Loading...
> >

Reality Plugin End-of-life notice

24567

Comments

  • takezo_3001takezo_3001 Posts: 1,948
    edited November 2021

    TheMysteryIsThePoint said:

    Which is more probable, that a billion dollar industry has collectively overlooked something that is obvious, or that there is somehow a practical flaw in your "perfect solution"?

    Elaborate... why do you think it's not a viable solution?

    Post edited by takezo_3001 on
  • vrba79vrba79 Posts: 1,297
    edited November 2021

    I just hope this will serve as a cautionary tale to other plug-in developers: Don't screw over your entire customer base out of fear that few people are going to rip you off. At the end of the day, you're just gonna hurt the people who forked over their cash to support you.

    Post edited by vrba79 on
  • nonesuch00nonesuch00 Posts: 17,944

    Omniflux said:

    @TheMysteryIsThePoint Yes, that is the correct repo.

    I think it has nearly everything included to build for OSX (possibly only missing QT). It is missing all the libraries for Windows. The documentation mentions another repo called reality-libs but I have not been able to find it so I tracked them down at various other locations.

    The documentation states there were some project specific changes made to the version of QT that was used, but they are not documented or included, so they may need to be figured out again.

    The CMakeLists.txt needs some work to genericize the build environment.

     

    Because you should be searching for QT-reality-libs I think. It's both mac & win & has Reality specific source edits by Paolo and using these just to get the initial build enviroment correct & functioning would be your 1st step. 2nd step, strip out all DRM. 3rd step fix the Reality / QT source to fix Reality after MS tightened up Windows 10 networking security. 4th step with the release of DS 5 upgrade QT to QT 5 or QT6 I forget which DS 5 will be using.

    Gotcha: Microsoft has upgraded in Windows 10 in the past year it's networking and kernel to be more secure which actually broke my purchased and functioning Reality from the DAZ Store to be not any longer working. Reality uses TCP/IP messaging for sending the scenes so you'd need to update that messaging as well, unless I'm mistaken on what broke my Reality and goodness knows I've been mistaken many times before.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,892

    takezo_3001 said:

    TheMysteryIsThePoint said:

    Which is more probable, that a billion dollar industry has collectively overlooked something that is obvious, or that there is somehow a practical flaw in your "perfect solution"?

    Elaborate... how is it not a viable solution?

     A few things:

    • It is based on the value of keeping some personally identifiable data secret being greater than the value of pirating the software. Many people don't want to give a company even their actual email address, to say nothing of data important enough to disuade them from sharing the program. A photo? That's Orwellian.
    • The pirated software could have been stolen from a legitimate user, without his knowledge, along with his PID. It's an unacceptable risk to require a user to spread his PID all over his system in ways he doesn't necessarily understand. And with this, the cost of being hacked is intensified with your PID distributed all over your system. The EFF would mount a veritable crusade against this.
    • The hackers will just hack this information as well. In cybersecurity circles, it is said to greatly favor the attacker because he only has to be "right" once, while the defenders have to be "right" all the time. It's an inherently losing proposition. The measures become increasingly intrusive and, in the end, you get hacked anyway.
    • How would a company authenticate this PID so that bogus data cannot be proffered in the way some people use 12345678 as a password? If it's a photo, how would the vendor know what I actually look like? The vendor probably doesn't even have the user's credit card info in unencrypted form.

    These are just things I've thought of off the top of my head. But I think it is actually a worse proposal than typical server-ping DRM in terms of inconveniencing that lawful party.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,892

    nonesuch00 said:

    danielbui78 said:

    Padone said:

    If I understand correctly from @danielbui78, it seems there's another open source plugin from daz to lux, so mac people may have an alternative.

    https://www.daz3d.com/forums/discussion/514376/iray-vs-luxcore-heads-to-heads-blind-comparison

    Just to clarify, there are compiled versions for both Windows and Mac.  Also: although it is a daz to lux plugin, it's not designed to be a drop-in replacement for Reality.  Instead, the goal is to be a drop-in replacement for the Iray Render engine.  The latest version is hardcoded for just LuxCore Render, but the older code base is still in place for LuxRender output.  Eventually, I'll re-enable the LuxRender pathway to allow people to choose between LuxRender or LuxCore.

    Find out more about it here: https://www.daz3d.com/forums/discussion/499531/open-source-release-daz-render-plugin-framework-with-yet-another-lux-plugin/p1

     

    Regarding the Reality End-Of-Life and open-source:  I've tried to get the source code to build, but have run into barriers trying to build or obtain the dependency libraries.  If someone has pre-compiled dependencies, then that would be a major step towards building the Reality plugin, modifying the source-code and ultimately removing the copy-protection system from the Reality plugin.

    I have downloaded what Paolo made available which includes the precompiled libraries and such if that's what you mean. Note: It's as is with no changes by me so you needn't ask if I changed anything from Paolo's original post at the online repository. It was posted on the internet at one of those commercial online CMS archival services unless it's been taken down since. If so, PM me and we can arrange for me to post you a USB fob with that original source.

    Actually, both development archives taken together amount to about 4GB which is small enough to upload to my MS OneDrive long enough for you to download if you are interested in obtaining it that way instead. It won't stay up any longer than it takes for you to download it one time though.

    @nonesuch00 Yes, can you please DM me a link as well, if it is a better or more complete starting point that the repo? I am not really a competent Win32 developer, and even less a competent OSX developer, so it is going to be quite easy to get me to give up :) Getting closer to the goal line will be helpful.

  • takezo_3001takezo_3001 Posts: 1,948

    TheMysteryIsThePoint said:

     A few things:

    • It is based on the value of keeping some personally identifiable data secret being greater than the value of pirating the software. Many people don't want to give a company even their actual email address, to say nothing of data important enough to disuade them from sharing the program. A photo? That's Orwellian.
    • The pirated software could have been stolen from a legitimate user, without his knowledge, along with his PID. It's an unacceptable risk to require a user to spread his PID all over his system in ways he doesn't necessarily understand. And with this, the cost of being hacked is intensified with your PID distributed all over your system. The EFF would mount a veritable crusade against this.
    • The hackers will just hack this information as well. In cybersecurity circles, it is said to greatly favor the attacker because he only has to be "right" once, while the defenders have to be "right" all the time. It's an inherently losing proposition. The measures become increasingly intrusive and, in the end, you get hacked anyway.
    • How would a company authenticate this PID so that bogus data cannot be proffered in the way some people use 12345678 as a password? If it's a photo, how would the vendor know what I actually look like? The vendor probably doesn't even have the user's credit card info in unencrypted form.

    These are just things I've thought of off the top of my head. But I think it is actually a worse proposal than typical server-ping DRM in terms of inconveniencing that lawful party.

    Cool, thanks for this, I was pretty much brainstorming for a solution as mine was not set in stone, especially if there is a better one, but unfortunately, companies are too addicted to DRM that negatively affect paying customers, and ironically do not affect the pirates themselves, which is why a lot of otherwise honest consumers turn to piracy which contributes to the never-ending cycle of customers turning to piracy due to overbearing eventually ineffective DRM.

  • OmnifluxOmniflux Posts: 363

    @nonesuch00 Can I get a link as well? I've searched again and still cannot find a copy.

    I can now successfully rebuild a runnable version for Windows, but I don't have any of the Qt changes (or others that may be included).

  • nonesuch00nonesuch00 Posts: 17,944

    TheMysteryIsThePoint said:

    nonesuch00 said:

    danielbui78 said:

    Padone said:

    If I understand correctly from @danielbui78, it seems there's another open source plugin from daz to lux, so mac people may have an alternative.

    https://www.daz3d.com/forums/discussion/514376/iray-vs-luxcore-heads-to-heads-blind-comparison

    Just to clarify, there are compiled versions for both Windows and Mac.  Also: although it is a daz to lux plugin, it's not designed to be a drop-in replacement for Reality.  Instead, the goal is to be a drop-in replacement for the Iray Render engine.  The latest version is hardcoded for just LuxCore Render, but the older code base is still in place for LuxRender output.  Eventually, I'll re-enable the LuxRender pathway to allow people to choose between LuxRender or LuxCore.

    Find out more about it here: https://www.daz3d.com/forums/discussion/499531/open-source-release-daz-render-plugin-framework-with-yet-another-lux-plugin/p1

     

    Regarding the Reality End-Of-Life and open-source:  I've tried to get the source code to build, but have run into barriers trying to build or obtain the dependency libraries.  If someone has pre-compiled dependencies, then that would be a major step towards building the Reality plugin, modifying the source-code and ultimately removing the copy-protection system from the Reality plugin.

    I have downloaded what Paolo made available which includes the precompiled libraries and such if that's what you mean. Note: It's as is with no changes by me so you needn't ask if I changed anything from Paolo's original post at the online repository. It was posted on the internet at one of those commercial online CMS archival services unless it's been taken down since. If so, PM me and we can arrange for me to post you a USB fob with that original source.

    Actually, both development archives taken together amount to about 4GB which is small enough to upload to my MS OneDrive long enough for you to download if you are interested in obtaining it that way instead. It won't stay up any longer than it takes for you to download it one time though.

    @nonesuch00 Yes, can you please DM me a link as well, if it is a better or more complete starting point that the repo? I am not really a competent Win32 developer, and even less a competent OSX developer, so it is going to be quite easy to get me to give up :) Getting closer to the goal line will be helpful.

    OK, it's 4GB and upload speeds are quite slow compared to download speeds so give me some time to get it uploaded.

  • nonesuch00nonesuch00 Posts: 17,944
    edited November 2021

    Omniflux said:

    @nonesuch00 Can I get a link as well? I've searched again and still cannot find a copy.

    I can now successfully rebuild a runnable version for Windows, but I don't have any of the Qt changes (or others that may be included).

    OK, it's 4GB and upload speeds are quite slow compared to download speeds so give me some time to get it uploaded.

    A lot of it's pre-compiled & linked (source is included too for all of it I think) so that should save you a bit of time on setting up and checking the initial build environment.

    Personally in my opinion, if you are interested in future proofing it against further Windows security enhancements and bug fixes I'd strip out all the file transport using TCP/IP messaging. I'd also update it to be configurable with which version of LuxRender it can be used with. I think that it should be updated to be compatable with any version of LuxRender from 2020 on so all that a user must do is install LuxRender and point Reality at it and then a year from now after several LuxRender updates, the user just has to update Reality to point at the new version if there is more than one version. If there is only one version of LuxRender available, Reality knows to use that by looking in the Windows registry for apps (that's probably been made more secure and complex in Windows 10 & Windows 11 now too).

    Post edited by nonesuch00 on
  • nonesuch00nonesuch00 Posts: 17,944

    OK, it uploaded quicker than I thought it would.

    @danielbui78

    @TheMysteryIsThePoint

    @Omniflux

    I've send yall PMs with instructions on what I need to send you the links. There are two zip archives.

  • danielbui78danielbui78 Posts: 333

    nonesuch00 said:

    Gotcha: Microsoft has upgraded in Windows 10 in the past year it's networking and kernel to be more secure which actually broke my purchased and functioning Reality from the DAZ Store to be not any longer working. Reality uses TCP/IP messaging for sending the scenes so you'd need to update that messaging as well, unless I'm mistaken on what broke my Reality and goodness knows I've been mistaken many times before.

    I have an Windows 10 with latest updates working perfectly with the Reality DS version downloaded from the Daz Store.  I am having absolutely no issues with TCP/IP messaging. 

    The only crash I have found with Reality DS and modern Windows is due to newer versions of OpenCL.DLL from Khronos Group.  Reality DS tries to dynamically load the OpenCL.DLL at runtime instead of linking at build-time.  There is apparently some incompatibility between the Windows kernel and the newer versions of OpenCL.DLL that cause a memory exception error when trying to load it at runtime.  If your Reality DS is not working, you can verify that is your problem by putting a fake OpenCL.DLL right next to your Reality executable.  Just create an empty text file and rename it to OpenCL.DLL.  The RealityDS code will try to load it, get a error message back from Windows that it can't be loaded and then proceed normally without OpenCL support and no crashes.  The only feature loss is RealityDS will not be able to query your OpenCL devices, so you'll have to manually configure those options.  As long as you do not keep the fake OpenCL.dll in the same folder as the LuxRender executable, you will still be able to do GPU rendering without problems.

     

  • danielbui78danielbui78 Posts: 333

    nonesuch00 said:

    OK, it's 4GB and upload speeds are quite slow compared to download speeds so give me some time to get it uploaded.

    A lot of it's pre-compiled & linked (source is included too for all of it I think) so that should save you a bit of time on setting up and checking the initial build environment.

    If this is the same files as from sourceforge.net (https://sourceforge.net/projects/reality-plugin/) then I think it only comes with pre-compiled mac binaries and not Windows.  You probably do not need to host those files if they are just the same ones from the above sourceforge URL.  However, I have not been able to find the custom Qt-Reality source, so those will definitely be helpful.  Thanks!  If anyone has them, I would appreciate if someone could post pre-compiled Windows binaries of the dependency libraries and also updated CMake files.

    Personally in my opinion, if you are interested in future proofing it against further Windows security enhancements and bug fixes I'd strip out all the file transport using TCP/IP messaging. I'd also update it to be configurable with which version of LuxRender it can be used with. I think that it should be updated to be compatable with any version of

    Reality DS is already configurable to let you use any LuxRender version you choose.  Just configure the path to your luxrender executable from inside the Reality DS options panel.  I don't fully remember, but you may also need to rename the newer executables from luxcoreconsole.exe to luxconsole.exe and luxcoreui.exe to luxrender.exe.

    LuxRender from 2020 on so all that a user must do is install LuxRender and point Reality at it and then a year from now after several LuxRender updates, the user just has to update Reality to point at the new version if there is more than one version. If there is only one version of LuxRender available, Reality knows to use that by looking in the Windows registry for apps (that's probably been made more secure and complex in Windows 10 & Windows 11 now too).

    Are you talking about LuxCore Render instead of LuxRender?  That is a new code base that has significantly diverged from LuxRender source code.  The last version of LuxRender that I know about is version 1.6.  The latest LuxCore Render only has limited support for the original LuxRender scene files that Reality DS generates.

  • OmnifluxOmniflux Posts: 363

    If this is the same files as from sourceforge.net (https://sourceforge.net/projects/reality-plugin/) then I think it only comes with pre-compiled mac binaries and not Windows.  You probably do not need to host those files if they are just the same ones from the above sourceforge URL.  However, I have not been able to find the custom Qt-Reality source, so those will definitely be helpful.  Thanks!  If anyone has them, I would appreciate if someone could post pre-compiled Windows binaries of the dependency libraries and also updated CMake files.

    This archive appears to be complete, unlike the sourceforge repository.

  • nonesuch00nonesuch00 Posts: 17,944

    danielbui78 said:

    nonesuch00 said:

    OK, it's 4GB and upload speeds are quite slow compared to download speeds so give me some time to get it uploaded.

    A lot of it's pre-compiled & linked (source is included too for all of it I think) so that should save you a bit of time on setting up and checking the initial build environment.

    If this is the same files as from sourceforge.net (https://sourceforge.net/projects/reality-plugin/) then I think it only comes with pre-compiled mac binaries and not Windows.  You probably do not need to host those files if they are just the same ones from the above sourceforge URL.  However, I have not been able to find the custom Qt-Reality source, so those will definitely be helpful.  Thanks!  If anyone has them, I would appreciate if someone could post pre-compiled Windows binaries of the dependency libraries and also updated CMake files.

    Personally in my opinion, if you are interested in future proofing it against further Windows security enhancements and bug fixes I'd strip out all the file transport using TCP/IP messaging. I'd also update it to be configurable with which version of LuxRender it can be used with. I think that it should be updated to be compatable with any version of

    Reality DS is already configurable to let you use any LuxRender version you choose.  Just configure the path to your luxrender executable from inside the Reality DS options panel.  I don't fully remember, but you may also need to rename the newer executables from luxcoreconsole.exe to luxconsole.exe and luxcoreui.exe to luxrender.exe.

    LuxRender from 2020 on so all that a user must do is install LuxRender and point Reality at it and then a year from now after several LuxRender updates, the user just has to update Reality to point at the new version if there is more than one version. If there is only one version of LuxRender available, Reality knows to use that by looking in the Windows registry for apps (that's probably been made more secure and complex in Windows 10 & Windows 11 now too).

    Are you talking about LuxCore Render instead of LuxRender?  That is a new code base that has significantly diverged from LuxRender source code.  The last version of LuxRender that I know about is version 1.6.  The latest LuxCore Render only has limited support for the original LuxRender scene files that Reality DS generates.

    LuxCore Render I mean, thanks. The divergent projects with similar names confuses me. 

  • nonesuch00nonesuch00 Posts: 17,944

    Omniflux said:

    If this is the same files as from sourceforge.net (https://sourceforge.net/projects/reality-plugin/) then I think it only comes with pre-compiled mac binaries and not Windows.  You probably do not need to host those files if they are just the same ones from the above sourceforge URL.  However, I have not been able to find the custom Qt-Reality source, so those will definitely be helpful.  Thanks!  If anyone has them, I would appreciate if someone could post pre-compiled Windows binaries of the dependency libraries and also updated CMake files.

    This archive appears to be complete, unlike the sourceforge repository.

    I think they are complete but I can't remember which commercial public CMS repo I downloaded them from. Atlassian maybe? It wasn't GitHub or SourceForge.

  • nonesuch00nonesuch00 Posts: 17,944

    danielbui78 said:

    nonesuch00 said:

    Gotcha: Microsoft has upgraded in Windows 10 in the past year it's networking and kernel to be more secure which actually broke my purchased and functioning Reality from the DAZ Store to be not any longer working. Reality uses TCP/IP messaging for sending the scenes so you'd need to update that messaging as well, unless I'm mistaken on what broke my Reality and goodness knows I've been mistaken many times before.

    I have an Windows 10 with latest updates working perfectly with the Reality DS version downloaded from the Daz Store.  I am having absolutely no issues with TCP/IP messaging. 

    The only crash I have found with Reality DS and modern Windows is due to newer versions of OpenCL.DLL from Khronos Group.  Reality DS tries to dynamically load the OpenCL.DLL at runtime instead of linking at build-time.  There is apparently some incompatibility between the Windows kernel and the newer versions of OpenCL.DLL that cause a memory exception error when trying to load it at runtime.  If your Reality DS is not working, you can verify that is your problem by putting a fake OpenCL.DLL right next to your Reality executable.  Just create an empty text file and rename it to OpenCL.DLL.  The RealityDS code will try to load it, get a error message back from Windows that it can't be loaded and then proceed normally without OpenCL support and no crashes.  The only feature loss is RealityDS will not be able to query your OpenCL devices, so you'll have to manually configure those options.  As long as you do not keep the fake OpenCL.dll in the same folder as the LuxRender executable, you will still be able to do GPU rendering without problems.

    OK, so I was wrong it or Windows did patch the problem or it was OpenCL.DLL problem as you stated. I wasn't the only preson with the problem then so I knew it wasn't something I did on my machine. I've moved on from Windows 10 to Windows 11 and don't have the hardware or time to set up a Windows 10 machine.

    What I will do is once you get the source tree build environment setup if you want to share that, then I will set it up on my Windows 11 machine to be a build machine so I can test your changes on my machine with Windows 11 & an AMD Ryzen 7 5700G APU (it has the 5th generation GCN GPU architecture Vega 8 (8 because is has 8 GPU cores).

    I will avoid installing the DAZ Store version of Reality again on my new machine so I can be a beta tester of your non-DRM Reality when you are ready, if you decide to go that route.

  • VirgoRivalVirgoRival Posts: 47

    TheMysteryIsThePoint said:

    Padone said:

    @TheMysteryIsThePoint Donald, just thought you may be interested to help here. I don't use reality myself but for most mac users it may be the only option for gpu rendering inside daz studio. If they don't wish to export to blender I mean.

    Then I understand you have your own projects to deal with and this may be too much of a burden so it's just a head up in case you didn't notice.


    @Padone Sure. I'd be willing to take a look, but the original dev saying "I cannot do it." kind of scares me. I would think that removing the server comm logic from the client would be too trivial to even discuss, but if it really were, surely he would have already done it instead of locking out everyone who supported him over the last, what, 11 years.

    Before I say I'm willing to learn how to link a DS plugin on Mac, I'd like to know the whole story of what I'd be getting myself into, as I already don't have enough time to even work on Sagan the way I'd like to. Can we have some more details, specifically addressing why the original dev doesn't just do it and be done with it?

    I'm sympathetic to Mac users, though, after Apple screwed them. Can we have a show of hands? How many people depend on this?

     

    alil late to the show but I'd like to say i'm still using Reality-Luxrender as my primary means of rendering (because i'm stubborn and do not like Iray)
     even tho i'm not an Apple user and was unware this was even an issue for Apple users not being able to use GPU rendering (if i'm reading that right)

  • WendyLuvsCatzWendyLuvsCatz Posts: 37,924

    VirgoRival said:

    TheMysteryIsThePoint said:

    Padone said:

    @TheMysteryIsThePoint Donald, just thought you may be interested to help here. I don't use reality myself but for most mac users it may be the only option for gpu rendering inside daz studio. If they don't wish to export to blender I mean.

    Then I understand you have your own projects to deal with and this may be too much of a burden so it's just a head up in case you didn't notice.


    @Padone Sure. I'd be willing to take a look, but the original dev saying "I cannot do it." kind of scares me. I would think that removing the server comm logic from the client would be too trivial to even discuss, but if it really were, surely he would have already done it instead of locking out everyone who supported him over the last, what, 11 years.

    Before I say I'm willing to learn how to link a DS plugin on Mac, I'd like to know the whole story of what I'd be getting myself into, as I already don't have enough time to even work on Sagan the way I'd like to. Can we have some more details, specifically addressing why the original dev doesn't just do it and be done with it?

    I'm sympathetic to Mac users, though, after Apple screwed them. Can we have a show of hands? How many people depend on this?

     

    alil late to the show but I'd like to say i'm still using Reality-Luxrender as my primary means of rendering (because i'm stubborn and do not like Iray)
     even tho i'm not an Apple user and was unware this was even an issue for Apple users not being able to use GPU rendering (if i'm reading that right)

    well you won't be for much longer surprise 

  • WendyLuvsCatzWendyLuvsCatz Posts: 37,924

    I think the s&%t will really hit the fan when the server goes down and a lot of people using it who do not visit the forum suddenly find it not working.

  • VirgoRivalVirgoRival Posts: 47

    WendyLuvsCatz said:

    I think the s&%t will really hit the fan when the server goes down and a lot of people using it who do not visit the forum suddenly find it not working.

    YEAH I didn't even think of that

    I manage to hear about this from someone else when i was talking about how i use Luxrender over Iray
    and they kinda just "oh yea this is happening" and linked me here

    been freaking out ever since 


    I see there is an attempt to get a plug in going with LuxCoreRender which looks promising

    But i love the fuctionality of Reality over built in plug ins so i hope everyone here gets something going with it
    other wise i'll be moving over to the yalux plugin 



    oh and i have found a work around with Reality by Keeping my RX580 plug in with my new 3060TI
    But i'm not sure what i'm reading about the fix for what is causing Reality to crash
    Something about the opencl.dll

    if someone wants to clear that up, i would LOVE to pull out my AMD card and uninstall the drivers so they can stop conflicting with my Nvidia drivers

  • StratDragonStratDragon Posts: 3,167

    When Reailty came out it was a total game changer. The work you did on this plug-in motivated me to explore many other 3D apps. I'm saddened to see it go. Best of luck.

  • MasterstrokeMasterstroke Posts: 1,820
    edited December 2021

    Thanks to Paolo, for giving me the first glimpse of what a PBR render world would look like.

    I do think, Paolo has started a trend and without his effort, we would not have an IRay or the Octane plug in for DAZ studio and no Superfly or Octane plug in for Poser either.
    I don't have any need for the Reality plug in anymore, but it has been a game changer for sure, so I am higly greatful, that we had it.

    Post edited by Masterstroke on
  • pcicconepciccone Posts: 661

     


    @Padone Sure. I'd be willing to take a look, but the original dev saying "I cannot do it." kind of scares me. I would think that removing the server comm logic from the client would be too trivial to even discuss, 

    I want to clarify this. The modification is trivial but then you need to recompile the program and that is not simple. So many things have changed since 5 years ago that it would take me days and days to recreate the environment. Reality is a program that compiles both on Windows and Mac. Tell you the truth, I don't use Macs anymore and so that part is particularly difficult. I just don't have the time to set up the development environment, which will require a whole set of updates. It would inflict a substantial economic damage to my current business and that is something I simply cannot afford.

    Hope this clarifies the situation.

     

    Cheers

  • pcicconepciccone Posts: 661

    I want to thank everybody for your words of support, they mean the world to me. Times and renderers change :) and I had a great time in this community and am very grateful for your support. We did all together put a little "dent" in the world and that is extra cool. 

    BTW, I am quite involved with Unreal, not as a developer but as a user, and that stuff is simply incredible. If you didn't try it yet, I would suggest that you look into it.

    Cheers!

  • pcicconepciccone Posts: 661

     

    What I will do is once you get the source tree build environment setup if you want to share that, then I will set it up on my Windows 11 machine to be a build machine so I can test your changes on my machine with Windows 11 & an AMD Ryzen 7 5700G APU (it has the 5th generation GCN GPU architecture Vega 8 (8 because is has 8 GPU cores).

    I will avoid installing the DAZ Store version of Reality again on my new machine so I can be a beta tester of your non-DRM Reality when you are ready, if you decide to go that route.

    That is very cool. I will be available to help you make sense of all the details of the build system. If you need to contact me directly, use [email protected]

     

  • pcicconepciccone Posts: 661

     

    Gotcha: Microsoft has upgraded in Windows 10 in the past year it's networking and kernel to be more secure which actually broke my purchased and functioning Reality from the DAZ Store to be not any longer working. Reality uses TCP/IP messaging for sending the scenes so you'd need to update that messaging as well, unless I'm mistaken on what broke my Reality and goodness knows I've been mistaken many times before.

     

    Correct. Reality is divided into two pieces: the UI, which is the same for DS and Poser and any other possible host and the rendering interface that exports the scene to Lux and runs the renderer. Because it makes no sense to duplicate the UI for each host, the solution was found to use message passing to communicate between the UI and the backend. We need to remember that the UI is designed to be a material editor, not just a launcher. The workflow is:

    • Capture events from the host (DS/Poser) and intercept all material modifications
    • Convert the materials from the host's format to Reality's
    • Load the materials in the editor
    • The material definitions are kept in the backend, the plugin that runs inside the host. When the editor changes anything, messages are sent to the backend to update the internal database
    • When asked to render, the UI sends the message to the backend which, in turn, scans the scene in the memory of the host, exports it to Lux's format, and pairs the material definitions in the process.

    This is a rough description. Keep in mind a couple of points:

    • Reality is designed to be general. It supports DS and Poser but it can easily be integrated in Modo, Max, Blender, etc by writing a rather thin plugin to interface into the host
    • The renderer is also abstracted. Reality is heavily influenced by Lux but there are C++ classes to abstract the renderer as well.

    Any questions you might have about it, please email me at [email protected]

    Cheers

  • nonesuch00nonesuch00 Posts: 17,944
    edited December 2021

    pciccone said:

     

    What I will do is once you get the source tree build environment setup if you want to share that, then I will set it up on my Windows 11 machine to be a build machine so I can test your changes on my machine with Windows 11 & an AMD Ryzen 7 5700G APU (it has the 5th generation GCN GPU architecture Vega 8 (8 because is has 8 GPU cores).

    I will avoid installing the DAZ Store version of Reality again on my new machine so I can be a beta tester of your non-DRM Reality when you are ready, if you decide to go that route.

    That is very cool. I will be available to help you make sense of all the details of the build system. If you need to contact me directly, use [email protected]

     

    Thank you. I will definately help if DanielBui asks (many devs like to go into a "all alone work mode" which I understand completely, it's not easy and it's error prone in any circumstance) but I, like you, am even rustier in development and integrating all the pieces of these large build enviroments but I'm starting now, just in case he does want extra help. Like you, it's not that I can't, it's that I haven't in a even longer while and it's a big undertaking.

    Post edited by nonesuch00 on
  • VirgoRivalVirgoRival Posts: 47

    Between Reality and YaLuxPlugin

    I honestly want Reality to continue and hope someone acutally picks it up to continue developing for it (if only to fix and or address some old issues i have with it lol)

    My attempts to use YaLuxPlugin has...not given me any confidence and I wish to continue to use LuxRender 1.6 if it means I can have more control 


    as much i'm sure people like having the engine built into Daz
    being able to acutally USE Daz while a scene is rendering to make adjustments as i see fit to get that quality out of my renders is the reason why i stuck with Reality/Luxrender for so long

    Rendering times of course are nightmarish
    I love having the scene files to go back to if needed for whatever reason
    some gripes i still have with Reality, but i Much prefer its workflow over Iray

    So i hope this issue can be resolved
    (and was still hoping for a response to my question about the opencl.dll fix, i think i understand but i don't want to break my reality attempting to pull my card out again o n o;)

    that being said, I really do appreciate Paolo for Reality as it has proved me my artistic outlet for this last few years and owe my success to him 

     - Rivaliant

  • pcicconepciccone Posts: 661

    Hello.

    Quick update. OmniFlux has offered to purchase the Preta3d.com domain and to continue running it for the time being. I will need some time to figure out all the details and make sure that nothing confidential is left around but we have a contingency plan so Reality should be able to continue running well past the March deadline.

    Thank you very much OmnuFlux for doing this.

    Cheers

     

  • nonesuch00nonesuch00 Posts: 17,944

    pciccone said:

    Hello.

    Quick update. OmniFlux has offered to purchase the Preta3d.com domain and to continue running it for the time being. I will need some time to figure out all the details and make sure that nothing confidential is left around but we have a contingency plan so Reality should be able to continue running well past the March deadline.

    Thank you very much OmnuFlux for doing this.

    Cheers

    Thank you Paolo & Omniflux.

Sign In or Register to comment.