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

Daz SoftwareDaz Software Posts: 30
edited September 7 in Daz Studio Discussion

Daz 3D is pleased to announce Daz Studio Pro BETA - version 4.20.1.78!

 


Highlights:

 

 


Frequently Asked Questions:

 

 


Previous Public Build (Beta) Threads:

 

  • ...
    • 4.20.1.78 (September 7, 2022)
    • 4.20.1.58 (July 27, 2022)
    • 4.20.1.43 (June 3, 2022)
    • 4.20.1.38 (May 20, 2022)
    • 4.20.1.34 (May 13, 2022)
  • 4.20.0.17 (April 21, 2022)
    • 4.20.0.12 (April 8, 2022)
    • 4.20.0.11 (March 25, 2022)
    • 4.20.0.8 (March 17, 2022)
    • 4.20.0.6 (March 11, 2022)
    • 4.20.0.5 (March 9, 2022)
    • 4.20.0.4 (March 3, 2022)
    • 4.20.0.3 (February 24, 2022)
    • 4.20.0.2 (February 17, 2022)
    • 4.16.1.47 (February 14, 2022)
    • 4.16.1.43 (February 4, 2022)
    • 4.16.1.40 (January 31, 2022)
    • 4.16.1.34 (January 21, 2022)
    • 4.16.1.31 (January 14, 2022)
    • 4.16.1.21 (December 22, 2021)
    • 4.16.1.17 (December 17, 2021)
    • 4.16.1.6 (December 1, 2021)
    • 4.16.1.2 (November 22, 2021)
    • 4.15.1.96 (November 12, 2021)
    • 4.15.1.91 (November 3, 2021)
    • 4.15.1.84 (October 29, 2021)
    • 4.15.1.72 (October 7, 2021)

 


General Release Threads:

 

  • 4.20.0.17 (April 29, 2022)
    • 4.20.0.2 (February 18, 2022)
  • 4.16.0.3 (November 22, 2021)
    • 4.15.0.30 (September 2, 2021)
    • 4.15.0.2 (January 7, 2021)
  • 4.14.0.10 (December 2, 2020)
    • 4.14.0.8 (November 10, 2020)
Post edited by rbtwhiz on
«13456

Comments

  • IceCrMnIceCrMn Posts: 1,767

    Hmm,, I'm seeing a 10 second shutdown with this new beta.

    txt
    txt
    log.txt
    73K
  • IceCrMnIceCrMn Posts: 1,767

    Just tried i a few more times.

    For me, it's 10 secnds exactly from the time I click the red "X" to close it until I can restart it.

     

    ...No more long wait times for Studio to close?

    Maybe someone else can check?

    If so , this is a great improvement.

  • In this build:

    1. When viewport is in the Iray photoeral preview mode with an otherwise empty scene except for a single G8F figure with a geograft and a geoshell if a camera (or a perspective view) is more than ~180 cm away from the figure, the part of the figure covered by the geoshell is being rendered as transparent while you are moving the camera.

    2. In the same setup just with a vanilla G8F when moving the camera around the scene, the update is almost instant and movement is smooth (RTX 3090). If you start moving the figure instead of the camera, then the render is stopped, the viewport switches to 3D textured mode and remains in that mode until you stop moving the figure and release the mouse which restarts the rendering. While dragging the slider (say Z translate) to move the figure, the scene update is very laggy -- the figure position changes approximately 3-4 times per second and it does so in small jumps instead of smoothly even though the photoreal preview is not visible until you release the mouse. The scene update drops to approx. 2 figure position changes per second if the figure also has geografts, geoshells, and higher resolution textures and it would probably get even worse in non-empty scenes.

    In my opinion, those are pretty basic operations that should always be tested before releasing a new build even if it is beta.

  • Richard HaseltineRichard Haseltine Posts: 83,637

    1. might be a Z-ordering issue, as the camera is far enough from the model for close values to blend together due to precision limits. What happens if you increase the offset value for the shell?

    2. I would think is because the first case simply involves telling Iray to update the viewpoint, without chnaging the 3D data, the second is actually changing the 3D data and so requires a re-transfer of the whole scene description.

  • EboshijaanaEboshijaana Posts: 258

    "Added support for curves/fibers for strand-based hair/fur

    • Render Settings > Render Mode > "Render Mode" must be set to "Photoreal"
    • For display via the NVIDIA Iray DrawStyle, Parameters > General > Line Tessellation > "Viewport Line Tessellation Sides" must be set to 1
    • For offline rendering, Parameters > General > Line Tessellation > "Render Line Tessellation Sides" must be set to 0"

    Where can I find these features? I checked the strand-based creation and it looks identical to the non-beta one.

  • Richard Haseltine said:

    1. might be a Z-ordering issue, as the camera is far enough from the model for close values to blend together due to precision limits. What happens if you increase the offset value for the shell?

    2. I would think is because the first case simply involves telling Iray to update the viewpoint, without chnaging the 3D data, the second is actually changing the 3D data and so requires a re-transfer of the whole scene description.

    1. That should be irrelevant, no? It wasn't happening in previous beta (4.20.0.x) or in the 4.16.0.3 release.

    2. I tested further, and it turns out this isn't new behavior just something I haven't noticed before -- 4.16.0.3 also has it.

    The second one is kind of weird given that when you start dragging while in NVIDIA Iray mode the viewport appears as if it is displaying in Smooth Shaded mode while dragging and only starts raytracing when you stop moving the figure so I would expect that updating the scene shouldn't be that slow if you are not actually raytracing while dragging (and you are not).

    I guess that what I am trying to say is that if you move a figure in any other viewport mode (Smooth Shaded, Texture Shaded, PBR) it will not be laggy, and the scene is still updated all the same like in NVIDIA Iray mode. I don't see why Iray would lag and other modes would not, especially given that Iray is not raytracing while you are moving the figure around.

  • Richard HaseltineRichard Haseltine Posts: 83,637

    Eboshijaana said:

    "Added support for curves/fibers for strand-based hair/fur

    • Render Settings > Render Mode > "Render Mode" must be set to "Photoreal"
    • For display via the NVIDIA Iray DrawStyle, Parameters > General > Line Tessellation > "Viewport Line Tessellation Sides" must be set to 1
    • For offline rendering, Parameters > General > Line Tessellation > "Render Line Tessellation Sides" must be set to 0"

    Where can I find these features? I checked the strand-based creation and it looks identical to the non-beta one.

    They are in the Parameters pane, they are not new - what is new is the effect of setting these values in that context.

  • Richard HaseltineRichard Haseltine Posts: 83,637

    johndoe_36eb90b0 said:

    Richard Haseltine said:

    1. might be a Z-ordering issue, as the camera is far enough from the model for close values to blend together due to precision limits. What happens if you increase the offset value for the shell?

    2. I would think is because the first case simply involves telling Iray to update the viewpoint, without chnaging the 3D data, the second is actually changing the 3D data and so requires a re-transfer of the whole scene description.

    1. That should be irrelevant, no? It wasn't happening in previous beta (4.20.0.x) or in the 4.16.0.3 release.

    I didn't deny it might reflect a chnage, just thinking about what that chnage might be. I'd still be curious to know if adjusting the offset value changes the distance at which it manifests for you.

    2. I tested further, and it turns out this isn't new behavior just something I haven't noticed before -- 4.16.0.3 also has it.

    The second one is kind of weird given that when you start dragging while in NVIDIA Iray mode the viewport appears as if it is displaying in Smooth Shaded mode while dragging and only starts raytracing when you stop moving the figure so I would expect that updating the scene shouldn't be that slow if you are not actually raytracing while dragging (and you are not).

    I guess that what I am trying to say is that if you move a figure in any other viewport mode (Smooth Shaded, Texture Shaded, PBR) it will not be laggy, and the scene is still updated all the same like in NVIDIA Iray mode. I don't see why Iray would lag and other modes would not, especially given that Iray is not raytracing while you are moving the figure around.

    It shows smooth shaded while waiting for the iray draw, that is not new at all. Before Iray can do its draw it needs the full 3D description of the scene - when you move the camera that does not change, when you move the content it does. Sending what is usually a fairly hefty chunk of data to Iray can take a while.

  • Richard Haseltine said:

    I didn't deny it might reflect a chnage, just thinking about what that chnage might be. I'd still be curious to know if adjusting the offset value changes the distance at which it manifests for you.

    Sure, I could test that when I have more time.

    Richard Haseltine said:

    It shows smooth shaded while waiting for the iray draw, that is not new at all. Before Iray can do its draw it needs the full 3D description of the scene - when you move the camera that does not change, when you move the content it does. Sending what is usually a fairly hefty chunk of data to Iray can take a while.

    Maybe it would be better to actually switch the viewport to smooth shaded when the user starts to move an object in the scene and only switch it back to Iray mode and send an update once the moving stops?

    The way it is implemented now we get the worst of both worlds -- we don't get fast and smooth object movement of smooth shaded mode, and we don't get Iray preview while moving objects around the scene.

    If we already cannot have Iray preview while moving objects around the scene (since the scene displays as smooth shaded), then at least we could get faster scene manipulation?

  • Richard HaseltineRichard Haseltine Posts: 83,637

    johndoe_36eb90b0 said:

    Richard Haseltine said:

    I didn't deny it might reflect a chnage, just thinking about what that chnage might be. I'd still be curious to know if adjusting the offset value changes the distance at which it manifests for you.

    Sure, I could test that when I have more time.

    Richard Haseltine said:

    It shows smooth shaded while waiting for the iray draw, that is not new at all. Before Iray can do its draw it needs the full 3D description of the scene - when you move the camera that does not change, when you move the content it does. Sending what is usually a fairly hefty chunk of data to Iray can take a while.

    Maybe it would be better to actually switch the viewport to smooth shaded when the user starts to move an object in the scene and only switch it back to Iray mode and send an update once the moving stops?

    The way it is implemented now we get the worst of both worlds -- we don't get fast and smooth object movement of smooth shaded mode, and we don't get Iray preview while moving objects around the scene.

    If we already cannot have Iray preview while moving objects around the scene (since the scene displays as smooth shaded), then at least we could get faster scene manipulation?

    You can set Manipulation Draw Style in the Tool Settings pane to one of the Bounding Box modes; with Iray and Filamaent it might well be worth asking that Smooth Shaded be added as an option too (Technical Support ticket).

  • marblemarble Posts: 6,826

    IceCrMn said:

    Just tried i a few more times.

    For me, it's 10 secnds exactly from the time I click the red "X" to close it until I can restart it.

     

    ...No more long wait times for Studio to close?

    Maybe someone else can check?

    If so , this is a great improvement.

    Nope ... still slow for me.

  • chorsechorse Posts: 163
    edited May 17

    marble said:

    IceCrMn said:

    Just tried i a few more times.

    For me, it's 10 secnds exactly from the time I click the red "X" to close it until I can restart it.

     

    ...No more long wait times for Studio to close?

    Maybe someone else can check?

    If so , this is a great improvement.

    Nope ... still slow for me.

    It closes almost instantly for me.  A few seconds.  ...I can restart right away..yes

    Post edited by chorse on
  • greg_82000392greg_82000392 Posts: 16
    edited May 17

    chorse said:

    marble said:

    IceCrMn said:

    Just tried i a few more times.

    For me, it's 10 secnds exactly from the time I click the red "X" to close it until I can restart it.

     

    ...No more long wait times for Studio to close?

    Maybe someone else can check?

    If so , this is a great improvement.

    Nope ... still slow for me.

    It closes almost instantly for me.  A few seconds.  ...I can restart right away..

    Is it possible that chorse is using a turbo loader product and marble is not? That makes a HUUUUGE difference.yes

    Post edited by Richard Haseltine on
  • marblemarble Posts: 6,826
    edited May 18

    greg_82000392 said:

    chorse said:

    marble said:

    IceCrMn said:

    Just tried i a few more times.

    For me, it's 10 secnds exactly from the time I click the red "X" to close it until I can restart it.

     

    ...No more long wait times for Studio to close?

    Maybe someone else can check?

    If so , this is a great improvement.

    Nope ... still slow for me.

    It closes almost instantly for me.  A few seconds.  ...I can restart right away..

    Is it possible that chorse is using a turbo loader product and marble is not? That makes a HUUUUGE difference.yes

    I don't have the Turbo Loader product.

    I do wonder whether some of the features of DAZ Studio are written in a compiled programming language or just scripts. I've just had dForce explode on me (again) and clicking cancel can take several minutes. Why is everything so slow? And dForce itself is a prime example - so very slow.

    Post edited by marble on
  • PerttiAPerttiA Posts: 5,367

    marble said:

    I don't have the Turbo Loader product.

    I do wonder whether some of the features of DAZ Studio are written in a compiled programming language or just scripts. I've just had dForce explode on me (again) and clicking cancel can take several minutes. Why is everything so slow? And dForce itself is a prime example - so very slow.

    Try it yourself... Write a thousand-page document and then start erasing all of it one character at a time devil
    Apparently there is also a related problem... If you for some reason, have duplicated some pages, you can erase only one of those duplicates and in the end can't finish erasing the document and therefore cannot proceed to the next task.

    Someone else might just throw the used pages in the bin and start the next one with fresh unused pages, but...

  • outrider42outrider42 Posts: 3,203
    edited May 21

    What is going on with Iray? Daz 4.20 introduced an Iray that is much slower than previous versions. The benchmark thread shows people rendering 13% slower than previous versions with a simple scene...it can get worse when you scale up.

    Much, much worse. I have created scenes that render more than 25% slower in 4.20 than they do in 4.15 with every setting being equal. I had hoped that this new release might fix the issue. But we have a user saying that this newest 4.20 is EVEN SLOWER than the previous 4.20.

    This kind of performance loss just from upgrading is unheard of. All the settings are the same, no caustics or guided sampling. Turning on either of these makes it even worse!

    The whole point of gpu rendering is supposed to be speed. Daz seriously needs to investigate what is going on here, whether it be something they have done or the Iray Dev team, it doesn't matter. This situation is getting pretty dire. I have a 3090 and a 3060, I have more hardware power than most, so I cannot imagine how bad this is for the people who have less hardware. If things stay on this course, Daz runs a risk of driving its customer base away to faster software. While it is true that Daz models can be exported, it does not work perfectly. But more importantly to Daz, if people export to other software, they have no need to buy any Daz or Iray specific products. Why buy Iray shaders if you do not use Iray? Why buy Daz scripts if you export to something else? And if you must export everything, why even bother using the Genesis models at all?

    And this performance problem is on top of all the other issues that 4.20 introduced for hapless Daz users who made the horrible mistake of "upgrading" their software. HDRIs look awful in 4.20. Ghost Lights are broken, and you will NEVER convince me this was to fix a glitch. 

    Daz Studio and Iray have to be fast and easy. They have to be more convenient than any other solution. They have to be both of these things in order to survive the next 10 years as this industry rapidly grows and changes. Daz getting Iray in 2015 was pretty cool. In 2015. It is no longer 2015, and GPU based render engines are everywhere. They are no longer special, and you have to do more to stand out. It is now possible to render amazing quality in real time and Unreal 5 is poised to break this industry wide open in ways that Daz only dreamed of.

    So what is Iray and Daz's goal for rendering in the next few years? And what are they going to do to fix this problem they have now?

    Post edited by outrider42 on
  • Richard HaseltineRichard Haseltine Posts: 83,637

    Previously emissive surfaces ddi not take accoutn of opacity, this is clearly non-physical so yes, nVidia in chnaging it were fixing a bug from the point of view of Iray being a Physcally Based Renderer. I'm not sue how you can be unconvinced on this. Of course we have things like section planes and non-rendering emitters, so clearly nVidia can live with non-physicality, and I still would hope they can be persuaded to all some kind of toggle to turn on the old behaviour (which has been there, and potyentially used beyond Daz Studio, for years) but it is pointless to imagine there may have been some clandestine motivation beyond what has been given.

  • nicsttnicstt Posts: 11,625

    +1 @ourtrider42

    My take from that, if I'm understanding correctly, is that it took Nvidia 7 years to fix an important feature, namely caustics.

    No encouraging.

  • evacynevacyn Posts: 836

    Richard Haseltine said:

    Previously emissive surfaces ddi not take accoutn of opacity, this is clearly non-physical so yes, nVidia in chnaging it were fixing a bug from the point of view of Iray being a Physcally Based Renderer. I'm not sue how you can be unconvinced on this. Of course we have things like section planes and non-rendering emitters, so clearly nVidia can live with non-physicality, and I still would hope they can be persuaded to all some kind of toggle to turn on the old behaviour (which has been there, and potyentially used beyond Daz Studio, for years) but it is pointless to imagine there may have been some clandestine motivation beyond what has been given.

    I think you're burying the lede - the rationale for the ghost light behaviour is trivial when compared to these poor rendering times. If some are seeing ~25% impact, that's significant and it would be nice to see Daz address some of this (or at least acknowledge they're working on it).

  • Richard HaseltineRichard Haseltine Posts: 83,637
    edited May 22

    evacyn said:

    Richard Haseltine said:

    Previously emissive surfaces ddi not take accoutn of opacity, this is clearly non-physical so yes, nVidia in chnaging it were fixing a bug from the point of view of Iray being a Physcally Based Renderer. I'm not sue how you can be unconvinced on this. Of course we have things like section planes and non-rendering emitters, so clearly nVidia can live with non-physicality, and I still would hope they can be persuaded to all some kind of toggle to turn on the old behaviour (which has been there, and potyentially used beyond Daz Studio, for years) but it is pointless to imagine there may have been some clandestine motivation beyond what has been given.

    I think you're burying the lede - the rationale for the ghost light behaviour is trivial when compared to these poor rendering times. If some are seeing ~25% impact, that's significant and it would be nice to see Daz address some of this (or at least acknowledge they're working on it).

    I was addressing a specific point, not the general topic - though of course, depending on the scene, it may be that the changed behaviour of emissive surfaces or Thin Film may have an imapct on the time taken.

    We do not, of course, know what Daz might be saying to nVidia or how persuasive they may be - the latter being a good reason for them to keep quiet about the former, lest uneralistic expectations arise.

    Post edited by Richard Haseltine on
  • outrider42outrider42 Posts: 3,203

    Come on now. What did the 'fix' actually accomplish? I keep hearing how it is a fix...but seriously how is it actually a fix? And more important...who benefits from this change? I want a name. I wanted to know who out of all the customers that use Iray benefits from that change?

    This idea the fix was made to be more 'physical' does not add up. I am not saying they made the change to sabotage Iray and anger people, but there doesn't seem to be any valid reason for the change other than it being physical somehow. That doesn't even make sense...again, I repeat, regular lights in Iray have their own opacity value. How is that physical? The mesh should have an opacity for the mesh, and if it has a light then the light should have an opacity value that independent of the mesh opacity. Period.

    3D rendering is not just about pure 100% physical accuracy. While accuracy is certainly great, we have already been over this. If Hollywood only used 100% accurate lighting it would go out of business. This is not even about special effects. Lights are added to every single scene in any movie or TV production. Audio is almost always overdubbed. Post effects are common.

    If anybody wants to suggest differently, go watch the indoor scenes for Vanilla Ice's movie, "Cool as Ice". Yes, I just wrote the words Vanilla Ice in 2022.

    As a bonus the indoor scenes are also oddly foggy. Inside a house...it is foggy. So just think folks, you can now use Daz 4.20 and its volumetric fog to perfectly recreate the scenes from Cool as Ice! Amazing!

    Caustics are also OPTIONAL. In every version you have to enable caustics to even use them at all. So anything that effects the performance of caustics should therefor only effect performance when caustics or guided sampling is enabled. That is not what is happening here.

    Thin film was mentioned. So I decided to test just that.

    It is not simply thin film.

    I created a scene with a HDRI and Genesis 8. For science I used no clothing or hair to keep the focus on the character and its skin. I ran multiple tests. I changed ALL the surfaces in the scene to be Thin Film OFF. Then I changed all the surfaces to Thin Film ON. And yes, every surface.

    Daz 4.20.0.17 was slower than 4.15 in EVERY case. I am desperately trying to give 4.20 every possible chance to prove it does something better, but it fails every time.

    I tried rendering to 95% convergence. One that I noticed is that 4.20 does a few more iterations to reach 95% convergence than 4.15. Interesting. So OK, I also tested the scene capped at 500 iterations, maybe this would equalize them. Again, I ran them with all surfaces thin walled OFF and then ON.

    NOPE.

    So I tested this scene so many times and so many ways. 4.20 was just plain slower in every case. The worst case was with all the surfaces thin walled OFF. Which was surprising...I thought the changes were to thin walled ON. With thin walled ON, the gap was actually at its smallest.

    I also examined the images produced, and this is where things really fall apart. At 500 iterations, the difference in quality is MUCH worse in 4.20. So not only did 4.20 take longer to hit 500 iterations, it LOOKED WORSE in doing so. What the hell is it doing?

    One last gasp for 4.20. What about the convergence test? After all, 4.20 ran more iterations to hit 95%, right, so surely those extra iterations resulted in a better quality image?

    NOPE!!!!

    It is close, but when I examined the two images, I spotted more noticeable noisy pixels in the 4.20 image than 4.15. WHAT???

    So lets get this straight. 4.20 took longer, it did more iterations...and still manages to look worse than 4.15. WHAT THE HELL IS GOING ON HERE DAZ?

    You know, if they are going to screw with Iray and make these changes...I would at least expect the changes to result in something positive. Literally ANYTHING positive. But there are none. Seriously. Daz 4.20 is slower, yet produces an inferior image to past versions. Yet we had to sacrifice ghost lights for this amazingly splendid "improvement". Oh, and volumetrics, those are kind of cool I guess for the 2 or 3 times a year you might want one, or when you want to recreate Cool as Ice.

    I see nothing good about 4.20. The more I test it, the WORSE it gets.

    It is wonderful that Daz finally figured out how to shut down a program, though. That is real progress. Daz needs to be locking horns with the Iray Dev team here. Iray is what makes Daz Studio different, but if Iray isn't going to perform well, that in turn hurts Daz Studio. It is absolutely vital that Daz get something done about this.

    Here is another question, is Daz obligated to always use the latest Iray? Why does DS even need to use it? We went a whole year without a Studio update for 4.10. Maybe we need to tak a step back and examine the situation here.

    At some point I promise I will post my data with pictures in a thread to demonstrate just how bad this is. But for now, just know I have tested this thing dozens of times back and forth and 4.20 is clearly a regression in performance.

  • barbultbarbult Posts: 19,295

    My 4.20.1.38 Public Build log file is full of warnings about mi_plugin_factory not found.

    2022-05-23 00:39:12.137 [INFO] Iray :: Loading Plugins...
    2022-05-23 00:39:12.138 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\aix.dll".
    2022-05-23 00:39:12.139 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avcodec-58.dll".
    2022-05-23 00:39:12.139 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avcodec-58.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.141 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avfilter-7.dll".
    2022-05-23 00:39:12.141 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avfilter-7.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.142 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avformat-58.dll".
    2022-05-23 00:39:12.142 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avformat-58.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.143 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avutil-56.dll".
    2022-05-23 00:39:12.143 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\avutil-56.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.146 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\axf_importer.dll".
    2022-05-23 00:39:12.146 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\AxFDecoding.1.8.1.dll".
    2022-05-23 00:39:12.146 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\AxFDecoding.1.8.1.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.147 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\blend_render.dll".
    2022-05-23 00:39:12.147 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\cb_importer.dll".
    2022-05-23 00:39:12.148 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\ct.dll".
    2022-05-23 00:39:12.152 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\dds.dll".
    2022-05-23 00:39:12.154 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\ffmpeg_video_decoder.dll".
    2022-05-23 00:39:12.154 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\iray_bridge_client.dll".
    2022-05-23 00:39:12.154 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\iray_bridge_server.dll".
    2022-05-23 00:39:12.159 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libiray.dll".
    2022-05-23 00:39:12.161 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libirt.dll".
    2022-05-23 00:39:12.163 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libnvindex.dll".
    2022-05-23 00:39:12.163 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libnvindex.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.164 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libnvindex_application_layer_application_layer.dll".
    2022-05-23 00:39:12.164 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libnvindex_application_layer_application_layer.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.165 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libnvindex_plugin_openvdb_integration.dll".
    2022-05-23 00:39:12.165 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\libnvindex_plugin_openvdb_integration.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.165 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\mdl_distiller.dll".
    2022-05-23 00:39:12.166 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\mi_exporter.dll".
    2022-05-23 00:39:12.166 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\mi_importer.dll".
    2022-05-23 00:39:12.167 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\nv_freeimage.dll".
    2022-05-23 00:39:12.168 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\nvcuvid_video_decoder.dll".
    2022-05-23 00:39:12.168 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\screen_video.dll".
    2022-05-23 00:39:12.169 Iray [INFO] - PLUG:PLUGIN ::   0.0   PLUG   plug info : Loaded library "C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\swresample-3.dll".
    2022-05-23 00:39:12.169 [WARNING] :: ..\..\..\..\..\src\pluginsource\DzIrayRender\dzneuraymgr.cpp(369): Iray [ERROR] - PLUG:PLUGIN ::   0.0   PLUG   plug error: Library C:\Program Files\DAZ 3D\DAZStudio4 Public Build\libs\iray\swresample-3.dll: symbol "mi_plugin_factory" not found.
    2022-05-23 00:39:12.169 [INFO] Iray :: Starting...

    What is wrong?  My NVIDIA display driver is version: 511.17, which exceeds the minimum requirements stated in the highlights thread.

  • kyoto kidkyoto kid Posts: 38,483

    ...think I'll just stick with the 4.16 beta I've been using, works fine andrenders quickly. Sad enough that with the latest GPUs 4.20  renders slower than earlier versions, not sure how much worse it may be with an older card. 

     

  • TorquinoxTorquinox Posts: 1,691

    outrider42 said:

    Come on now. What did the 'fix' actually accomplish? I keep hearing how it is a fix...but seriously how is it actually a fix? And more important...who benefits from this change? I want a name. I wanted to know who out of all the customers that use Iray benefits from that change?

    This idea the fix was made to be more 'physical' does not add up. I am not saying they made the change to sabotage Iray and anger people, but there doesn't seem to be any valid reason for the change other than it being physical somehow. That doesn't even make sense...again, I repeat, regular lights in Iray have their own opacity value. How is that physical? The mesh should have an opacity for the mesh, and if it has a light then the light should have an opacity value that independent of the mesh opacity. Period.

    3D rendering is not just about pure 100% physical accuracy. While accuracy is certainly great, we have already been over this. If Hollywood only used 100% accurate lighting it would go out of business. This is not even about special effects. Lights are added to every single scene in any movie or TV production. Audio is almost always overdubbed. Post effects are common.

    If anybody wants to suggest differently, go watch the indoor scenes for Vanilla Ice's movie, "Cool as Ice". Yes, I just wrote the words Vanilla Ice in 2022.

    As a bonus the indoor scenes are also oddly foggy. Inside a house...it is foggy. So just think folks, you can now use Daz 4.20 and its volumetric fog to perfectly recreate the scenes from Cool as Ice! Amazing!

    Caustics are also OPTIONAL. In every version you have to enable caustics to even use them at all. So anything that effects the performance of caustics should therefor only effect performance when caustics or guided sampling is enabled. That is not what is happening here.

    Thin film was mentioned. So I decided to test just that.

    It is not simply thin film.

    I created a scene with a HDRI and Genesis 8. For science I used no clothing or hair to keep the focus on the character and its skin. I ran multiple tests. I changed ALL the surfaces in the scene to be Thin Film OFF. Then I changed all the surfaces to Thin Film ON. And yes, every surface.

    Daz 4.20.0.17 was slower than 4.15 in EVERY case. I am desperately trying to give 4.20 every possible chance to prove it does something better, but it fails every time.

    I tried rendering to 95% convergence. One that I noticed is that 4.20 does a few more iterations to reach 95% convergence than 4.15. Interesting. So OK, I also tested the scene capped at 500 iterations, maybe this would equalize them. Again, I ran them with all surfaces thin walled OFF and then ON.

    NOPE.

    So I tested this scene so many times and so many ways. 4.20 was just plain slower in every case. The worst case was with all the surfaces thin walled OFF. Which was surprising...I thought the changes were to thin walled ON. With thin walled ON, the gap was actually at its smallest.

    I also examined the images produced, and this is where things really fall apart. At 500 iterations, the difference in quality is MUCH worse in 4.20. So not only did 4.20 take longer to hit 500 iterations, it LOOKED WORSE in doing so. What the hell is it doing?

    One last gasp for 4.20. What about the convergence test? After all, 4.20 ran more iterations to hit 95%, right, so surely those extra iterations resulted in a better quality image?

    NOPE!!!!

    It is close, but when I examined the two images, I spotted more noticeable noisy pixels in the 4.20 image than 4.15. WHAT???

    So lets get this straight. 4.20 took longer, it did more iterations...and still manages to look worse than 4.15. WHAT THE HELL IS GOING ON HERE DAZ?

    You know, if they are going to screw with Iray and make these changes...I would at least expect the changes to result in something positive. Literally ANYTHING positive. But there are none. Seriously. Daz 4.20 is slower, yet produces an inferior image to past versions. Yet we had to sacrifice ghost lights for this amazingly splendid "improvement". Oh, and volumetrics, those are kind of cool I guess for the 2 or 3 times a year you might want one, or when you want to recreate Cool as Ice.

    I see nothing good about 4.20. The more I test it, the WORSE it gets.

    It is wonderful that Daz finally figured out how to shut down a program, though. That is real progress. Daz needs to be locking horns with the Iray Dev team here. Iray is what makes Daz Studio different, but if Iray isn't going to perform well, that in turn hurts Daz Studio. It is absolutely vital that Daz get something done about this.

    Here is another question, is Daz obligated to always use the latest Iray? Why does DS even need to use it? We went a whole year without a Studio update for 4.10. Maybe we need to tak a step back and examine the situation here.

    At some point I promise I will post my data with pictures in a thread to demonstrate just how bad this is. But for now, just know I have tested this thing dozens of times back and forth and 4.20 is clearly a regression in performance.

    I'm convinced. I'll stay on 4.15 until 4.20 changes for the better.

  • PerttiAPerttiA Posts: 5,367

    Torquinox said:

    I'm convinced. I'll stay on 4.15 until 4.20 changes for the better.

    Not having the information about VRAM usage in the log was reason enough, not to update. 

  • TorquinoxTorquinox Posts: 1,691
    edited May 23

    PerttiA said:

    Torquinox said:

    I'm convinced. I'll stay on 4.15 until 4.20 changes for the better.

    Not having the information about VRAM usage in the log was reason enough, not to update. 

    Since zombietaggerung pointed out how to have as many installs as I like, I can have my cake and eat it. Even so, Outrider's report is disappointing.

    Post edited by Torquinox on
  • outrider42outrider42 Posts: 3,203
    edited May 24

    I have done even more testing, and the one thing I am finding is that for whatever reason 4.20 is often doing a lot more iterations to achieve the same convergence setting. If you take that own its own, it might not be a problem. But then you find that even if you cap the iterations to be exactly the same, it STILL takes longer.

    So this compounds the issue even more when you using convergence as a stopping point. Because 4.20 takes longer per iteration and then does more iterations to hit 95% or whatever. If you choose 100% you might find 4.20 making 50% more iterations to hit its convergence goal. This creates another problem, you might be hitting your iteration cap sooner more often. I have done several tests where 4.20 unexpectedly hits the iteration cap when 4.15 barely break 4000. And it had the cap at 6000 for that pic.

    So with all these extra iterations, sometimes if you pixel peep you might spot 4.20 being just slightly better in the final image. But the thing is if you raise the caps on convergence or even turn it off, you can easily match that quality and probably do it faster.

    There is one possible silver lining. I have found one scene where 4.20 actually hits a higher convergence than 4.15 on a set iteration cap. However, it still takes longer to hit the iteration cap...so if you were to set convergence as the cap they would only wind up close to even. So even here the best 4.20 can manage is a draw.

    But 4.20 is only close to 4.15 when strictly rendering architecture...not people. The best scene for 4.20 where it gets close to 4.15 is the Trendy City Bar. There is a lot of glass in this scene, and lights. I was surprised given the mesh lighting issues with 4.20 that it was close as it was in this scene. I have not tested a ton of environments, but so far this bar scene is one of 4.20 better showings compared to 4.15 in performance.

    So if all you do is render architecture in Iray, you may be ok in 4.20, you are still taking a performance hit nearly every time, but not as much. But this is Daz Studio...I would dare say that most users render people.

    Like Charlton Heston might say, Rendering is people!

    And well, that is where 4.20 seems to struggle most. It appears that the more complex shaders on skin gives 4.20 all kinds of problems, and this where I start to see the performance gaps get crazy and the strange iteration counts. I have also seen 4.20 struggle to render mesh eyebrows without noise, while 4.15 did a better job. 4.15 still had some noise in the brows, but the noise pixels in 4.20 stood out a lot more. Adding a point light almost got rid of the noise in 4.15, but it was still easily visible in 4.20. This was a mesh brow by bluejaunte for his Nadya.

    I will just show this one comparison here. This Bluejaunte Nadya rendered with a HDRI and a point light at 1750 by 5000 pixels. She is at subD 3, using here mesh brows and lashes. The rendering options were at default, so 95% convergence. In this particular test I set ALL surfaces to have Thin Walled OFF, that includes the tear, cornea, and eye moisture surfaces which by default have Thin Walled ON with this material preset. But the performance results were similar with Thin Walled ON as well for those surfaces, though not quite as extreme as this one.

    First the numbers.

    4.15 

    2022-05-23 21:02:23.639 Total Rendering Time: 5 minutes 19.88 seconds

    2022-05-23 21:02:38.005 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : CUDA device 0 (NVIDIA GeForce RTX 3090): 2325 iterations, 2.269s init, 309.693s render

    2022-05-23 21:02:38.005 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : CUDA device 1 (NVIDIA GeForce RTX 3060): 1022 iterations, 2.925s init, 306.914s render

    3347 total iterations

     

    4.20 

    2022-05-23 21:13:05.457 [INFO] :: Total Rendering Time: 8 minutes 52.13 seconds

    2022-05-23 21:13:12.717 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : CUDA device 0 (NVIDIA GeForce RTX 3090): 3127 iterations, 1.656s init, 523.068s render

    2022-05-23 21:13:12.717 Iray [INFO] - IRAY:RENDER ::   1.0   IRAY   rend info : CUDA device 1 (NVIDIA GeForce RTX 3060): 1560 iterations, 1.819s init, 519.901s render

    4687 total iterations

    The most obvious thing that stands out is that 4.15 rendered this over 5 minutes, while 4.20 took almost 9 minutes. Yes, you read that correctly. I told you guys that I could create scenes that show beyond 25% performance gap, well, here you go. However, 4.20 did a lot more iterations, too. In fact it did 1340 more iterations to be exact. Though if you cap the two versions by iteration counts in this scene, 4.15 still renders faster. Another very concerning observation is that the 3060 is doing a lot more iterations compared to the 3090. Given the massive speed difference between them, the 3090 should be the card doing most of those extra iterations, but the ratio is not as high as it should be. This points to another problem with 4.20 that makes no sense. So these performance gaps may be different for different hardware. However, if the most powerful hardware is hurt the most, boy is that a problem.

    The next big question is the picture quality worth the extra time and iterations that 4.20 ran to hit 95%? Well, here you go. Judge for yourself.

    4.20

    4.15

    I tried to crop the pics to see if the compression is better.

    4.20

    4.15

    Sadly this is not as clear as it could be because of the image compression on the websites. Look close at the eyebrows. There is one other oddity in this pic, and that there are clear UV seams showing. It happened in both versions, and I don't know why. Other skins did not have this issue, so I believe it is just this skin and HDRI at this high resolution.

    But even if version 4.20 produced a better image here (and it did NOT), it still took a staggering 68.9% longer to hit 95% convergence. So even if you try to factor the extra iterations, there is no way it gets close. But even worse, 4.20 simply produced an inferior image here, which is just depressing.

    These numbers are so bad I had to do some other tests just to verify it wasn't a fluke. My benchmark scene numbers match other people who have the same hardware. And other scenes can be closer. But there is something about this material setup that is giving the Iray in 4.20 all kinds of problems. Whatever it is, needs to be fixed ASAP.

    This is a total disaster. Now this is the worst of the performance gaps I have so far observed, but holy crap, this is bad. This is a Bluejaunte character, dare I say one of the more popular PAs in this store, and I believe that all his characters might experience this kind of slow down in 4.20 with a similar setup. This is rendered at a higher resolution than perhaps most people do, and there is no hair or much clothing (jury may be out on the clothing part, LOL), but still, yikes.

    Post edited by outrider42 on
  • TorquinoxTorquinox Posts: 1,691

    I hope someone at Daz is evaluating the information @outrider42 provided in this thread and is doing what must be done to improve future versions of DS. @outrider42  thank you for your diligence and caring to take the time and trouble to do these tests. The work you're doing is a credit to you and a boon to the community. It's pretty cool! yes

  • Richard HaseltineRichard Haseltine Posts: 83,637

    Torquinox said:

    I hope someone at Daz is evaluating the information @outrider42 provided in this thread and is doing what must be done to improve future versions of DS. @outrider42  thank you for your diligence and caring to take the time and trouble to do these tests. The work you're doing is a credit to you and a boon to the community. It's pretty cool! yes

    Daz does not write Iray (or 3Delight)

  • TorquinoxTorquinox Posts: 1,691

    Richard Haseltine said:

    Torquinox said:

    I hope someone at Daz is evaluating the information @outrider42 provided in this thread and is doing what must be done to improve future versions of DS. @outrider42  thank you for your diligence and caring to take the time and trouble to do these tests. The work you're doing is a credit to you and a boon to the community. It's pretty cool! yes

    Daz does not write Iray (or 3Delight)

    And? Daz implements it. If they can work with Apple folks to get DS to run on current Apple machines, they can probably have a meet with Nvidia and/or 3DL folks to see what's what and to see what can be done.

Sign In or Register to comment.