4.5 is the currently available version, Daz has been careful to ensure that changes since then have not broken the SDK.
Unfortunately this "carefulness" doesn't guarantee that everything works as intended.
The most annoying thing for me has been that plugins cannot be linked without copying the relevant dll's from the installation folder as the dll's included with the SDK has been generated using a different version of QT than the current version of the application uses.....
I've seen a few comments about "an entire new ray tracer implementation should warrant a new SDK" and I totaly agree on that. I would also think that "updating the entire base framework" should be one of those changes that causes a new SDK to be released.........
This wouldn't be quite as irritating if it wasn't for this little commet I dug up from the release notes for "Release candidate 5":
Updated SDK version to 4.9.3.154; SDK min is 4.5.0.100
This sort of comment just makes it seem that nobody could be bothered to push the "Generate updated SDK build" button
The SDK is not updated because if it was it would break existing plug-ins. Some developers are no longer active, or are occupied principally in other areas, and so their plug-ins would probabyl fall by the wayside. Users also complain about having to update even when there is a new version promptly available.
I'm not sure what you mean by copying dlls - plug-ins (.dlls or dylibs) go in the plugins folder of the application folder, or a sub-folder thereof, and always have.
If you look at the foot notes to Rob's little figure in http://www.daz3d.com/forums/discussion/comment/1203666/#Comment_1203666 you will see that they are investigating the possibility of an SDK update for DS 4.10.x.x - but that that is not a promise that there will be such an update (or indeed a DS version numbered 4.10.x.x). This is the reason for the Updated SDK version to 4.x.x.x; SDK min is 4.5.0.100 enties in the log, preparing for a possible update without breaking the existing SDK.
Plug-ins on Windows, which appears to be what you are using, will link against the existing SDK - the Daz developers do that, after all - which is, I would assume, what you are using since you mention .dlls rather than .dylibs. You can tell your compiler to place the compiled files directly in the plugins folder, if that is what you mean by having to move them. If you are using other libraries from Qt then of course any required placement of support files is down to you - that would be true regardless of SDK version. If you are having problems with debugging, apparently you need to compile with the Runtime Library set to /MD and not /MDd since there isn't a separate debug version of DS.
What I have is both a plugin and what is basically a standalone DAZ Studio application. My application extends the DzApp class and provides additional functionallity for what is esentialy some eleborate scripted rendering.
The last part is actually what is giving me the problems with QT. The extended application runs within the DAZ Studio install directory, so it needs to be linked with dll's build with the correct QT version. Otherwise it cannot even start :)
As the plugin is a sort verifcation/content creation helper tool it uses quite a bit of the extended application codebase to ensure that it perfoms the same actions and parses assets in the same way <-- this is what gives me the linker problems with plugins. And just FYI: A QT version error in a plugin crashes the entire application on startup (at least on my setup :))
The copying of dll's is quite possibly just a Visual Studio quirk. Apparently that IDE really prefers the dll's you're linking against to reside in a predefined location which is a bit of a pain to maintain if you're working on the project accross multiple machines/installations. So the point of least resistance here is to just copy the needed dll's from the DAZ installation to a predefined location and work from there.
I do hope that a new version of the SDK is comming soon. I am currently working on switching the rendering from 3Delight to IRay and well.... All the features I want to use from the IRay settings are not exposed to the SDK. So I will have to do my setup by programatically navigating the UI and checking/unchecking what I need.
FYI: Loading of renderoptions with canvas rendering enabled does not set the nodelists for the various canvas' even though they are clearly defined and saved in the .duf file. Is this something I should file a bug repport for?
FYI: Loading of renderoptions with canvas rendering enabled does not set the nodelists for the various canvas' even though they are clearly defined and saved in the .duf file. Is this something I should file a bug repport for?
I would think so, there's certainly no harm in doing so.
Comments
4.5 is the currently available version, Daz has been careful to ensure that changes since then have not broken the SDK.
Unfortunately this "carefulness" doesn't guarantee that everything works as intended.
The most annoying thing for me has been that plugins cannot be linked without copying the relevant dll's from the installation folder as the dll's included with the SDK has been generated using a different version of QT than the current version of the application uses.....
I've seen a few comments about "an entire new ray tracer implementation should warrant a new SDK" and I totaly agree on that. I would also think that "updating the entire base framework" should be one of those changes that causes a new SDK to be released.........
This wouldn't be quite as irritating if it wasn't for this little commet I dug up from the release notes for "Release candidate 5":
Updated SDK version to 4.9.3.154; SDK min is 4.5.0.100
This sort of comment just makes it seem that nobody could be bothered to push the "Generate updated SDK build" button
The SDK is not updated because if it was it would break existing plug-ins. Some developers are no longer active, or are occupied principally in other areas, and so their plug-ins would probabyl fall by the wayside. Users also complain about having to update even when there is a new version promptly available.
I'm not sure what you mean by copying dlls - plug-ins (.dlls or dylibs) go in the plugins folder of the application folder, or a sub-folder thereof, and always have.
Passing on some additional information:
If you look at the foot notes to Rob's little figure in http://www.daz3d.com/forums/discussion/comment/1203666/#Comment_1203666 you will see that they are investigating the possibility of an SDK update for DS 4.10.x.x - but that that is not a promise that there will be such an update (or indeed a DS version numbered 4.10.x.x). This is the reason for the Updated SDK version to 4.x.x.x; SDK min is 4.5.0.100 enties in the log, preparing for a possible update without breaking the existing SDK.
Plug-ins on Windows, which appears to be what you are using, will link against the existing SDK - the Daz developers do that, after all - which is, I would assume, what you are using since you mention .dlls rather than .dylibs. You can tell your compiler to place the compiled files directly in the plugins folder, if that is what you mean by having to move them. If you are using other libraries from Qt then of course any required placement of support files is down to you - that would be true regardless of SDK version. If you are having problems with debugging, apparently you need to compile with the Runtime Library set to /MD and not /MDd since there isn't a separate debug version of DS.
Thanks for the response Richard.
To clarify:
What I have is both a plugin and what is basically a standalone DAZ Studio application. My application extends the DzApp class and provides additional functionallity for what is esentialy some eleborate scripted rendering.
The last part is actually what is giving me the problems with QT. The extended application runs within the DAZ Studio install directory, so it needs to be linked with dll's build with the correct QT version. Otherwise it cannot even start :)
As the plugin is a sort verifcation/content creation helper tool it uses quite a bit of the extended application codebase to ensure that it perfoms the same actions and parses assets in the same way <-- this is what gives me the linker problems with plugins. And just FYI: A QT version error in a plugin crashes the entire application on startup (at least on my setup :))
The copying of dll's is quite possibly just a Visual Studio quirk. Apparently that IDE really prefers the dll's you're linking against to reside in a predefined location which is a bit of a pain to maintain if you're working on the project accross multiple machines/installations. So the point of least resistance here is to just copy the needed dll's from the DAZ installation to a predefined location and work from there.
I do hope that a new version of the SDK is comming soon. I am currently working on switching the rendering from 3Delight to IRay and well.... All the features I want to use from the IRay settings are not exposed to the SDK. So I will have to do my setup by programatically navigating the UI and checking/unchecking what I need.
FYI: Loading of renderoptions with canvas rendering enabled does not set the nodelists for the various canvas' even though they are clearly defined and saved in the .duf file. Is this something I should file a bug repport for?
I would think so, there's certainly no harm in doing so.