Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Try setting QT_QMAKE_EXECUTABLE to point at your prebuilt qmake.exe. The CMake json files make CMake much easier to use, so I'm not sure if that doesn't work.
CMake's FindQT actually looks in the registry (HKCU\Software\Trolltech\Versions\) where the Qt installer sets some keys, so I'm surprised it did not find it. I had to specify manually because I installed both 32-bit and 64-bit versions and was switching back and forth.
Sorry, I should have made this optional
Should be located at C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x64\WS2_32.lib for the Windows 10 SDK (10.0.19041.0 varies depends on your version)
and C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\WS2_32.lib for the Windows 7.1 SDK
i'm not sure for the vc110 toolkit.
When I run CMake, I see
Unfortunately, the prebuilt binaries in the archive do not match those used in the last release of Reality. The Qt version was different for both architectures (4.8.4 was in the archive and 4.8.7 was used for released version) and as you saw boost is missing some libraries. I think you'll have to rebuild Boost yourself as I am not aware of a prebuilt version for Mac. IIRC, the one time I built Boost manually it was very simple to do.
As an aside, I compared the Qt 4.8.4 in the archive to the official Qt 4.8.4 and there were no differences, so if there was any customization it was in a later version we don't have. As my limited testing shows no issues with using the official version, it appears any customizations where cosmetic.
Thanks all of you.
I've forked Omniflux's work too. I'll see if I can get it to compile & run on my architecture.
I remember being blown away by Reality when it was released. I upgraded my PC with a Core i7-4770K in 2013 for better render speeds. The last time I used it was in 2018. Good times throughout.
I just tried to re-download v4 of the exe for DS from preta3d - to see how Lux would perform on my new AMD Ryzen 9 5900X - and both Chrome and Firefox aborted the download after reporting a security risk.
i would assume because its old at this point
There is a way to tell chrome to download something anyways dispite the warning
Just have to poke around a bit tho
Thanks for the tip. The plugin installed, but the Reality Render Editor won't load in the current version of DS.
Ah, well... It was worth a shot...
This is exactly what I do -- however, since the absolute path of qt source tree is compiled into the qmake executable, this method will only work if the prebuilt qt binaries you are using were built in the exact same drive letter and absolute folder path that you currently have them installed. If it isn't, then CMake will waste its time and your time.
The registry key method will only work if the Qt 4.8 SDK was installed with an official installer executable that installs the corresponding registry key. Yes, this worked for me 10 years ago, when Trolltech was still providing installation binaries for Qt 4.8. The last 5 years have been significantly more difficult for Qt 4.8 developers.
Thanks for the encouragement. I have not had the same luck with building Boost that you had. I've attempted to manually build it about 5-6 times in the last decade and have only been successful twice: both times with operating systems / build environments that were fully matched to the then current version of boost. Anyway, the precompiled mac boost library that I tried to use earlier turned out to have incomplete source files to re-build boost. So I downloaded the full 1.54 source here: https://www.boost.org/users/history/version_1_54_0.html. ; Unfortunately, it does not even make it through the bootstrap.sh without several pages of errors on Big Sur. If anyone has any instructions for me to use to get Boost 1.54 to build with Big Sur 11.6 and Xcode 13, please let me know.
For now, I've installed boost 1.76 + boost-python3 precompiled binaries using Mac homebrew. Once I'm able to generate project files to actually try to compile, I'll try to update the code as necessary to support boost 1.76 instead of 1.54. This might take a while.
However, with the switch to a complete precompiled boost library, I was able to get past the boost section of the CMake using these files, but the zeromq4/CMakeLists.txt appears to also be a block point for me on Mac. There are many errors related to missing commands and compile definitions. I'll try to figure out the zeromq CMake issues next weekend.
This sounds like it could be the OpenCL.DLL driver issue. Please refer to the prior post on how to diagnose and fix it.
I don't know how to reference individual posts, so I'm reprinting that section here for convenience:
Reallity 32 bits still working.
FYI: New installation, registration and rendering are still working 100% for me with: Reality 64-bit from Daz Store + Daz Studio 4.16 + Windows 11 + OpenCL 2.x DLL.
Also, I made some more progress with trying to build Reality from source-code:
With all the above changes, CMake will now complete and generate project files. Build process compiles and appears to successfully link to above dependencies. However, I am getting an error during build process:
even though I am explicitly linking against: C:\local\boost_1_78_0\lib64-msvc-14.0\libboost_thread-vc140-mt-x64-1_78.lib. I wish I could figure out how to get Visual Studio 2022 to actually display the full command line and error message like it used to do with older versions instead of this esoteric abbreviated junk it produces now.
Latest changes on this branch: https://github.com/danielbui78/reality/commits/experimental-vs2022
I was working on the same sort of thing yesterday as I wanted the whole bit to be able to be compiled and linked within VS Community 2022 in preperation for DS 5 & QT 5 (or is it QT 6 DAZ 3D are using in DS 5?). Also I had trouble with boost.
Maybe you've seen these build hints already?
1) c++ - How to compile Boost library with Visual Studio 2022 ( Preview 3) - Stack Overflow
2) Building Boost 1.77 using Visual Studio 2022 preview (working solution) · Issue #735 · boostorg/build (github.com)
3) https://github.com/boostorg/build/files/7177223/bootstrap.zip
If you are that far along then I'll leave well enough alone and work on something else until you gets things building the way you prefer. I was personally ready to go back to using Paolo's instructions very strictly instead, but your progress looks pretty decent to me so I'll wait.
You maybe could use a program like "VerySleepy" to watch the files that the VS linker opens and closes in the build process.
vc143 is VS2022, vc140 is VS2017. These are linked against different runtime libraries, I'm not sure if they are compatible (they may be), but even if they are, Boost autolinking is causing your problem. Try defining BOOST_ALL_NO_LIB to disable autolinking.
@danielbui78 Actually, why are you not using the vc143 version from the repository you posted?
A few years ago there were some reports that compiling a plugin with a newer runtime than vc100/windows7.1sdk would cause DS to crash. Have you found this not to be the case? It will simplify things immensely if everything can use a modern toolchain.
Well that is just not what I was hoping would happen with Luxrender integration with Studio. I was hoping for an update to the new version of Lux soon. Hopefully someone will pick this up, I just like to have more than one option available for render engines. In Blender I have 4,studio 1(no Octane due to no NVidia card).
THANK YOU!!! I completely missed that there was a vc143 version of boost. This got me over my last barrier preventing me from generating a working VS2022 project file. By switching to the vc143 precompiled boost, I got 99% of the way to end goal. The VS2022 Linker refused to link the Reality EXE with the precompiled qtmain.lib due to the toolchain / compiler version mismatch that you mentioned. But I was able to build enough of the qt 4.8.7 opensource code using VS2022 to create a qtmain.lib that successfully links with Reality EXE. Everything except for Python library is now building to completion.
Once the DLL plugin and EXE were built, I started fixing many crashes, probably related to the compiler and libc++ version mismatch (or maybe they were the Qt bugs that Paolo fixed). Most of these were related to QString::toStdString() causing crashes when fed into a c++ std::lib stream. It looks like the std::string was immediately out of scope and invalid when passed to the output stream. I fixed this by using the (const char*) overload variants of the affected functions and stream operators.
Then stepped through the code and figured out all the DRM points and commented them out. No more DRM stops (so far).
The Reality DS plugin now loads into Daz Studio, creates menu item and succesffully launches Reality EXE. It is still crashing when trying to transfer data to the Reality EXE. I suspect these are more memory violations related to std::string or other objects related to mismatched compiler versions... hopefully they can be fixed like my fixes above.
Reality EXE runs and even loads OpenCL 2.x. I still hardcoded the section to detect "Daz Studio Edition", but it is still showing "Poser Edition" on the title frame -- not sure if I'm doing it correctly yet. Finally, luxrender is not loading yet, since the plugin is still crashing during the transfer of Scene data to the EXE.
Yes, as I reported above, I sometimes encounter crashes when passing std::lib classes in Qt function calls. In my experience, these can be overcome by going back to ANSI C alternatives, where the binary / assembly interactions are much more predictable and consistent. The build process still requires some specific step-by-step actions to be done in order to build for me, but at least they can be built using VS2022 and the latest precompiled binary libraries.
https://github.com/danielbui78/reality
https://github.com/danielbui78/reality/tree/experimental-vs2022
https://github.com/danielbui78/reality/commit/2f8ceb4e02438f1ae4f1e5f7d696977f446e36e6 (Disable DRM)
So the experimental-vs2022 is the one with the disabled DRM?
Yes. You can probably cherry-pick the Disable DRM commit into any branch based off of Paolo's original source code without taking all the experimental changes to fix vs2022/compiler mismatch errors. That's why I listed the specific commit in addition to the experimental code branch.
I may then try the compile again if you are that close to having it done. LOL, I was trying to avoid splitting my attention is 10 different directions again but 4 hours messing with this to see where you are won't hurt anything.
Update on VS2022 source-code upgrade:
Some corrections and clarifications on my previous posts: most of my build and crash issues are NOT related to moving to Visual Studio 2022, but because of trying to use mismatched precompiled binaries from different compiler versions. If I was able to recompile all source-code dependencies for Visual Studio 2022, then I would probably have significantly fewer issues to resolve.
The majority of crashes that I am fixing are related to C++ runtime memory management / garbage collection. Most crashes appear to happen when locally defined variables are added to global data structures and then go out of scope. I'm replacing all those occurences with explicit "new" calls and pointer manipulation.
Here are some things that I need advice/help:
I will try to post step-by step instructions and my precompiled binaries when I have more free time.
UPDATE:
OpenSource-DeDRM Reality + Luxrender working with primitives and 3DL materials:
BTW, looks like that mesh conversion bug that was previously mentioned is right there in the top left edge of the sphere.
Cool:
Another clarification: when I said "working" in last post, that was being extremely generous. I have it built with debug libraries and am ignoring multiple access violations to get to this screen. So, yeah, not ready for production use. But still great to see the progress. I will post precompiled binaries and instructions so other people can violate access and maybe run luxrender too.
Looks great! Thanks for the hard work.
Oops -- sorry, the screenshots were taken with the plugin calling the original EXE. The rebuilt EXE is still not calling luxrender correctly yet. The EXE is sending "runRenderer" (RealityDataRelay.cpp:line 190) to some kind of server via zmq library, serverCommandInterface->send(message) (RealityDataRelay.cpp: line 230) but I have no idea what or where this server is. Is it another module inside the EXE? Is it a module inside the DS plugin?? I'm guessing it's a module inside the DS plugin... so in order to fully debug and figure out this situation, I'm going to have to run simulataneous debugging sessions on DazStudio/Reality Plugin + Reality.exe.... If anyone has any info to help, feel free to chime in.
UPDATE:
Yep, running two debugging sessions quickly shed light on the situation: Reality.EXE sends a "runRenderer" command to the zmq server embedded in the DS Plugin, which activates the Reality_DS::processTimedEvents() method (Reality_DS.cpp: line 859) inside the DS plugin to process the "render" command. This gets all the way down to ReLuxSceneExporter::getFilm() where it causes an unhandled exception (ReLuxSceneExporter.cpp: line 150). More crash fixes to come....
WARNING: you will probably need to uninstall this DS plugin after you are done testing since it crashes Daz Studio in almost every situation except for the exact one listed in the instructions.
https://github.com/danielbui78/reality/releases/tag/v0.0-alpha-test-1
All source code changes are here: in the https://github.com/danielbui78/reality/tree/experimental-vs2022
The precompiled libs for SQLiteCpp-3.1.1 and qtmain are in the release page above. I will try to modify the Readme page to reflect the changes that I've made to the build process, until then, you'll have to find the notes that I wrote in the post from December 19.
I am now "tagging out". Thanks to everyone who has helped get us this far! And thanks for Paolo for releasing this as opensource instead of keeping it locked up like so many software publishers do!
What do you mean "tagging out"? Signing off from further work for a few weeks?
To me it looks like the shadow terminator that's another thing from the tesselation bug reported before. As for the shadow terminator it happens in every pbr engine for low poly geometry, then some handle it better than others, don't know how lux is good with this. A common fix is to use subdivision to add more geometry for the render engine to work with.
https://blog.irayrender.com/post/29042276644/shadow-acne-and-the-shadow-terminator
https://developer.blender.org/rB9c6a382
Sorry to hear of the demise of this product. It always intrigued me. I even corresponded with Paolo a few times as I almost made the jump and purchased Reality/Luxrender.
Wishing you all the best in your retirement Paolo.
Please take care and enjoy your liesure pursuits.
Yes, exactly. Sorry, I was trying to make a reference to Tag Team matches like in American Professional Wrestling, where the active team member can "tag out" to rest outside the ring, and let another team member enter the ring.
Thanks for the info! I think you are right about the sphere but I'm not sure that explains the shadow artifacts on the Genesis 2 model. That could be related to broken code from the experimental build, so someone will have to verify the mesh data integrity. Also, that blog mentions it as a problem with the iray renderer, but that artifact does not show up in the current iray renderer of Daz Studio: at first, I thought that Daz Studio was automatically subdividing the sphere for the built-in iray render, but you can clearly see the sharp sphere edges when you do a render vs the smooth shadowing on the sphere surface. Did Iray fix this problem then?
Ha! nevermind -- I got Daz Studio's Iray to produce the same artifacts by turning off all the extra environmental/surface/volumetric effects that it applies by default. Once those are off, the same artifacts show up almost 1:1 equivalent to the luxrender artifacts.
That is a problem that Blender 3.0 has, per their claims, designed a much better solution for it.
I'll try to clarify. The idea of Reality 4 was to have a single exe for the UI so that it would not be necessary to re-invent the wheel for every host. Remember that Reality works with both DS and Poser. The UI is identical in both versions. I also had plans to port Reality to other hosts like ZBrush, Blender, etc. It made no sense to repeat the same UI with every host.
So, the UI is a stand-along program. The collection of data from the hosts, the geometry, the conversion of materials, etc. is done by a plugin. The same is for the export. Given that the plugin has access to the native geometry, it makes sense for the plugin to do the export. At the same time, once the scene is exported to the Lux-specific geometry format, the rest of the execution is common for every host. The running of Lux is always the same.
So, the UI is a separate process that communicates with the host plugin via ZeroMQ and vice-versa, because you need to do things like loading a new scene in DS and so the Reality UI needs to be told to reset and restart. You need to update a material using the Reality editor and that material definition needs to be sent to the host plugin, because that's where the Reality mats are stored. When you save the DS scene, Reality saves its materials in it, so that they can be easily reloaded the next time.
So, there is a lot of bidirectional communication and that's why I used ZeroMQ. The situation is complex enough without using some message-passing layer that required a separate server.
But there are a lot of processes that are abstracted because they are the same regardless of the host. The format of Reality mats is the same, the way they are stored is slightly different because of the characteristic of the host.
Hope this helps
Thank you very much.