Daz Studio Pro BETA - version 4.21.0.5! (*UPDATED*)

123578

Comments

  • wsterdanwsterdan Posts: 1,810

    Richard Haseltine said:

    Reinstating (almost) transparent lights that don't reflect (it's the latter that is currently the big issue) is not something Daz has any control over - if they did I would be pretty sure they would reinstate them.

    Prorender came out after Iray was integrated into Daz Studio, and was much less feature-rich than iray for a long time - I don't know it's current status, but it certainly doesn't seem to have much momentum. Changing render engines now would break a lot more than ghost lights, I can't believe it would be the lesser evil (and there is nothing to stop an interested developer from using the SDK to integrate any renderer with a published API).

    I don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.

    -- Walt Sterdan

  • wsterdan said:

    Richard Haseltine said:

    Reinstating (almost) transparent lights that don't reflect (it's the latter that is currently the big issue) is not something Daz has any control over - if they did I would be pretty sure they would reinstate them.

    Prorender came out after Iray was integrated into Daz Studio, and was much less feature-rich than iray for a long time - I don't know it's current status, but it certainly doesn't seem to have much momentum. Changing render engines now would break a lot more than ghost lights, I can't believe it would be the lesser evil (and there is nothing to stop an interested developer from using the SDK to integrate any renderer with a published API).

    I don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.

    -- Walt Sterdan

    That's never going to happen in any convenient way because of the incompatible licenses under which both Cycles and EEVEE are made available. Graunching the two together would violate the spirit, if not the letter of the license.

    But as for converters, we've already got a pretty darned good one by our very own Thomas Larsson and Padone. It's call the Diffeomorphic DAZ Importer. It is really, really good and most of the time one does not have to modify the converted materials at all. I don't think it's going to get any easier than these gentlemen have already made it.

     

  • wsterdanwsterdan Posts: 1,810

    TheMysteryIsThePoint said:

    wsterdan said:

    I don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.

    -- Walt Sterdan

    That's never going to happen in any convenient way because of the incompatible licenses under which both Cycles and EEVEE are made available. Graunching the two together would violate the spirit, if not the letter of the license.

    Thanks for clarifying; I (wrongly, I guess) assumed that Cycles at least -- using the Apache LIcense Version 2.0 -- could be used  in open source and commercial applications, as a version is still currently being used in Poser. I see that Evee is a different animal of license completely (GPL3), and is also entangled pretty deeply with Blender code itself.

    -- Walt Sterdan

  • wsterdan said:

    TheMysteryIsThePoint said:

    wsterdan said:

    I don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.

    -- Walt Sterdan

    That's never going to happen in any convenient way because of the incompatible licenses under which both Cycles and EEVEE are made available. Graunching the two together would violate the spirit, if not the letter of the license.

    Thanks for clarifying; I (wrongly, I guess) assumed that Cycles at least -- using the Apache LIcense Version 2.0 -- could be used  in open source and commercial applications, as a version is still currently being used in Poser. I see that Evee is a different animal of license completely (GPL3), and is also entangled pretty deeply with Blender code itself.

    -- Walt Sterdan

    Yes, you're right about Cycles; that's a pretty good example of violating the spirit. The GPL2/3 basically says that you cannot link GPL software with proprietary software. That provision is supposed to encourage the development of more GPLed software, and with sound reasoning: If your software benefited greatly from the existing Open Source software made available to you, your software, which also creates some new functionality ostensibly useful to others, it should in turn also be Open Source (the LGPL is a special case for software intended to be distributed as a library). Need a penny, take a penny, have a penny, leave a penny. Makes sense to me.

    But developers took no time to find the loophole: they just don't link the GPL software with the proprietary to make a single executable. They keep the two separate and have them communicate with each other over a local socket or some other form of inter-process communication, of which POSIX.1 has many. In that way, the developers benefit from an enormous body of quality software for free, but they don't contribute anything at all back to the community that produced it. That is not what Richard M. Stallman had in mind, but you see it being done everywhere.

     

  • wsterdanwsterdan Posts: 1,810

    TheMysteryIsThePoint said:

    wsterdan said:

    TheMysteryIsThePoint said:

    wsterdan said:

    I don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.

    -- Walt Sterdan

    That's never going to happen in any convenient way because of the incompatible licenses under which both Cycles and EEVEE are made available. Graunching the two together would violate the spirit, if not the letter of the license.

    Thanks for clarifying; I (wrongly, I guess) assumed that Cycles at least -- using the Apache LIcense Version 2.0 -- could be used  in open source and commercial applications, as a version is still currently being used in Poser. I see that Evee is a different animal of license completely (GPL3), and is also entangled pretty deeply with Blender code itself.

    -- Walt Sterdan

    Yes, you're right about Cycles; that's a pretty good example of violating the spirit. The GPL2/3 basically says that you cannot link GPL software with proprietary software. That provision is supposed to encourage the development of more GPLed software, and with sound reasoning: If your software benefited greatly from the existing Open Source software made available to you, your software, which also creates some new functionality ostensibly useful to others, it should in turn also be Open Source (the LGPL is a special case for software intended to be distributed as a library). Need a penny, take a penny, have a penny, leave a penny. Makes sense to me.

    But developers took no time to find the loophole: they just don't link the GPL software with the proprietary to make a single executable. They keep the two separate and have them communicate with each other over a local socket or some other form of inter-process communication, of which POSIX.1 has many. In that way, the developers benefit from an enormous body of quality software for free, but they don't contribute anything at all back to the community that produced it. That is not what Richard M. Stallman had in mind, but you see it being done everywhere.

     

    Thanks again, very much for breaking it down so clearly for me; the time you spend helping me better understand is very much apprecaited. Thanks as well for your patience.

    -- Walt Sterdan 

  • wsterdan said:

    TheMysteryIsThePoint said:

    wsterdan said:

    TheMysteryIsThePoint said:

    wsterdan said:

    I don't use iRay or want photorealism at all, but I do think that adding Cycles (and possibly Evee) would be a good move for DAZ. I (possibly wrongly) assume that creating converters between iRay and Cycles would be easier that's iRay to 3DL, it would allow people using both Blender and DAZ to work more freely, and using an actively-supported, open-source render engine wouldn't tie DAZ to any hardware manufacture's whims. I think it would open up DAZ users to more choices, while still letting iRay junkies get their fix.

    -- Walt Sterdan

    That's never going to happen in any convenient way because of the incompatible licenses under which both Cycles and EEVEE are made available. Graunching the two together would violate the spirit, if not the letter of the license.

    Thanks for clarifying; I (wrongly, I guess) assumed that Cycles at least -- using the Apache LIcense Version 2.0 -- could be used  in open source and commercial applications, as a version is still currently being used in Poser. I see that Evee is a different animal of license completely (GPL3), and is also entangled pretty deeply with Blender code itself.

    -- Walt Sterdan

    Yes, you're right about Cycles; that's a pretty good example of violating the spirit. The GPL2/3 basically says that you cannot link GPL software with proprietary software. That provision is supposed to encourage the development of more GPLed software, and with sound reasoning: If your software benefited greatly from the existing Open Source software made available to you, your software, which also creates some new functionality ostensibly useful to others, it should in turn also be Open Source (the LGPL is a special case for software intended to be distributed as a library). Need a penny, take a penny, have a penny, leave a penny. Makes sense to me.

    But developers took no time to find the loophole: they just don't link the GPL software with the proprietary to make a single executable. They keep the two separate and have them communicate with each other over a local socket or some other form of inter-process communication, of which POSIX.1 has many. In that way, the developers benefit from an enormous body of quality software for free, but they don't contribute anything at all back to the community that produced it. That is not what Richard M. Stallman had in mind, but you see it being done everywhere.

     

    Thanks again, very much for breaking it down so clearly for me; the time you spend helping me better understand is very much apprecaited. Thanks as well for your patience.

    -- Walt Sterdan 

    No problem, Walt. I often enjoy the clarity and reasoning in your posts.

  • Richard HaseltineRichard Haseltine Posts: 86,009

    This isn't a thread on license terms, it is a thread principally about a specific version of Daz Studio.

  • Richard Haseltine said:

    Reinstating (almost) transparent lights that don't reflect (it's the latter that is currently the big issue) is not something Daz has any control over - if they did I would be pretty sure they would reinstate them.

    I am not talking about reinstating "buggy" behavior of ghostlights -- it is obvious that Daz cannot do that on their own.

    I was asking whether Daz can implement fully invisible lights using Iray SDK?

    If Iray SDK does not support creation of such light sources (and I would be really surprised to hear it doesn't), then Daz should submit a feature request to NVIDIA Iray team.

    Then, if NVIDIA refuses to get their professional rendering engine up to par with other rendering engines used by other DCCs which all support such functionality, Daz should consider switching the rendering engine.

    Prorender came out after Iray was integrated into Daz Studio, and was much less feature-rich than iray for a long time - I don't know it's current status, but it certainly doesn't seem to have much momentum. Changing render engines now would break a lot more than ghost lights, I can't believe it would be the lesser evil (and there is nothing to stop an interested developer from using the SDK to integrate any renderer with a published API).

    ProRender seems very close to feature-complete, and it is already available in Maxxon Cinema 4D, and also as a free plugin for 3DS Max, Maya, Blender, and even Unreal Engine (which I am sure would be interesting to many people using Daz Studio who are interested in making games).

    I am aware that the breakage would be much more significant, but at least it would come with some palpable benefits (acceleration on any GPU, Mac on Arm support, open-source) unlike the recent Iray updates.

  • Torquinox said:

    The easiest and most logical "fix" in terms of keeping people happy and productive is to keep previous versions of DS available for download. Even Blender has watershed moments where major features and functionality were removed in favor of easier maintenance and progress, but you can still download versions of Blender that have those features.

    Sadly, that is only a partial solution.

    As the video drivers get updated, old versions of Daz Studio are inevitably going to either produce artifacts (for example Daz Studio 4.16.0.3 and NVIDIA driver 516.93), or outright stop working or start crashing at some time in the future.

    One thing I do agree is that Daz should offer at least one earlier release version for download -- for example 4.16.0.3 and whatever is the current release version. Also, incompatibility with existing assets (if any) should be prominently noted on the download page.

  • prixatprixat Posts: 1,491

    Maxon dropped ProRender from Cinema, 2 versions ago. It may return as, yet another plugin renderer, if AMD gets round to developing it.

  • nicsttnicstt Posts: 11,714

    Richard Haseltine said:

    nicstt said:

    Richard Haseltine said:

    Taoz said:

    Are DS Beta's time limited or can the installers be saved and installed later at any time?

    They can be installed and used at any time, but if they have been superseded you will need to be working with DIM offline or it will see the newer version and want to download and install that rather than the older version.

    Or save em for as long as you want.

    or?

    Good catch.

    I probably meant something like copy the installed folder as it can be used as long as needed if renamed.

  • Richard HaseltineRichard Haseltine Posts: 86,009

    johndoe_36eb90b0 said:

    Richard Haseltine said:

    Reinstating (almost) transparent lights that don't reflect (it's the latter that is currently the big issue) is not something Daz has any control over - if they did I would be pretty sure they would reinstate them.

    I am not talking about reinstating "buggy" behavior of ghostlights -- it is obvious that Daz cannot do that on their own.

    I was asking whether Daz can implement fully invisible lights using Iray SDK?

    If Iray SDK does not support creation of such light sources (and I would be really surprised to hear it doesn't), then Daz should submit a feature request to NVIDIA Iray team.

    Then, if NVIDIA refuses to get their professional rendering engine up to par with other rendering engines used by other DCCs which all support such functionality, Daz should consider switching the rendering engine.

    Apparently there are suitable atributes listed for iray to make a light invisible to secondary rays (relfections and so on - as I said, that is the problematic bit) but the Iray Programmers Manual says they are ignored and Daz' testing confirmed it (so yes, they did try to do this).

    Prorender came out after Iray was integrated into Daz Studio, and was much less feature-rich than iray for a long time - I don't know it's current status, but it certainly doesn't seem to have much momentum. Changing render engines now would break a lot more than ghost lights, I can't believe it would be the lesser evil (and there is nothing to stop an interested developer from using the SDK to integrate any renderer with a published API).

    ProRender seems very close to feature-complete, and it is already available in Maxxon Cinema 4D, and also as a free plugin for 3DS Max, Maya, Blender, and even Unreal Engine (which I am sure would be interesting to many people using Daz Studio who are interested in making games).

    I am aware that the breakage would be much more significant, but at least it would come with some palpable benefits (acceleration on any GPU, Mac on Arm support, open-source) unlike the recent Iray updates.

  • Richard Haseltine said:

    johndoe_36eb90b0 said:

    Richard Haseltine said:

    Reinstating (almost) transparent lights that don't reflect (it's the latter that is currently the big issue) is not something Daz has any control over - if they did I would be pretty sure they would reinstate them.

    I am not talking about reinstating "buggy" behavior of ghostlights -- it is obvious that Daz cannot do that on their own.

    I was asking whether Daz can implement fully invisible lights using Iray SDK?

    If Iray SDK does not support creation of such light sources (and I would be really surprised to hear it doesn't), then Daz should submit a feature request to NVIDIA Iray team.

    Then, if NVIDIA refuses to get their professional rendering engine up to par with other rendering engines used by other DCCs which all support such functionality, Daz should consider switching the rendering engine.

    Apparently there are suitable atributes listed for iray to make a light invisible to secondary rays (relfections and so on - as I said, that is the problematic bit) but the Iray Programmers Manual says they are ignored and Daz' testing confirmed it (so yes, they did try to do this).

    Interesting... are you referring to these attributes that should be possible to set on any scene object (supposedly on lights too)?

    • bool reflection_cast
      The object is visible as a reflection in reflective objects.
    • bool reflection_recv
      The object is reflective.
    • bool refraction_cast
      The object is visible through refractive objects.
    • bool refraction_recv
      The object is refractive.
    • bool shadow_cast
      The object casts shadows.
    • bool shadow_recv
      The object can have shadows cast onto it.

    They are described here (under Attributes heading). If that is what they tested, then perhaps it didn't work due to attribute inheritance? If I had access to Iray SDK I would try to create a simple scene with built-in light source (such as point light or spotlight) and set those on it to see what happens and I would also try to disable attribute inheritance on that node just to be sure.

  • outrider42outrider42 Posts: 3,302

    Richard Haseltine said:

    panorios1 said:

    Torquinox said:

    The easiest and most logical "fix" in terms of keeping people happy and productive is to keep previous versions of DS available for download. Even Blender has watershed moments where major features and functionality were removed in favor of easier maintenance and progress, but you can still download versions of Blender that have those features.

    I think this is the best solution, release a second version with minor upgrades overtime that is working just like it used to.

    That would slow down development overall, as the team would be trying to juggle different versions - and also ignores the fact that some "minor fixes" are in fact anything but minor and would have just as much potential to break something as a more significant update. And again, we do not know anything about the agreement between Daz and nVidia and so have no idea what constraints daz may be working under (nor do we know how much liberty they have to discuss their agreement with nVidi

    For people using Daz for work, it is a nightmare if a client ask them to make a minor adjustment in an old file. I completely understand  that the software needs to go further, and some sacrifices are expected, but having an alternative is not a big deal.

    We can shoot this down, but what is the deal with simply providing a fallback version of Studio? If you cannot guarrantee that an update will break a product, then the obvious moral thing to do is to offer the previous version where that product worked correctly. It should be a standard obligation.

    Studio is only around 450MB in size. We have new hairs, characters, environments, and all sort of things that exceed that number. I have shader packs that are well over 1GB in size. There should be no issue with having an old version on a server. It doesn't even have to be on the best server.

    Also there was mention that previous versions of Daz before 4 were still available for download, and assurances that after DS5 releases, a version of 4 would still remain. If this is the case, what is preventing Daz from keeping a previous version of 4.x available? Why are things handled this way? It is maddening how the current policy is.

    Also, I saw on July 22 the Iray Dev Blog posted they released a new version 2021.1.6 for bugfixes. But I don't see a changelog that offers any details. Do we have any details for what this means, and when Studio might get it?

  • DoctorJellybeanDoctorJellybean Posts: 6,517
    edited July 30

    outrider42 said:

    Also, I saw on July 22 the Iray Dev Blog posted they released a new version 2021.1.6 for bugfixes. But I don't see a changelog that offers any details. Do we have any details for what this means, and when Studio might get it?

     

    NVIDIA Iray change log, which is in the current Public Beta (4.20.1.58) release.

    Post edited by DoctorJellybean on
  • Richard HaseltineRichard Haseltine Posts: 86,009

    johndoe_36eb90b0 said:

    Richard Haseltine said:

    johndoe_36eb90b0 said:

    Richard Haseltine said:

    Reinstating (almost) transparent lights that don't reflect (it's the latter that is currently the big issue) is not something Daz has any control over - if they did I would be pretty sure they would reinstate them.

    I am not talking about reinstating "buggy" behavior of ghostlights -- it is obvious that Daz cannot do that on their own.

    I was asking whether Daz can implement fully invisible lights using Iray SDK?

    If Iray SDK does not support creation of such light sources (and I would be really surprised to hear it doesn't), then Daz should submit a feature request to NVIDIA Iray team.

    Then, if NVIDIA refuses to get their professional rendering engine up to par with other rendering engines used by other DCCs which all support such functionality, Daz should consider switching the rendering engine.

    Apparently there are suitable atributes listed for iray to make a light invisible to secondary rays (relfections and so on - as I said, that is the problematic bit) but the Iray Programmers Manual says they are ignored and Daz' testing confirmed it (so yes, they did try to do this).

    Interesting... are you referring to these attributes that should be possible to set on any scene object (supposedly on lights too)?

    • bool reflection_cast
      The object is visible as a reflection in reflective objects.
    • bool reflection_recv
      The object is reflective.
    • bool refraction_cast
      The object is visible through refractive objects.
    • bool refraction_recv
      The object is refractive.
    • bool shadow_cast
      The object casts shadows.
    • bool shadow_recv
      The object can have shadows cast onto it.

    They are described here (under Attributes heading). If that is what they tested, then perhaps it didn't work due to attribute inheritance? If I had access to Iray SDK I would try to create a simple scene with built-in light source (such as point light or spotlight) and set those on it to see what happens and I would also try to disable attribute inheritance on that node just to be sure.

    I wasn't given details, but both the Iray prorammers' manual and Daz testing show that some or all of the attributes in question are (currently) ignored.

  • Richard Haseltine said:

    I wasn't given details, but both the Iray prorammers' manual and Daz testing show that some or all of the attributes in question are (currently) ignored.

    Having those details would help getting to the bottom of the issue.

    Regardless, I passed this information to NVIDIA and I was told that if Daz needs some functionality in Iray they should just approach Iray team and ask for it if they haven't already.

  • HellcatHellcat Posts: 98

    guess i won't be installing this or any upgrade in the future if i have to keep using that stupid install manager. i miss just being able to directly download and install and not have things hang and crash

  • Richard HaseltineRichard Haseltine Posts: 86,009

    Hellcat said:

    guess i won't be installing this or any upgrade in the future if i have to keep using that stupid install manager. i miss just being able to directly download and install and not have things hang and crash

    This is a beta, those have always required Install Manager. The General Release can still be installed directly.

  • MattymanxMattymanx Posts: 6,742

    Hellcat said:

    guess i won't be installing this or any upgrade in the future if i have to keep using that stupid install manager. i miss just being able to directly download and install and not have things hang and crash

     

    You dont have to let DIM install it for you.  You can just download the ZIP file and install it manually if you wish.

  • JD_MortalJD_Mortal Posts: 747

    outrider42 said:

    ... Longer render times takes more iterations... various issues...

    In the past, IRAY has tweaked "convergence" before. The result will usually be longer render-times, which results in more iterations before it is "equally as complete as it was in the past". In the past, it may have thought it was 98% complete convergence at 4000 iterations, but in a new formula, they may have determined it needed 6000 iterations to be 98% complete convergence. That will obviously also take more time.

    For quality, you NEED to set a forced iteration count to stop at, not use convergence comparison, unless you want to test how accurate convergence is. For quality, that stopping point at XXXX iteration is what you want to compare.

    For the record, an image with "more colors" does not equal "more noise". There could just be better sub-pixel processing, resulting in more variance of gradients. Having 200 steps between white and black can have the same amount of noise as an image which has 500 steps between white and black gradients.

    No cure for bad seams, except to increase resolution and down-sample the "cracks", if possible... or increase the "blur", of the rendering quality blending, which is already rather high. The more accurate rendering gets, the more that these minor imperfections will become more visible. It's like comparing old TV to a 4K screen, where you can now see pores on everyone's noses and faces. On old TV sets, everyone looked like smooth plastic. No pores in sight, no wrinkles, no eye baggage, etc.

    When it comes to iterations, As a generic rule of thumb, I force a minimum of 1500, or reflections just don't render correct. For a maximum, on a standard image, I have my iteration count to around 5000. For a real good HD image, I might force it to try and reach 20,000 iterations, or just render 4x larger at 5000 iterations. (An 8K image reduced to a 4K image, or a 4K image reduced to 1080p)

  • vozolgantvozolgant Posts: 207
    edited August 4

    EDIT: What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    I have CPU turned off in DAZ. I only allow IRAY GPU renders. If the memory goes over 4gb in anyway, sometimes it will cause the renderer to disable permanently, and the only way to fix it is to restart DAZ.  However, sometimes if I leave it for like 60 seconds, I can get it to work again; but the problem is this process is too time consuming. Has this problem been fixed?

    Basically, this is how it should work, god I hope the DAZ devs see this:

    1. When you do a render, it should show you precisely how much memory is being used in the video card. If there's not enough video card memory, it should communicate this information to you in the most clearest manner possible. You should be able to guessestimate this based upon what assets are in DAZ; maybe there's already a way to show how much memory is being used based on what assets you have in your scene?

    2. When you hide or show clothing or characters, the required video card memory should update in the top or right corner of the DAZ screen.  

    What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    Let's say you have 4gb of video card memory, but your scene requires 5gb of memory.  It should show what assets are taking up the most memory in the scene, in the viewport itself; a setting that can be turned on/off.   Then I can easily hide/fix the assets with the most inefficient texture sizes.



     

    Post edited by vozolgant on
  • Richard HaseltineRichard Haseltine Posts: 86,009
    edited August 4

    vozolgant said:

    EDIT: What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    I have CPU turned off in DAZ. I only allow IRAY GPU renders. If the memory goes over 4gb in anyway, sometimes it will cause the renderer to disable permanently, and the only way to fix it is to restart DAZ.  However, sometimes if I leave it for like 60 seconds, I can get it to work again; but the problem is this process is too time consuming. Has this problem been fixed?

    Basically, this is how it should work, god I hope the DAZ devs see this:

    1. When you do a render, it should show you precisely how much memory is being used in the video card. If there's not enough video card memory, it should communicate this information to you in the most clearest manner possible. You should be able to guessestimate this based upon what assets are in DAZ; maybe there's already a way to show how much memory is being used based on what assets you have in your scene?

    2. When you hide or show clothing or characters, the required video card memory should update in the top or right corner of the DAZ screen.  

    What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    Let's say you have 4gb of video card memory, but your scene requires 5gb of memory.  It should show what assets are taking up the most memory in the scene, in the viewport itself; a setting that can be turned on/off.   Then I can easily hide/fix the assets with the most inefficient texture sizes.

    Daz Studio doesn't know how much memory a scene will take when transferred to Iray, so this isn't possible.

    Post edited by Richard Haseltine on
  • vozolgantvozolgant Posts: 207

    Richard Haseltine said:

    vozolgant said:

    EDIT: What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    I have CPU turned off in DAZ. I only allow IRAY GPU renders. If the memory goes over 4gb in anyway, sometimes it will cause the renderer to disable permanently, and the only way to fix it is to restart DAZ.  However, sometimes if I leave it for like 60 seconds, I can get it to work again; but the problem is this process is too time consuming. Has this problem been fixed?

    Basically, this is how it should work, god I hope the DAZ devs see this:

    1. When you do a render, it should show you precisely how much memory is being used in the video card. If there's not enough video card memory, it should communicate this information to you in the most clearest manner possible. You should be able to guessestimate this based upon what assets are in DAZ; maybe there's already a way to show how much memory is being used based on what assets you have in your scene?

    2. When you hide or show clothing or characters, the required video card memory should update in the top or right corner of the DAZ screen.  

    What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    Let's say you have 4gb of video card memory, but your scene requires 5gb of memory.  It should show what assets are taking up the most memory in the scene, in the viewport itself; a setting that can be turned on/off.   Then I can easily hide/fix the assets with the most inefficient texture sizes.

    Daz Studio doesn't know how much memory a scene will take when transferred to Iray, so this isn't possible.

    Let's say my current scene can't fit into video card memory.  Obviously I'm going to start hiding everything in the scene until the render works.  But here's the problem, even if I hide everything in the scene except the character, it just won't render until I restart DAZ Studio.  Has this been fixed in the beta version?

  • Richard HaseltineRichard Haseltine Posts: 86,009

    vozolgant said:

    Richard Haseltine said:

    vozolgant said:

    EDIT: What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    I have CPU turned off in DAZ. I only allow IRAY GPU renders. If the memory goes over 4gb in anyway, sometimes it will cause the renderer to disable permanently, and the only way to fix it is to restart DAZ.  However, sometimes if I leave it for like 60 seconds, I can get it to work again; but the problem is this process is too time consuming. Has this problem been fixed?

    Basically, this is how it should work, god I hope the DAZ devs see this:

    1. When you do a render, it should show you precisely how much memory is being used in the video card. If there's not enough video card memory, it should communicate this information to you in the most clearest manner possible. You should be able to guessestimate this based upon what assets are in DAZ; maybe there's already a way to show how much memory is being used based on what assets you have in your scene?

    2. When you hide or show clothing or characters, the required video card memory should update in the top or right corner of the DAZ screen.  

    What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    Let's say you have 4gb of video card memory, but your scene requires 5gb of memory.  It should show what assets are taking up the most memory in the scene, in the viewport itself; a setting that can be turned on/off.   Then I can easily hide/fix the assets with the most inefficient texture sizes.

    Daz Studio doesn't know how much memory a scene will take when transferred to Iray, so this isn't possible.

    Let's say my current scene can't fit into video card memory.  Obviously I'm going to start hiding everything in the scene until the render works.  But here's the problem, even if I hide everything in the scene except the character, it just won't render until I restart DAZ Studio.  Has this been fixed in the beta version?

    This is a limitation of Iray, not something Daz can fix.

  • jbowlerjbowler Posts: 639
    edited August 6

    vozolgant said:

    EDIT: What i'm proposing is a video card memory manager that is constantly displayed in the viewport., that's constantly updated based upon the visibile state of clothing, characters, props, etc.

    Use Tech GPU-Z; it's a separate window but it shows you in real time how much memory is being used on the graphics card.

    Don't blame DAZ; CHECK YOUR BROWSER.  It will swamp your graphics card; I just discovered that Brave (a hacked Chrome) was using 1.6GByte of my 12GByte TitanXP and yet the monitor the browser is using is not connected to the TitanXP (no monitor is connected to it).  I've previously had this problem with the mud people, but I managed to deconifgure them.  In this case I had to find "Settings/System/User hardware acceleration when available" and now my XP is back to it's standard 142MByte with no clients.

    Starting DAZStudio bumps that to 315MByte (not in Iray preview), so I assume that 150Mbyte is the connection cost (duh, when I first started developing UNIX the computer I used had 4MByte of DRAM, end.)  Starting an Iray preview (of a scene with just the tonemapping and environment nodes) bumps me to 2.5GByte.  Here's the skinny:

    2022-08-05 18:48:33.003 Iray [INFO] - IRAY:RENDER ::   1.11  IRAY   rend info : CUDA device 0 (NVIDIA TITAN Xp): Allocated 11.422 MiB for frame buffer
    2022-08-05 18:48:33.003 Iray [INFO] - IRAY:RENDER ::   1.13  IRAY   rend info : CUDA device 0 (NVIDIA TITAN Xp): Allocated 1.906 GiB of work space (2048k active samples in 0.007s)

    It's not the frame buffer (I use a UHD monitor, but as I said it isn't connected to the TItanXP).  I killed Ruins, which isn't that big, and it made no difference.

    So maybe @daz could respond to that; 2GB of workspace for a scene that is totally empty seems like starting on the wrong foot.  All the same, there are a lot of other entities to blame too.

    4.20.1.58

    Post edited by jbowler on
  • jbowlerjbowler Posts: 639

    johndoe_36eb90b0 said:

    Interesting... are you referring to these attributes that should be possible to set on any scene object (supposedly on lights too)?

    • bool reflection_cast
      The object is visible as a reflection in reflective objects.
    • bool reflection_recv
      The object is reflective.
    • bool refraction_cast
      The object is visible through refractive objects.
    • bool refraction_recv
      The object is refractive.
    • bool shadow_cast
      The object casts shadows.
    • bool shadow_recv
      The object can have shadows cast onto it.

    They are described here (under Attributes heading). If that is what they tested, then perhaps it didn't work due to attribute inheritance? If I had access to Iray SDK I would try to create a simple scene with built-in light source (such as point light or spotlight) and set those on it to see what happens and I would also try to disable attribute inheritance on that node just to be sure.

    Yes, they would all have to be set to false but then the ambiguity is what happens to the rays that are not covered in that list.

    Rays that are scattered and encounter the object have to pick up the emission of the object yet they have to pass through the object, at 100%, too; otherwise the object still casts a shadow.  So the "shadow_cast" property set to false may prevent the latter, but still there is the concept of encountering an emissive surface and picking up that emission while also passing straight through the object.

    So... basically if a ray encounters an object and the source of that ray is a reflection or a refraction the object can be seen, but if the ray was scattered by the previous surface the object can't be seen, except by implication of the slightly brighter previous surface.

    I'm pretty sure that if anyone analyzed ghost lights in the detail that Iray has been examined here they (ghost lights) would have been found not to work.

  • PerttiAPerttiA Posts: 5,904

    jbowler said:

    Starting DAZStudio bumps that to 315MByte (not in Iray preview), so I assume that 150Mbyte is the connection cost (duh, when I first started developing UNIX the computer I used had 4MByte of DRAM, end.)  Starting an Iray preview (of a scene with just the tonemapping and environment nodes) bumps me to 2.5GByte.  Here's the skinny:

    2022-08-05 18:48:33.003 Iray [INFO] - IRAY:RENDER ::   1.11  IRAY   rend info : CUDA device 0 (NVIDIA TITAN Xp): Allocated 11.422 MiB for frame buffer
    2022-08-05 18:48:33.003 Iray [INFO] - IRAY:RENDER ::   1.13  IRAY   rend info : CUDA device 0 (NVIDIA TITAN Xp): Allocated 1.906 GiB of work space (2048k active samples in 0.007s)

    It's not the frame buffer (I use a UHD monitor, but as I said it isn't connected to the TItanXP).  I killed Ruins, which isn't that big, and it made no difference.

    So maybe @daz could respond to that; 2GB of workspace for a scene that is totally empty seems like starting on the wrong foot.  All the same, there are a lot of other entities to blame too.

    4.20.1.58

    Emulation of the RTX functions on a card that doesn't have the hardware (GTX cards and your Titan), takes about 1GB of VRAM and at least on systems that do drive the monitors, W10 takes 1GB just for the fun of it.

  • jbowlerjbowler Posts: 639

    PerttiA said:

    Emulation of the RTX functions on a card that doesn't have the hardware (GTX cards and your Titan), takes about 1GB of VRAM and at least on systems that do drive the monitors, W10 takes 1GB just for the fun of it.

    So DAZStudio **is** using the whole NVidia ray-tracing shebang?  My impression was that the support wasn't in yet, but I have backups so I can roll back to a version without ray-tracing, which version @richard?

  • PerttiAPerttiA Posts: 5,904

    Don't know for sure, but the change log mentions integrated version of Iray RTX for DS 4.12.1.8, that was the first time "RTX" was added between "Iray" and the year

    http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log_4_12_1_118

    • Removed the “OptiX Prime Acceleration” option from the Advanced page of the Render Settings pane when NVIDIA Iray is set as the active renderer

      • The option is no longer supported by the integrated version of Iray RTX 2019

      • Although it is not explicitly stated in the release notes, the “iray_optix_prime” option is no longer listed/described in section “4 Iray Photoreal”, subsection “4.10 Rendering Options”, of the NVIDIA Iray - Programmer's Manual and setting the option results in a warning message being logged

Sign In or Register to comment.