Where to Begin

Hello. I just downloaded the Daz Studio SDK. I am already quite familiar with C++ so that's not a problem. However, there are a ton of documentation files. Can anyone suggest where I should begin? Better yet, does anyone know of any tutorials? Thanks.

Comments

  • Richard HaseltineRichard Haseltine Posts: 100,804

    Have you looked at the samples?

  • KingClownKingClown Posts: 11
    edited January 2021

    Hello all,

    I went to the samples folder at "/My DAZ 3D Library/DAZStudio4.5+ SDK/samples/"

    and also the SDK documentation.

    Files : ./sdk/samples/interface/AFirstPlugin
    afirstpluginaction.h The action class header.
    afirstpluginaction.cpp The action class implementation.
    afirstplugindlg.h The dialog class header.
    afirstplugindlg.cpp The dialog class implementation.
    afirstplugin.def The exports definition file for compiling under Windows.
    pluginmain.cpp The plug-in definition.
    AFirstPlugin.vcproj Microsoft Visual C++ 2010 project file.

     

    I was able to constuct a non-modal DAZ Script that works well for all intents and purposes, but it's my understanding that non-modal scripts are rejected by DAZ.

    So, I simply decided to port the code into a magical .dll SDK plugin. DAZ Script is QT (which I'm familiar with), so I started to get all kinds of excited.

     

    However, the latest release of the SDK kit doesn't include the Microsoft Visual C++ 2010 project files.

     

    I can load the files into a new project, but I can't seem to get the "Reference" to the dzcore.lib to show up when I right click to "Add Reference". I was already to the point of frustration in developing this project and I really didn't want to be delayed - forever - so,  I thought I 'd reach out for help on the forums.

    I've written many applications in C#, java, python, android, and I was taught the basics of C++ in school, but honestly, it's hard enough trying to learn the DAZ SDK, while altering your thinking from C# to C++, without a working project file as a starting point. 

    It is equally frustrating to read other post on the forum that suggest, "Have you looked at the samples?" when the samples are no longer supplied.

    Any help getting started would be greatly appreciated.

    Thanks!

    Post edited by KingClown on
  • KingClown said:

    Hello all,

    I went to the samples folder at "/My DAZ 3D Library/DAZStudio4.5+ SDK/samples/"

    and also the SDK documentation.

    Files : ./sdk/samples/interface/AFirstPlugin
    afirstpluginaction.h The action class header.
    afirstpluginaction.cpp The action class implementation.
    afirstplugindlg.h The dialog class header.
    afirstplugindlg.cpp The dialog class implementation.
    afirstplugin.def The exports definition file for compiling under Windows.
    pluginmain.cpp The plug-in definition.
    AFirstPlugin.vcproj Microsoft Visual C++ 2010 project file.

     

    I was able to constuct a non-modal DAZ Script that works well for all intents and purposes, but it's my understanding that non-modal scripts are rejected by DAZ.

    So, I simply decided to port the code into a magical .dll SDK plugin. DAZ Script is QT (which I'm familiar with), so I started to get all kinds of excited.

     

    However, the latest release of the SDK kit doesn't include the Microsoft Visual C++ 2010 project files.

     

    I can load the files into a new project, but I can't seem to get the "Reference" to the dzcore.lib to show up when I right click to "Add Reference". I was already to the point of frustration in developing this project and I really didn't want to be delayed - forever - so,  I thought I 'd reach out for help on the forums.

    I've written many applications in C#, java, python, android, and I was taught the basics of C++ in school, but honestly, it's hard enough trying to learn the DAZ SDK, while altering your thinking from C# to C++, without a working project file as a starting point. 

    It is equally frustrating to read other post on the forum that suggest, "Have you looked at the samples?" when the samples are no longer supplied.

    Any help getting started would be greatly appreciated.

    Thanks!

    The DS plugins I've written are really all the win32 programming I've done in the last 20 years, so please recognize the difference between what I figured out that works and what is actually the correct practice :)

    To get those symbols resolved, instead of adding references, which I think is a COM thing, just go to the project properties and go down to Linker, right under C/C++.

    I wish I could say your frustration wil end after figuring out the build, but it is just going to get worse when you can't figure out the simplest of things because there is basically no documentation for anything meaningful. Good luck nonetheless.

     

    general.jpg
    1443 x 596 - 160K
    input.jpg
    1444 x 597 - 127K
  • TheMysteryIsThePoint said:

    The DS plugins I've written are really all the win32 programming I've done in the last 20 years, so please recognize the difference between what I figured out that works and what is actually the correct practice :)

    To get those symbols resolved, instead of adding references, which I think is a COM thing, just go to the project properties and go down to Linker, right under C/C++.

    I wish I could say your frustration wil end after figuring out the build, but it is just going to get worse when you can't figure out the simplest of things because there is basically no documentation for anything meaningful. Good luck nonetheless.

     

    Thanks, TheMysteryIsThePoint, but after a days work of effort I could not get the.dll to compile. I resolved most of the errors, but I'm getting 166 linker errors:

    Severity Code Description Project File Line Suppression StateError LNK2001 unresolved external symbol "protected: virtual bool __thiscall DzBasicDialog::event(class QEvent *)" (?event@DzBasicDialog@@MAE_NPAVQEvent@@@Z) AFirstPlugin C:\Users\Vision\Documents\Visual Studio 2019\Projects\VS-DAZ-SDK-master\AFirstPlugin\afirstplugindlg.obj 1

    I was going to type in my configuration for the project, but I'm too lazy to re-learn C++ to that level today. Especially when sample files are missing from the Daz SDK and the documentation is somties a little cryptic or out-of-date. I think I'll forgo the agony of trying to do all that and work on something a little easier.

    Really, I want to get published and be useful. If I can manage that, mission accomplished. 

    I have scripting down. Most of my script request are nominal; Daz Scripts work great and there's ample samples out there for that. I can't finish my project the way I wanted, at this point, but its likely I'll eventually get the SDK sorted out either by asking questions on the forums, or by making a support request for the SDK sample files, or both (whichever comes first).

    The learning curve in the 3D is high. I ain't joking. The amount of details that goes into the creation of a complex, realistic 3D model is astounding. Files, database, source code, materials, vertices, lights, cameras, models, make-up, reality, action - the list goes on and on and on. Makes a fellow have mad respect for the published artist here.

    Thanks for your help! I'm way farther along than I was and someday, down the road, I'll get into the SDK again.

     

     

     

     

  • KingClown said:

    TheMysteryIsThePoint said:

    The DS plugins I've written are really all the win32 programming I've done in the last 20 years, so please recognize the difference between what I figured out that works and what is actually the correct practice :)

    To get those symbols resolved, instead of adding references, which I think is a COM thing, just go to the project properties and go down to Linker, right under C/C++.

    I wish I could say your frustration wil end after figuring out the build, but it is just going to get worse when you can't figure out the simplest of things because there is basically no documentation for anything meaningful. Good luck nonetheless.

     

    Thanks, TheMysteryIsThePoint, but after a days work of effort I could not get the.dll to compile. I resolved most of the errors, but I'm getting 166 linker errors:

    Severity Code Description Project File Line Suppression StateError LNK2001 unresolved external symbol "protected: virtual bool __thiscall DzBasicDialog::event(class QEvent *)" (?event@DzBasicDialog@@MAE_NPAVQEvent@@@Z) AFirstPlugin C:\Users\Vision\Documents\Visual Studio 2019\Projects\VS-DAZ-SDK-master\AFirstPlugin\afirstplugindlg.obj 1

    I was going to type in my configuration for the project, but I'm too lazy to re-learn C++ to that level today. Especially when sample files are missing from the Daz SDK and the documentation is somties a little cryptic or out-of-date. I think I'll forgo the agony of trying to do all that and work on something a little easier.

    Really, I want to get published and be useful. If I can manage that, mission accomplished. 

    I have scripting down. Most of my script request are nominal; Daz Scripts work great and there's ample samples out there for that. I can't finish my project the way I wanted, at this point, but its likely I'll eventually get the SDK sorted out either by asking questions on the forums, or by making a support request for the SDK sample files, or both (whichever comes first).

    The learning curve in the 3D is high. I ain't joking. The amount of details that goes into the creation of a complex, realistic 3D model is astounding. Files, database, source code, materials, vertices, lights, cameras, models, make-up, reality, action - the list goes on and on and on. Makes a fellow have mad respect for the published artist here.

    Thanks for your help! I'm way farther along than I was and someday, down the road, I'll get into the SDK again.

    Hi @KingClown

    Well, technically if you got to the linker stage, everything compiled and you are extremely close to success. It sounds like you're just missing dzcore.lib or maybe you added it for the Debug configuration but are using the Release configuration or vice versa. I certainly feel your pain, we've all been there, and I'd be happy to send you a working skeleton should you wish to try again... you're so close it'd be a shame to rob yourself of the elation of getting it to work.

  • TheMysteryIsThePoint said:

    Hi @KingClown

    Well, technically if you got to the linker stage, everything compiled and you are extremely close to success. It sounds like you're just missing dzcore.lib or maybe you added it for the Debug configuration but are using the Release configuration or vice versa. I certainly feel your pain, we've all been there, and I'd be happy to send you a working skeleton should you wish to try again... you're so close it'd be a shame to rob yourself of the elation of getting it to work.

    Really? I would love a working skeleton! Thank you. I was going to turn non-modal off on my script and use that, but the tool "sort of" requires that the end-user work in a non-modal fashion. With your working skeleton, I should be able to convert my javascript code into the plugin without too much trouble. Once I get the script to compile, I think I know how to install it so the plugin will be available in the Daz dropdown menu.

    I'll take a look into your Debug/Release suggestion because I need to understand where my errors are taking place, but if you can send your script, that would be amazing. I'd rather start with a Droid instead of this Frankenstien monster. Thanks again, for all your help.

  • surrealsurreal Posts: 168

    Sounds like you are familar with building EXE files, building a DLL file is slightly different.

     

    Regarding "Unresolved external symbol",

    it usually means I have forgotten to MOC a file that includes a class that inherits Q_OBJECT. See "Compiling DAZ Studio Plugins on Windows" in the Help documentation.

     

  • KingClownKingClown Posts: 11
    edited January 2021

    surreal said:

    Sounds like you are familar with building EXE files, building a DLL file is slightly different.

     

    Regarding "Unresolved external symbol",

    it usually means I have forgotten to MOC a file that includes a class that inherits Q_OBJECT. See "Compiling DAZ Studio Plugins on Windows" in the Help documentation.

    Hi @surreal ,

    Thanks for pointing me to that document. I don't know how I missed it.

    One more piece to creating a Frankenstien monster from a mish-mash of articles, suggestions, a down-loaded sample from the underground, and an antiquated help document. I mean, 2010? That's 11 years ago! If I were actually able to get this particular .dll to build, as I am down to one error now, I would never feel the integrity of the code was solid enough to ask someone to load the final product on their system.

    I have already invested a week of my time into solving this problem, one day being equal to 8-10 hours of work and study and the result is: a Frankenstien monster app.

    I've created several, robust dynamic link libraries in my life, as well as a plethora of executables, using Visual Studio with C# or Visual Basic; this stuff is coming back to me, but the re-learning curve is extremly high, the information is cryptic or missing, and the examples are broken. The example solutions are really the most important success tool needed for anyone wishing to build a plugin for the Daz Studio environment.

    I estimate it will take me 5-7 years to complete a Daz SDK plugin without the examples and with the information that is available. 

     God, have mercy. 

    I get that someone should have an intimate knowledge of what they are building, but without a starting point that's extremely difficult to learn. We are talking about a custom app (Daz) with custom features. Without the building blocks, one is certain to fail. I don't wish to spend 5-7 years of my life trying to fix something that is broken, so I can use it to finish the remaining 3% of my 97% completed project. What I'm trying to say is:

    "The Daz Studio SDK is broken, along with its supporting documentation."

    "The Daz Studio SDK is broken, along with its supporting documentation. That is, if you've never actually read the entire supporting documentation. 

            - Comment edited by Glen to correct a mistake.

    If I'm going to invest 5-7 years, I'd rather spend my time rewriting Daz in Python, which is perfectly suited for cross-platform, QT apps such as Daz Studio.

    Writing an app in QT with Visual Studio is a bitter and harsh experience, where coding an app in QT with python is qute erotic. In addition, the learning curve for someone wishing to learn the Python programming langauge, who already has a solid working knowledge of C style programming languages, is super easy.

    Here is a short assessment of C++ vs. Python from the bitdegree.org website:

    https://www.bitdegree.org/tutorials/python-vs-c-plus-plus/

    Comparing Python vs C++ leads to one conclusion: Python is better for beginners in terms of its easy-to-read code and simple syntax. Additionally, Python is a good option for web development (back-end), while C++ is not very popular in web development of any kind.

    Python is also a leading language for data analysis and machine learning. While it is possible to use C++ for machine learning purposes as well, it is not a good option.

    In terms of simplicity, Python is much easier to use and has a great support system when it comes to AI and ML frameworks. Learn more about modules of Python in this tutorial.

    C++ wins the race when it comes to game development. Yes, Python can create simple games that will help you understand the basic logic and steps of producing a game. However, for more sophisticated game development, C++ is an unstoppable leader.

    The performance of C++ and Python also comes to an end with this conclusion: C++ is much faster than Python. After all, Python is an interpreted language, and it cannot be a match for a compiled language such as C++.

    The good news is that you can get the best of both worlds by combining C++ and Python code. Therefore, some speed-critical parts of your project can use C++ instead of Python.

    I imagine Poser was written in some form of C. Since Daz Studio was originally written to be compliant with Poser, which has Python support, shouldn't it support Python as well? This is probably another pipe dream of mine.

    Anyways, thanks again for taking the time to consider my problem. At this point, I'm moving on to other projects until I get published. I have simple projects in mind that I can create. I'm going to open a support ticket and request the missing SDK sample files. @TheMysteryIsThePoint offered to give me a working skeleton, so if I get that or the sample files from Daz, then I'll go again. I need to know that the integrity of my software is not defective from out-the-box.

    By the way, I'm down to one error with my Frankenapp. I'd post that error, but I broke the app trying to fix the error and need to start over with a fresh template. When I re-Build, if the error still exists (I think I know how to correct it), then I will post that.

    Glen

     

    Post edited by KingClown on
  • For trouble compiling, see /docs/compile_win.html in the folder to which you installed the SDK. The latest update you mentioned has switched to usign CMake, that's why you don't see the Visual C++ project files.

    You don't say how you are converting the non-modal script to a plug-in - it is usual, t least if there is a UI, to use a class derived from DzPane.

  • KingClown said:

    surreal said:

    Sounds like you are familar with building EXE files, building a DLL file is slightly different.

     

    Regarding "Unresolved external symbol",

    it usually means I have forgotten to MOC a file that includes a class that inherits Q_OBJECT. See "Compiling DAZ Studio Plugins on Windows" in the Help documentation.

    Hi @surreal ,

    Thanks for pointing me to that document. I don't know how I missed it.

    One more piece to creating a Frankenstien monster from a mish-mash of articles, suggestions, a down-loaded sample from the underground, and an antiquated help document. I mean, 2010? That's 11 years ago! If I were actually able to get this particular .dll to build, as I am down to one error now, I would never feel the integrity of the code was solid enough to ask someone to load the final product on their system.

    I have already invested a week of my time into solving this problem, one day being equal to 8-10 hours of work and study and the result is: a Frankenstien monster app.

    I've created several, robust dynamic link libraries in my life, as well as a plethora of executables, using Visual Studio with C# or Visual Basic; this stuff is coming back to me, but the re-learning curve is extremly high, the information is cryptic or missing, and the examples are broken. The example solutions are really the most important success tool needed for anyone wishing to build a plugin for the Daz Studio environment.

    I estimate it will take me 5-7 years to complete a Daz SDK plugin without the examples and with the information that is available. 

     God, have mercy. 

    I get that someone should have an intimate knowledge of what they are building, but without a starting point that's extremely difficult to learn. We are talking about a custom app (Daz) with custom features. Without the building blocks, one is certain to fail. I don't wish to spend 5-7 years of my life trying to fix something that is broken, so I can use it to finish the remaining 3% of my 97% completed project. What I'm trying to say is:

    "The Daz Studio SDK is broken, along with its supporting documentation."

    If I'm going to invest 5-7 years, I'd rather spend my time rewriting Daz in Python, which is perfectly suited for cross-platform, QT apps such as Daz Studio.

    Writing an app in QT with Visual Studio is a bitter and harsh experience, where coding an app in QT with python is qute erotic. In addition, the learning curve for someone wishing to learn the Python programming langauge, who already has a solid working knowledge of C style programming languages, is super easy.

    Here is a short assessment of C++ vs. Python from the bitdegree.org website:

    https://www.bitdegree.org/tutorials/python-vs-c-plus-plus/

    Comparing Python vs C++ leads to one conclusion: Python is better for beginners in terms of its easy-to-read code and simple syntax. Additionally, Python is a good option for web development (back-end), while C++ is not very popular in web development of any kind.

    Python is also a leading language for data analysis and machine learning. While it is possible to use C++ for machine learning purposes as well, it is not a good option.

    In terms of simplicity, Python is much easier to use and has a great support system when it comes to AI and ML frameworks. Learn more about modules of Python in this tutorial.

    C++ wins the race when it comes to game development. Yes, Python can create simple games that will help you understand the basic logic and steps of producing a game. However, for more sophisticated game development, C++ is an unstoppable leader.

    The performance of C++ and Python also comes to an end with this conclusion: C++ is much faster than Python. After all, Python is an interpreted language, and it cannot be a match for a compiled language such as C++.

    The good news is that you can get the best of both worlds by combining C++ and Python code. Therefore, some speed-critical parts of your project can use C++ instead of Python.

    I imagine Poser was written in some form of C. Since Daz Studio was originally written to be compliant with Poser, which has Python support, shouldn't it support Python as well? This is probably another pipe dream of mine.

    Anyways, thanks again for taking the time to consider my problem. At this point, I'm moving on to other projects until I get published. I have simple projects in mind that I can create. I'm going to open a support ticket and request the missing SDK sample files. @TheMysteryIsThePoint offered to give me a working skeleton, so if I get that or the sample files from Daz, then I'll go again. I need to know that the integrity of my software is not defective from out-the-box.

    By the way, I'm down to one error with my Frankenapp. I'd post that error, but I broke the app trying to fix the error and need to start over with a fresh template. When I re-Build, if the error still exists (I think I know how to correct it), then I will post that.

    Glen

     You should find the SDK samples at https://www.daz3d.com/downloader/customer/files#prod_14876 , or type SDK in the filter field in the Product Library.

    ---------------------

    As the excerpt you quote acknowledges, Python is an interpreted language with a major speed disadvantage compared to compiled languages such as C/C++. The scripting language(s), if any, that an application supports are separate from the code in which the application is written.

  • Remember what I said about my way, versus the correct way? :)

    If Richard is saying that the samples now use CMake, probably so they can support the Mac too, then instead of using my skeleton, you'd be better off using it to generate your Visual Studio project files, and then hacking that. What @surreal said is probably more correct than what I did, in that it's the code generated by the moc compiler that isn't part of your project because, unless you've done Qt before, you wouldn't even be aware that these files were necessary because they don't exist. I assume that the CMake script will generate the correct dependencies so that the moc compiler will be run on the right header files, and everything will work. Pre CMake, the dependency was expressed as a custom build step on each header that had a class that defined Q_OBJECT, so after CMake does its thing, you might look for these custom build steps to see how the moc compiler works, and how to customize it to work with your project.

    I didn't know the samples are CMake now, and can understand how you must be really confused because there are files that you need to compile that haven't even been generated yet...

    Note that the moc files isn't a Daz thing, nor a C++ thing, it's a Qt thing and how Qt does it's late-binding magic with signals/slots. You'll have to understand it well in order to do certain things that interact with the rest of DS.

    So if I were you, I would forget about everything else and first figure out how to run CMake and generate your VS project file. Then look for those custom build steps that runs uic on the .ui file (if there is one) and moc on the GUI's .h files. Everything might become clear to you once you are actually seeing all the files, i.e. the generated ones.

  • KingClownKingClown Posts: 11
    edited January 2021

    Richard Haseltine said:

    For trouble compiling, see /docs/compile_win.html in the folder to which you installed the SDK. The latest update you mentioned has switched to usign CMake, that's why you don't see the Visual C++ project files.

    You don't say how you are converting the non-modal script to a plug-in - it is usual, t least if there is a UI, to use a class derived from DzPane.

    Thank you, Richard Haseltine for steering me in the right direction. I've decided to read the instruction manuals, as it appears my zelous confidence has betrayed me. I will take a look at "/docs/compile_win.html ".

    C++ will humble the average programmer, but I feel it's worth investing the time to reach at least an intermediate level of understanding of the language. I went back to scripting for now, to achieve my goals, and things are going well enough. There's so much one needs to understand to write a script or a plugin, and that's not to mention the requirement to simply understand what one is trying to achieve within the Daz Studio environment. Lighting, and cameras, and glute morphs! Oh, my!

    That being said, here's the shortlist of documents I plan on digesting in order to create a robust plugin:

    Daz Studio SDK help files: /My DAZ 3D Library/DAZStudio4.5+ SDK/docs

    C++ Programming Language: https://www.programiz.com/cpp-programming

    Dynamic Link Libraries: https://docs.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp?view=msvc-160

    Daz Reference Guide: http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/start

    Daz Tutorials and Information: https://blog.daz3d.com/

    QT Framework: https://doc.qt.io/

    Javascript for Daz Scripts: https://www.tutorialspoint.com/javascript/index.htm


    Helpful, knowledgeable people and awesome information: https://www.daz3d.com/forums


    I hope this list helps someone else achieve their goal of creating a script or a plugin, or at the very least, gives them an idea of how difficult that goal might be.

    Thanks again, Richard.

    Glen

    Post edited by KingClown on
  • TheMysteryIsThePoint said:

    Remember what I said about my way, versus the correct way? :)

    If Richard is saying that the samples now use CMake, probably so they can support the Mac too, then instead of using my skeleton, you'd be better off using it to generate your Visual Studio project files, and then hacking that. What @surreal said is probably more correct than what I did, in that it's the code generated by the moc compiler that isn't part of your project because, unless you've done Qt before, you wouldn't even be aware that these files were necessary because they don't exist. I assume that the CMake script will generate the correct dependencies so that the moc compiler will be run on the right header files, and everything will work. Pre CMake, the dependency was expressed as a custom build step on each header that had a class that defined Q_OBJECT, so after CMake does its thing, you might look for these custom build steps to see how the moc compiler works, and how to customize it to work with your project.

    I didn't know the samples are CMake now, and can understand how you must be really confused because there are files that you need to compile that haven't even been generated yet...

    Note that the moc files isn't a Daz thing, nor a C++ thing, it's a Qt thing and how Qt does it's late-binding magic with signals/slots. You'll have to understand it well in order to do certain things that interact with the rest of DS.

    So if I were you, I would forget about everything else and first figure out how to run CMake and generate your VS project file. Then look for those custom build steps that runs uic on the .ui file (if there is one) and moc on the GUI's .h files. Everything might become clear to you once you are actually seeing all the files, i.e. the generated ones.

     Thank you, TheMysteryIsThePoint. This is great information! In particular...

    TheMysteryIsThePoint said:

    Note that the moc files isn't a Daz thing, nor a C++ thing, it's a Qt thing... 

    That clears my understanding considerably. I will follow your advice and I may look into this a little soon...

    TheMysteryIsThePoint said:

    Then look for those custom build steps that runs uic on the .ui file (if there is one) and moc on the GUI's .h files.

    I've written QT .ui files before and with my in-the-future, deep understanding of C++ compiling, I should be able to construct one if the file is missing.

    I feel as though I have the information I need to accomplish my goals, although that will take longer than I had originally anticipated. Thank you! For now, until I can dedicate some time to that task, I'll stick to scripting and other creative efforts where my knowledge is growing deep.

    Glen

  • Richard Haseltine, is there a sample regarding writing a dzDevice plugin or equivalent (a sensor that continually reads information and updates a scene view)?

    All the best.

  • Richard HaseltineRichard Haseltine Posts: 100,804
    edited February 2021

    Not that I am aware of, though I think Casual wrote at least one (see his threads in the Freebies forum).

    Post edited by Richard Haseltine on
Sign In or Register to comment.