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

1333436383974

Comments

  • Saxa -- SDSaxa -- SD Posts: 872
    edited December 2019
    RayDAnt said:

    Did not really see anything definitive re: ""individual-scene-object-placement dependent"" other than the more objects, then the more spatial relationships etc need to be defined.  And not so much anything about subroutines for pockets of scene geometry density or anything like that.

    Imagine for a second that you wanted to render an incredibly simplistic scene with only 4 separate triangles in it where each triangle sits in its own front corner of the virtual scene space. This is what the BVH Acceleration Structure for that scene configuration would most likely look like:

    1. Bounding Box Front-Top
      1. Bounding Box Left
        1. Triangle #1
      2. Bounding Box Right
        1. Triangle #2
    2. Bounding Box Front-Bottom
      1. Bounding Box Left
        1. Triangle #3
      2. Bounding Box Right
        1. Triangle #4

    That's a heirarchical structure with a total of 10 items in it that need to be stored in a file somewhere for constant analysis by your Path Tracers.

    Now imagine rendering the same scene except this time with one triangle in the front top right corner and the rest in the front bottom left. This is how the BVH Acceleration Structure would now read:

    1. Bounding Box Front-Top-Right
      1. ​Triangle #1
    2. Bounding Box Front-Bottom-Left
      1. Triangle #2
      2. Triangle #3
      3. Triangle #4

    That's a heirarchical structure with a total of only 6 items in it (a 40% size reduction from before) despite the fact that the scene's content remains exactly the same. Hence why I say individual-scene-object-placement also plays a role in how much memory is needed to accommodate the construction and storage of these acceleration structures.

    Oh that's a helpful description.  So it does break into sub-environments for raycast compute.

    Do you know how specifically how many Bounding box designations there are?  Don' want to assume based on your naming conventions, which may be hypothetical? or Not.  smiley  And are they static or relational to scene size?

    -

    -

    EDIT/Update:  While DAZ-ing away, thought of another question.  LOL, hope you don't mind all these questions.

    Question: Is the scene config for the BVH Build (1) camera dependent or (2) scene-dependent or a (3) hybrid or (4) something else yet?

    Post edited by Saxa -- SD on
  • marblemarble Posts: 7,500

    So are we saying that NVidia drivers 441.66 have improved matters? Has anyone tried them with a GTX GPU? I have 4.12.1.40 Beta installed but have been reverting to 4.11 for renders. I would like to render in 4.12 because (may be my imagination) it seems to render quicker when it is not falling back to CPU. I've installed so many drivers in the past few weeks (and had Windows 10 overwrite them) that I am wary of jumping to yet another version unless there are significant improvements.

  • marble said:

    So are we saying that NVidia drivers 441.66 have improved matters? Has anyone tried them with a GTX GPU? I have 4.12.1.40 Beta installed but have been reverting to 4.11 for renders. I would like to render in 4.12 because (may be my imagination) it seems to render quicker when it is not falling back to CPU. I've installed so many drivers in the past few weeks (and had Windows 10 overwrite them) that I am wary of jumping to yet another version unless there are significant improvements.

    I'm using 441.66 Studio and have a GTX 1080Ti. It is rendering for me in 4.12, but the jury is still out on whether 441.66 is the "best".

  • RayDAntRayDAnt Posts: 1,135
    edited December 2019
    marble said:

    So are we saying that NVidia drivers 441.66 have improved matters?

    That's the way it looks with my Titan RTX. Haven't had the chance to test it out yet on my GTX 1050-equipped laptop. But based on my knowledge of the underlying things at play, this particular bug fix (essentially raytracing acceleration memory leaks) should apply on both platforms. 

     

     

    RayDAnt said:

    Did not really see anything definitive re: ""individual-scene-object-placement dependent"" other than the more objects, then the more spatial relationships etc need to be defined.  And not so much anything about subroutines for pockets of scene geometry density or anything like that.

    Imagine for a second that you wanted to render an incredibly simplistic scene with only 4 separate triangles in it where each triangle sits in its own front corner of the virtual scene space. This is what the BVH Acceleration Structure for that scene configuration would most likely look like:

    1. Bounding Box Front-Top
      1. Bounding Box Left
        1. Triangle #1
      2. Bounding Box Right
        1. Triangle #2
    2. Bounding Box Front-Bottom
      1. Bounding Box Left
        1. Triangle #3
      2. Bounding Box Right
        1. Triangle #4

    That's a heirarchical structure with a total of 10 items in it that need to be stored in a file somewhere for constant analysis by your Path Tracers.

    Now imagine rendering the same scene except this time with one triangle in the front top right corner and the rest in the front bottom left. This is how the BVH Acceleration Structure would now read:

    1. Bounding Box Front-Top-Right
      1. ​Triangle #1
    2. Bounding Box Front-Bottom-Left
      1. Triangle #2
      2. Triangle #3
      3. Triangle #4

    That's a heirarchical structure with a total of only 6 items in it (a 40% size reduction from before) despite the fact that the scene's content remains exactly the same. Hence why I say individual-scene-object-placement also plays a role in how much memory is needed to accommodate the construction and storage of these acceleration structures.

    Oh that's a helpful description.  So it does break into sub-environments for raycast compute.

    It's just like the extended Tableo of Contents of something like a physics textbook. Except that instead of breaking paragraphs of text down into chapters/headings/subheadings/etc based on topics, its breaking down collections of triangles into an increasingly detailed descriptive hierarchy based on location in a specific representation of virtual space.

     

    Do you know how specifically how many Bounding box designations there are? Don' want to assume based on your naming conventions, which may be hypothetical? or Not.  smiley  

    BHV construction is completely open-ended and infinitely tweakable. So yeah, my examples here are completely just made up by me at the spur of the moment. 

     

     

    And are they static or relational to scene size?

    Depends on what you mean by scene size. If by scene size you mean texture data needing to be stored, then the asnwer is no. If, however, you mean scene size in terms of scene object/polygon count  or virtual space (ie.small room vs large room) then the answer becomes either yes or sort of respectively. 

     

    Question: Is the scene config for the BVH Build (1) camera dependent or (2) scene-dependent or a (3) hybrid or (4) something else yet?

    BHV Accelleration Structure complexity = camera viewpoint * scene content * scene content layout

    Hence why BVH Acceleration Structures are normally generated on the fly at the start of each render. Because nearly every rendering scenario (the exception being exactly the same scene with light intensities or textures modified) needs a potentialyl completely new BVH to describe it efficiently.

    Post edited by RayDAnt on
  • galiengalien Posts: 137
    marble said:

    So are we saying that NVidia drivers 441.66 have improved matters? Has anyone tried them with a GTX GPU? I have 4.12.1.40 Beta installed but have been reverting to 4.11 for renders. I would like to render in 4.12 because (may be my imagination) it seems to render quicker when it is not falling back to CPU. I've installed so many drivers in the past few weeks (and had Windows 10 overwrite them) that I am wary of jumping to yet another version unless there are significant improvements.

    I have a GTX1070 and see no real improvement with the new drivers - IRay preview is still prone to falling back to CPU when it has no business doing so.

     

  • marblemarble Posts: 7,500
    galien said:
    marble said:

    So are we saying that NVidia drivers 441.66 have improved matters? Has anyone tried them with a GTX GPU? I have 4.12.1.40 Beta installed but have been reverting to 4.11 for renders. I would like to render in 4.12 because (may be my imagination) it seems to render quicker when it is not falling back to CPU. I've installed so many drivers in the past few weeks (and had Windows 10 overwrite them) that I am wary of jumping to yet another version unless there are significant improvements.

    I have a GTX1070 and see no real improvement with the new drivers - IRay preview is still prone to falling back to CPU when it has no business doing so.

     

    Yes, the IRay preview thing was a separate issue as I recall. I think the new drivers might have improved VRAM management but maybe the preview thing (where it drops to CPU if you tinker with shaders or skins settings) might be a DAZ issue rather than a driver issue. I could be wrong about that though. I'm not sure whether the problem with it dropping to CPU on the second frame of an image sequence was DAZ or NVidia either.

  • JD_MortalJD_Mortal Posts: 760
    edited December 2019

    I can also repeat the "fallback to CPU", mid-render... if I try to scroll a large image fast in the render window. Leads to GPU failure, memory allocation issues and Daz's failure to release GPU memory at all, or RAM, of the associated render, unless you "Save" the image. (If you just cancel and stop rendering, all future renders will be CPU renders as the link to the cards is apparently severed and Daz can't even tell the GPUs to release the memory. However, if you kill the program, the cards dump the memory and RAM returns to normal, quite fast. Most times.)

    I can also cause it to crash by zooming in on the Gen8 eye and trying to render at 10,000 x 10,000 which easily fits in my cards VRAM, RAM and virtual-memory. However, the result is a fatal error that just kills Daz, or it simply drops to CPU again, causing the RAM to blast up from 30GB to 63.5GB, where it hits my 64GB limit, and normally just crashes fatally at that point.

    I still don't get why a 480MB PNG image, consumes nearly 2-4GB in the video cards memory, VIA Daz3D, but not by my art programs, web browser, or image previewers... But it does, apparently.

    Post edited by JD_Mortal on
  • nicsttnicstt Posts: 11,715

    You don't have swap set up? It shouldn't go out of ram, but just start using swap - slower for sure.

  • ParadigmParadigm Posts: 421
    edited December 2019

    I've actually been having fewer cases where I drop to CPU in the 4.12 beta than I did with 4.10 / 4.11. 

    Post edited by Paradigm on
  • RayDAnt said:
    marble said:

    So are we saying that NVidia drivers 441.66 have improved matters?

    That's the way it looks with my Titan RTX. Haven't had the chance to test it out yet on my GTX 1050-equipped laptop. But based on my knowledge of the underlying things at play, this particular bug fix (essentially raytracing acceleration memory leaks) should apply on both platforms. 

    Switched to 441.66 a week ago. 

    Regular Public DS 4.12.0.86 continues to be a reliable workhorse. 

    Did have to use Beta 4.12.1.40 for a bit to trouble-shoot> Did 7 morph changes (not material updates this time) in live IrayPreview in 4.12.1.40 with 441.66 and.... PC-system dropped to CPU.  sad   Whereas, in 4.12.0.86 I can do changes all day long, for days on end. 

    RayDAnt said:

     

     

    RayDAnt said:

    Did not really see anything definitive re: ""individual-scene-object-placement dependent"" other than the more objects, then the more spatial relationships etc need to be defined.  And not so much anything about subroutines for pockets of scene geometry density or anything like that.

    Imagine for a second that you wanted to render an incredibly simplistic scene with only 4 separate triangles in it where each triangle sits in its own front corner of the virtual scene space. This is what the BVH Acceleration Structure for that scene configuration would most likely look like:

    1. Bounding Box Front-Top
      1. Bounding Box Left
        1. Triangle #1
      2. Bounding Box Right
        1. Triangle #2
    2. Bounding Box Front-Bottom
      1. Bounding Box Left
        1. Triangle #3
      2. Bounding Box Right
        1. Triangle #4

    That's a heirarchical structure with a total of 10 items in it that need to be stored in a file somewhere for constant analysis by your Path Tracers.

    Now imagine rendering the same scene except this time with one triangle in the front top right corner and the rest in the front bottom left. This is how the BVH Acceleration Structure would now read:

    1. Bounding Box Front-Top-Right
      1. ​Triangle #1
    2. Bounding Box Front-Bottom-Left
      1. Triangle #2
      2. Triangle #3
      3. Triangle #4

    That's a heirarchical structure with a total of only 6 items in it (a 40% size reduction from before) despite the fact that the scene's content remains exactly the same. Hence why I say individual-scene-object-placement also plays a role in how much memory is needed to accommodate the construction and storage of these acceleration structures.

    Oh that's a helpful description.  So it does break into sub-environments for raycast compute.

    It's just like the extended Tableo of Contents of something like a physics textbook. Except that instead of breaking paragraphs of text down into chapters/headings/subheadings/etc based on topics, its breaking down collections of triangles into an increasingly detailed descriptive hierarchy based on location in a specific representation of virtual space.

     

    Do you know how specifically how many Bounding box designations there are? Don' want to assume based on your naming conventions, which may be hypothetical? or Not.  smiley  

    BHV construction is completely open-ended and infinitely tweakable. So yeah, my examples here are completely just made up by me at the spur of the moment. 

    Heh.
    My reason for asking that question and the other probing questions following that was to get an idea of best practices for scene layout.  

    Your interesting & illustrative example (10 vs 6 items in hierarchial structure) leads me to believe there may be be better ways from a camera POV (and probably items outside of camera POV for impact on lighting) to try and setup the "Scene Layout" in certain ways to optimize for BVH and reduce render times alot.  The previous example gave me hope there may be ways to do that.  The latest replies are a bit more abstract and mean I probably have to do scene testing of many different varaibles.  

    Would you happen to have any tangible examples you could share?

    And also want to say, the abstract you provided is very helpful already.  So if you don't have anything tangible, am grateful for what you shared already. smiley
    Just means I need to figure out how that applies to my scenes, and how I can improve layout, given my tendency to want to put alot of Geometry&Mats into  my scenes.

    RayDAnt said:

     

     

    And are they static or relational to scene size?

    Depends on what you mean by scene size. If by scene size you mean texture data needing to be stored, then the asnwer is no. If, however, you mean scene size in terms of scene object/polygon count  or virtual space (ie.small room vs large room) then the answer becomes either yes or sort of respectively. 

    For example, a large room vs small room.  Would the large room have more BVH "bounding box" sub-areas, or are there just more items&virtual space in the same number of BVH subareas?  This would be good to know in terms of populating a scene.  That is you keep some areas or quadrants of the scene unpopulated (similar to your example 10 vs 6).

    RayDAnt said:

    BHV Accelleration Structure complexity = camera viewpoint * scene content * scene content layout

    Hence why BVH Acceleration Structures are normally generated on the fly at the start of each render. Because nearly every rendering scenario (the exception being exactly the same scene with light intensities or textures modified) needs a potentialyl completely new BVH to describe it efficiently.

    Thanx for confirmation that camera viewpoint is a prime variable.  What role do things play that are outside of the camera view and yet affect the light ?  Like a tall bookcase, a wall, a roof, a light source etc?  This comes under "scene contents" but yet camera viewpoint acts as a filter.   Somehow seems logical all scene content despite camera POV has to be factored in to get correct lighting end-result?  So that confuses me how camera viewpoint in that case matters?

    As you can probably guess, my hope/goal is to reduce scene render times by 10-30% with optimized scene layouts recognizing BVH realities.

  • barbultbarbult Posts: 24,243
    edited January 2020

    Sometimes, when I am working on a scene in Daz Studio 4.12.1.40, Iray will apply an incorrect texture to a surface. Usually it appears to be an incorrect normal map - the normal map for some other surface in the scene. It usually happens in Iray Preview Photoreal mode. Today it happened in an actual render. The operation I did right before the problem occurred was that I set Cutout Opacity to 0 on two surfaces of the hair.

    I submitted a help request and attached the render and the scene. The scene will probably not demonstrate the problem, because after the scene is saved and reloaded, it renders OK.

    Brenna Matilda Hair bad texture on face.jpg
    1000 x 1300 - 1M
    Post edited by barbult on
  • L'AdairL'Adair Posts: 9,479

    Is any one having issues where you know you've saved your work, but after a crash, the reloaded file is missing changes?

    It just happened to me, and I know I saved a number of times after the point the reloaded file brought me to. I'm wondering if it's an anomoly with my computer, or if there is something else going on…

  • barbultbarbult Posts: 24,243
    edited January 2020
    L'Adair said:

    Is any one having issues where you know you've saved your work, but after a crash, the reloaded file is missing changes?

    It just happened to me, and I know I saved a number of times after the point the reloaded file brought me to. I'm wondering if it's an anomoly with my computer, or if there is something else going on…

    I haven't seen that. Did you save it with the same name every time (overwriting), or did you save incremental versions? If incremental, is it possible that you opened the file again from the Recent list and maybe the last listed version was not really the last one saved, because Daz Studio crashed? Is it possible that there is a later one saved that you can open manually?

    Another thought (this has happened to me blush): Did you accidently open a different version of DS (e.g. 4.11 release vs. 4.12 Beta) and so the Recent list did not contain scenes you saved with the other DS version. You clicked on the most recent scene at the top of the list, and it wasn't the one you were expecting, because the one you were expecting was saved with the OTHER version of DS.

    Post edited by barbult on
  • marblemarble Posts: 7,500
    barbult said:
     

    Another thought (this has happened to me blush): Did you accidently open a different version of DS (e.g. 4.11 release vs. 4.12 Beta) and so the Recent list did not contain scenes you saved with the other DS version. You clicked on the most recent scene at the top of the list, and it wasn't the one you were expecting, because the one you were expecting was saved with the OTHER version of DS.

    Exactly that happened to me ... took me a while to realise what I'd done.

  • barbultbarbult Posts: 24,243
    marble said:
    barbult said:
     

    Another thought (this has happened to me blush): Did you accidently open a different version of DS (e.g. 4.11 release vs. 4.12 Beta) and so the Recent list did not contain scenes you saved with the other DS version. You clicked on the most recent scene at the top of the list, and it wasn't the one you were expecting, because the one you were expecting was saved with the OTHER version of DS.

    Exactly that happened to me ... took me a while to realise what I'd done.

    The second or third time, you begin to catch on.laugh

  • L'AdairL'Adair Posts: 9,479
    barbult said:
    L'Adair said:

    Is any one having issues where you know you've saved your work, but after a crash, the reloaded file is missing changes?

    It just happened to me, and I know I saved a number of times after the point the reloaded file brought me to. I'm wondering if it's an anomoly with my computer, or if there is something else going on…

    I haven't seen that. Did you save it with the same name every time (overwriting), or did you save incremental versions? If incremental, is it possible that you opened the file again from the Recent list and maybe the last listed version was not really the last one saved, because Daz Studio crashed? Is it possible that there is a later one saved that you can open manually?

    Another thought (this has happened to me blush): Did you accidently open a different version of DS (e.g. 4.11 release vs. 4.12 Beta) and so the Recent list did not contain scenes you saved with the other DS version. You clicked on the most recent scene at the top of the list, and it wasn't the one you were expecting, because the one you were expecting was saved with the OTHER version of DS.

    No, I've only used the one version, though it's not the latest beta. I'm taking it easy on the electronics as I'm running my UPS off an extension cord. (I've apparenty been asking too much of the old wiring. Now there's a short somewhere in the circuit and we're waiting on the electrician to call back. Obviously not the best time of year to have an emergency electrical issue.)

    Also, I don't have the plugin for incremental saves.

    There are two features I don't use without frequent saves, dForce and the Geometry Editor. I distinctly recall saving the file once I set Freeze Simulation on the object I was draping. But when I opened the file, the final drape wasn't there. Neither were the two dForce Magnets I'd added or setting changes to use the Timeline. (I tried it first with two magnets and Current Frame.)

    My biggest consolation is a good half of the time was spent figuring out how to do what I needed, so at least that bit wasn't wasted.

  • ImagoImago Posts: 5,155
    L'Adair said:
    barbult said:
    L'Adair said:

    Is any one having issues where you know you've saved your work, but after a crash, the reloaded file is missing changes?

    It just happened to me, and I know I saved a number of times after the point the reloaded file brought me to. I'm wondering if it's an anomoly with my computer, or if there is something else going on…

    I haven't seen that. Did you save it with the same name every time (overwriting), or did you save incremental versions? If incremental, is it possible that you opened the file again from the Recent list and maybe the last listed version was not really the last one saved, because Daz Studio crashed? Is it possible that there is a later one saved that you can open manually?

    Another thought (this has happened to me blush): Did you accidently open a different version of DS (e.g. 4.11 release vs. 4.12 Beta) and so the Recent list did not contain scenes you saved with the other DS version. You clicked on the most recent scene at the top of the list, and it wasn't the one you were expecting, because the one you were expecting was saved with the OTHER version of DS.

    No, I've only used the one version, though it's not the latest beta. I'm taking it easy on the electronics as I'm running my UPS off an extension cord. (I've apparenty been asking too much of the old wiring. Now there's a short somewhere in the circuit and we're waiting on the electrician to call back. Obviously not the best time of year to have an emergency electrical issue.)

    Also, I don't have the plugin for incremental saves.

    There are two features I don't use without frequent saves, dForce and the Geometry Editor. I distinctly recall saving the file once I set Freeze Simulation on the object I was draping. But when I opened the file, the final drape wasn't there. Neither were the two dForce Magnets I'd added or setting changes to use the Timeline. (I tried it first with two magnets and Current Frame.)

    My biggest consolation is a good half of the time was spent figuring out how to do what I needed, so at least that bit wasn't wasted.

    It happens to me too pretty often. I'm using the latest non-beta DAZ Studio version.

    Everytime I save a scene I have to start a new session of DAZ Studio and load there the saved scene and check it for missing parts before closing the original one.

    I also noticed that some times, DAZ Studio ignores the changes when closing the program and doesn't show the Save window, simply shurting down the session. To be clear, if I click on the red cross in the window's bar after moving an object or adding anything to the scene, there's the chance DAZ Studio simply closes without any warning.

  • PadonePadone Posts: 3,688
    Imago said:

    Everytime I save a scene I have to start a new session of DAZ Studio

    Beware that if you are using multiple sessions then the settings are shared .. may be somewhat this could affect savings too.

  • ImagoImago Posts: 5,155
    Padone said:
    Imago said:

    Everytime I save a scene I have to start a new session of DAZ Studio

    Beware that if you are using multiple sessions then the settings are shared .. may be somewhat this could affect savings too.

    No, I load a new session AFTER I saved the scene in the first session (without closing it) to check if everything is place, this is the only way to avoid losing of changes. Until that moment only one session is active.

  • jjmainorjjmainor Posts: 485
    L'Adair said:
    barbult said:
    L'Adair said:

    Is any one having issues where you know you've saved your work, but after a crash, the reloaded file is missing changes?

    It just happened to me, and I know I saved a number of times after the point the reloaded file brought me to. I'm wondering if it's an anomoly with my computer, or if there is something else going on…

    I haven't seen that. Did you save it with the same name every time (overwriting), or did you save incremental versions? If incremental, is it possible that you opened the file again from the Recent list and maybe the last listed version was not really the last one saved, because Daz Studio crashed? Is it possible that there is a later one saved that you can open manually?

    Another thought (this has happened to me blush): Did you accidently open a different version of DS (e.g. 4.11 release vs. 4.12 Beta) and so the Recent list did not contain scenes you saved with the other DS version. You clicked on the most recent scene at the top of the list, and it wasn't the one you were expecting, because the one you were expecting was saved with the OTHER version of DS.

    No, I've only used the one version, though it's not the latest beta. I'm taking it easy on the electronics as I'm running my UPS off an extension cord. (I've apparenty been asking too much of the old wiring. Now there's a short somewhere in the circuit and we're waiting on the electrician to call back. Obviously not the best time of year to have an emergency electrical issue.)

    Also, I don't have the plugin for incremental saves.

    There are two features I don't use without frequent saves, dForce and the Geometry Editor. I distinctly recall saving the file once I set Freeze Simulation on the object I was draping. But when I opened the file, the final drape wasn't there. Neither were the two dForce Magnets I'd added or setting changes to use the Timeline. (I tried it first with two magnets and Current Frame.)

    My biggest consolation is a good half of the time was spent figuring out how to do what I needed, so at least that bit wasn't wasted.

    Then you're probably not using multiple folders.  Sometimes I'll save a scene, and later find it missing.  Then I'll realize Daz defaulted to a different folder I had previously saved another scene to, but since I forgot about that save, I never bothered to check if the correct folder was selected when I saved the other one.

  • IvyIvy Posts: 7,165
    edited January 2020

    I got a new NVIDIA GAMING driver update  version 441.87. has anyone used yet?  are there any issues to report?

    I had to roll back my drivers all the way back to 436.30 just t keep daz 4.12 from crashing every 2 seconds that is why i am asking if this driver has improved stability,  other wise i'll just stick with the drivers that is working

    Capture.JPG
    1459 x 371 - 52K
    Post edited by Ivy on
  • barbult said:

    Sometimes, when I am working on a scene in Daz Studio 4.12.1.40, Iray will apply an incorrect texture to a surface. Usually it appears to be an incorrect normal map - the normal map for some other surface in the scene. It usually happens in Iray Preview Photoreal mode. Today it happened in an actual render. The operation I did right before the problem occurred was that I set Cutout Opacity to 0 on two surfaces of the hair.

    I submitted a help request and attached the render and the scene. The scene will probably not demonstrate the problem, because after the scene is saved and reloaded, it renders OK.

    This. I could never explain how it happens. When I render image series, it happens; when I render individually, the problem is gone. I don't know how to repeat it, one time you look at it, it is there, the other time, problem disappears.

  • barbult said:

    Sometimes, when I am working on a scene in Daz Studio 4.12.1.40, Iray will apply an incorrect texture to a surface. Usually it appears to be an incorrect normal map - the normal map for some other surface in the scene. It usually happens in Iray Preview Photoreal mode. Today it happened in an actual render. The operation I did right before the problem occurred was that I set Cutout Opacity to 0 on two surfaces of the hair.

    I submitted a help request and attached the render and the scene. The scene will probably not demonstrate the problem, because after the scene is saved and reloaded, it renders OK.

    I've been having this problem often and it is so frustrating and time-wasting that I've reverted to the release build. It definitely occurs for me if cut out is adjusted while in Iray preview, which I use constantly. However, it also happen in my next to latest project without any opacity adjustments having been done—seemingly at random, after which I reverted to the release build. I haven't used the beta since. As well as misplaced normal maps I have also seen what looks like large dark rust patches on skin (at the same time), which looked like it might be to do with SSS or perhaps emissive channels.

    As you say, restarting or saving and reloading clears the issue. Sometimes, though it goes away spontaneously in the same session. It is present in preview and final render modes.

  • L'AdairL'Adair Posts: 9,479
    barbult said:

    Sometimes, when I am working on a scene in Daz Studio 4.12.1.40, Iray will apply an incorrect texture to a surface. Usually it appears to be an incorrect normal map - the normal map for some other surface in the scene. It usually happens in Iray Preview Photoreal mode. Today it happened in an actual render. The operation I did right before the problem occurred was that I set Cutout Opacity to 0 on two surfaces of the hair.

    I submitted a help request and attached the render and the scene. The scene will probably not demonstrate the problem, because after the scene is saved and reloaded, it renders OK.

    I've been having this problem often and it is so frustrating and time-wasting that I've reverted to the release build. It definitely occurs for me if cut out is adjusted while in Iray preview, which I use constantly. However, it also happen in my next to latest project without any opacity adjustments having been done—seemingly at random, after which I reverted to the release build. I haven't used the beta since. As well as misplaced normal maps I have also seen what looks like large dark rust patches on skin (at the same time), which looked like it might be to do with SSS or perhaps emissive channels.

    As you say, restarting or saving and reloading clears the issue. Sometimes, though it goes away spontaneously in the same session. It is present in preview and final render modes.

    Regardless of the version, I've seen skin look strange and patchy when Instancing Optimization is set to Memory. I wouldn't describe it as "dark rust patches," though, so your issue could easily be something else.

  • nicsttnicstt Posts: 11,715
    Ivy said:

    I got a new NVIDIA GAMING driver update  version 441.87. has anyone used yet?  are there any issues to report?

    I had to roll back my drivers all the way back to 436.30 just t keep daz 4.12 from crashing every 2 seconds that is why i am asking if this driver has improved stability,  other wise i'll just stick with the drivers that is working

    I rolled back too; it is a very stable version, which is a long way from what can be said about later ones.

    I'm in favour of new features, but not at the expense of stability, and quite simply basic functionality.

  • IvyIvy Posts: 7,165
    nicstt said:
    Ivy said:

    I got a new NVIDIA GAMING driver update  version 441.87. has anyone used yet?  are there any issues to report?

    I had to roll back my drivers all the way back to 436.30 just t keep daz 4.12 from crashing every 2 seconds that is why i am asking if this driver has improved stability,  other wise i'll just stick with the drivers that is working

    I rolled back too; it is a very stable version, which is a long way from what can be said about later ones.

    I'm in favour of new features, but not at the expense of stability, and quite simply basic functionality.

    Thank you for the reply , I guess then its just best to hold on and stick with whats working.  i had enough trouble the first time..sad

  • When you launch daz public build beta,
    Until it started, it was good, but there was no workspace, so when I checked the log, something like this appeared.

    2020-01-12 14:07:38.225 WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): Error in metadata for product 'dForce Master - Hair Simulation Presets for dForce Cloth Engine' (49199), metadata for file 'ecvh0 dforce master/hair dforce presets/special/hair accessories/dforce presets - 00 accessories instruction 01.duf' has no corresponding file

    txt
    txt
    log.txt
    205K
  • No panes would not be related, directly, to a CMS error. The oen you reporrt sounds like a pure content/metadata issue with one product. As for the UI, try Window>Workspace>Select Layout... - once you'v emade a choice, close DFS, wait a bit (or just check task Manager to be sure it has closed - don't end task on it though), and restart; does the layout you chose remain in effect or has it reverted to an empty window?

  • No panes would not be related, directly, to a CMS error. The oen you reporrt sounds like a pure content/metadata issue with one product. As for the UI, try Window>Workspace>Select Layout... - once you'v emade a choice, close DFS, wait a bit (or just check task Manager to be sure it has closed - don't end task on it though), and restart; does the layout you chose remain in effect or has it reverted to an empty window?

    https://www.youtube.com/watch?v=hoIGPQuntvM

    It starts up but no window appears.

    txt
    txt
    cloudLog.txt
    36K
    txt
    txt
    cloudLog.txt
    36K
Sign In or Register to comment.