Loading...
> >

Daz 4.11 Iray Dark Eyes Bug ?

emu42emu42 Posts: 50
in The Commons

There seems to be a serious issue with the Sclera surface shader in the new release. It turns all black when the figure is moved to a position far from <0,0,0>. The two attached images were rendered with the default G8F positioned at <0,0,0> and <1000,0,0> (and camera parented to the figure, no other objects in scene), so I would expect them to be identical. And they are, if you render the scene in Daz 4.10.

Is this issue already known/reported? Does anyone have a workaround for it?

eye_test_0.png
400 x 400 - 243K
eye_test_1000.png
400 x 400 - 244K
«13

Comments

  • emu42emu42 Posts: 50

    Just filed a bug report for this.

  • AllenArtAllenArt Posts: 7,140

    It's very late here now, but I will try and duplicate this in the morning for you :)

    Laurie

  • jepegraphicsjepegraphics Posts: 863

    This is a very nasty bug in 4.11 I fight with for a while now and as far as I know, DAZ3D is aware of it, but it is not an issue with Studio, but with NVidia Iray and they say they don't have control over it. They wait for NVidia to have a fix. For single character images I recommend moving the environment instead of the character. Thankfully grouping (Create --> New Group) doesn't take that long anymore in 4.11, so best would be to group your scene items and move them while the character stays in 0,0,0 world space. For 2 characters - well, try to keep them as close as possible to zero point. 

  • emu42emu42 Posts: 50

    But why is it just that one surface? What‘s so different about this particular shader that triggers this weird bug?

  • jepegraphicsjepegraphics Posts: 863

    I can only assume that it is a combination of geometry design and shader settings. One of my work arounds also was to open the scene in 4.10 a second time to make a spot render of the eyes and compose/add/merge it in Photoshop. indecision

  • Sven DullahSven Dullah Posts: 7,621
    edited June 2019
    jepegraphics said:

    I can only assume that it is a combination of geometry design and shader settings. One of my work arounds also was to open the scene in 4.10 a second time to make a spot render of the eyes and compose/add/merge it in Photoshop. indecision

    Not saying I know what I'm talking about;) But is it a raytracing bias thing, caused by bad eye topology? Has anyone tried pulling the eye surface out a tad in an external modelling app, to see if that corrects the issue?

    Also does this happen with earlier generations?

    Post edited by Sven Dullah on
  • PadonePadone Posts: 3,481

    I get the same with 4.10. Though at x = 10.000 instead of 1.000. With x = 1.000 it works fine.

     

    eyes.jpg
    480 x 270 - 40K
  • xyer0xyer0 Posts: 5,691

    Good to know. No update for me then.

  • 3CPO3CPO Posts: 156

    I ran into this issue for the first time when I made my large "High Hopes For A New Beginning" sci-fi scene. And it was with DS 4.10 and those were genesis 3 characters. So it is not DS 4.11 related. The sclera actually turns dark red  as if the skin SSS hue is leaking in and seems to be happening only to genesis characters. I did try to modify the shader of the sclera, enlarge the eyes and hide the cornea among other things. Did not have time to try them all but my successful workaround was indeed to shift the environment instead of the characters. Hope the origin of this bug or anomaly is tracked down and fixed.

  • LosingSignalLosingSignal Posts: 409

    After some fiddling around, I found that the problems start kicking in around X = 4000 and Z = 2100, showing up as concentric rings inside the sclera that get bigger the further out you go and tiny imperfections closer than that.  The problem seems to take more distance to kick in if you use a G3 texture instead of a G8 one, and if you put the G8 texture on a G3 character, the problem remains (so its probably not geometry).  Also, by the time you it X = 10000, Z = 10000, Victoria 8's skin is getting pretty red, plus an added hair model made a black blob appear on her forehead.  Considering the problems aren't just related to the sclera, yeah, it looks like a problem with the rendering engine.  Maybe it's Studio's implementation, but it looks like just weirdness with the way light is being modeled.

    Thing.jpg
    1188 x 973 - 429K
  • WendyLuvsCatzWendyLuvsCatz Posts: 37,836

    It does it in Octane too on Genesis 8 as the geometry is too close for the render engine 

    setting Ray epsilon to infinite fixes it there

     

  • jepegraphicsjepegraphics Posts: 863
    edited June 2019

    I can confirm that it is not only the sclera, especially polygons intersecting from a hair skull cap with the head geometry let holes appear in the forehead I had to correct in postwork several times. Unfortunately, as already said, it is the new NVidia Iray version that is implemented in 4.11 rather than the Studio software. NVidia has to find a solution, if then it is a problem that is important enough for them to consider a 'problem'.

    Post edited by jepegraphics on
  • WendyLuvsCatzWendyLuvsCatz Posts: 37,836
    jepegraphics said:

    I can confirm that it is not only the sclera, especially polygons intersecting from a hair skull cap with the head geometry let holes appear in the forehead I had to correct in postwork several times. Unfortunately, as already said, it is the new NVidia Iray version that is implemented in 4.11 rather than the Studio software. NVidia has to find a solution, if then it is a problem that is important enough for them to consider a 'problem'.

    I don’t think Nvidia’s world evolves around DAZ studio cheeky

  • jepegraphicsjepegraphics Posts: 863
    Wendy_Carrara said:
    jepegraphics said:

    I can confirm that it is not only the sclera, especially polygons intersecting from a hair skull cap with the head geometry let holes appear in the forehead I had to correct in postwork several times. Unfortunately, as already said, it is the new NVidia Iray version that is implemented in 4.11 rather than the Studio software. NVidia has to find a solution, if then it is a problem that is important enough for them to consider a 'problem'.

    I don’t think Nvidia’s world evolves around DAZ studio cheeky

    Hehe. I certainly agree. laugh Maybe DAZ finds a solution, if then they consider this major enough. But for now I assume the few people who complain about this are not enough...

  • Deadly BudaDeadly Buda Posts: 155

    This happens on objects with opacity maps in general on 4.11 and 4.10. My previous fixes have been to null or group everything and move them close to 0,0,0 but for some reason the scene never looks the same to the camera. Sometimes the camera moves all over, too. It will happen with some objects, not others. I think I will try Padone's suggestion, just divide everything in general parameters by 100 or 1000 or whatever and see if that replicates the scene set-up better.

  • emu42emu42 Posts: 50

    I finally found a way to work around this issue. It does not show up when I set "Instancing Optimization" to Speed in the render settings.

    Usually I use Memory instead in order to keep scenes small enough to fit into GPU memory (I like to use UltraScatter a lot to populate the background with plants and stuff). So I may end up doing the final render on the CPU, but that's still the best solution I have so far.

     

  • outrider42outrider42 Posts: 3,679
    This bug has been around for a very long time without any fix. I can't remember exactly, but there are other threads about this that predate 4.10. I believe it has always been a problem with Iray from the very beginning with 4.8.

    What is happening is related to transparency somehow. The rays being cast by Iray are not properly penetrating things that have a certain transparency as you get further away from the world center. Notice that all of these surfaces involved have highly transparent properties. The eyes have a clear eye moisture surface, hair is trans mapped, and most skin has some transparency for the its sub surface properties. You would get a similar effect by reducing the number of times the light is allowed to bounce. Like if you turn light bounce down to just 3 or 4, you may get the same eyes even at the world center. So its like the distance from the center is screwing up light bounce properties.

    Try turning the eye moisture off and see if that helps. (Take the opacity down to zero.) This will expose the other eye surfaces, though you will lose the eye reflection doing this. It may not matter if you are far from the camera. But otherwise there is no fix other than moving the entire environment and have the character closer to the base 0,0 starting point.
  • ShozaiShozai Posts: 30
    edited August 2019

    I had the problem when I moved my figure too far from "0". When I changed all parameters (X, Z, Y) to 0, everything was fine again. Sometimes the set lights cause a problem.

    Maybe this will help you.

     

    Edit: Oh, i just see that is not what you can help :D well, tried :p

    Post edited by Shozai on
  • Strange VoyagerStrange Voyager Posts: 390

    THANK YOU! I spent ALL day troubleshooting this. It carries over into the MTL file of exported OBJs too. It never once occurred to me that this would be a bug introduced by DAZ Studio.

     

  • emu42emu42 Posts: 50
    outrider42 said:
    Try turning the eye moisture off and see if that helps. (Take the opacity down to zero.) This will expose the other eye surfaces, though you will lose the eye reflection doing this. It may not matter if you are far from the camera. But otherwise there is no fix other than moving the entire environment and have the character closer to the base 0,0 starting point.

    Thanks, I might still try that eye moisture trick. Not much fun rendering on CPU. ;)

    One thing I noticed that makes this issue even worse is, that it can occur even with the figure at the origin position. If your character looks up or down at a steep angle it will show even there. So you might end up having to rotate your entire scene as well to fix that, which in my cause would mean I'd have to abandon the Iray Sun+Sky environment setup to do that.

     

  • emu42emu42 Posts: 50

    Wooohooo! It looks like this whole issue has been fixed in 4.12 now. I tried in two diffferent scenes that have this problem in 4.11.

    Can someone confirm that it's all gone in the current beta?

  • outrider42outrider42 Posts: 3,679
    I have not tried a scene that had this issue yet, but this is very long awaited good news. Remember Iray has been totally overhauled in 4.12 because OptiX Prime has been replaced by the full OptiX 6.0. So this bug may have been a problem with OptiX Prime itself.

    I'll try to test it when I get the chance. If true, that's another reason to go with 4.12.
  • OstadanOstadan Posts: 1,123

    I find that it is actually worse in 4.12.  Here are renders of G8F at the origin, x=2500, x=5000, and x=10000, for 4.11 and 4.12.  The 4.12 renders show that the blackness encroaches more, and starts sooner, than in 4.11.

     

    all11.png
    3200 x 800 - 2M
    all12.png
    3200 x 800 - 2M
  • emu42emu42 Posts: 50
    Ostadan said:

    I find that it is actually worse in 4.12.  Here are renders of G8F at the origin, x=2500, x=5000, and x=10000, for 4.11 and 4.12.  The 4.12 renders show that the blackness encroaches more, and starts sooner, than in 4.11.

     

    Odd. It renders fine for me now even at x=100000. Also works with either instancing optimization option: "Memory" or "Speed". I remember trying with an earlier 4.12 build with the same issue, but not with 4.12.0.60 it seems OK. I'll check some other scenes that used to have this problem...

  • outrider42outrider42 Posts: 3,679
    Yeah, which specific version of 4.12 are you on? And did you update your graphics driver with it? The new Iray requires a pretty recent driver, I think 430.86+.
  • OstadanOstadan Posts: 1,123
    edited August 2019

    Odd indeed.  This was done on a Mac, CPU only.

    Further information: this is DS 4.12.60.  I also have a PC with the latest GeForce Game Ready drive (436.15).  The results are the same on the PC.  Graphics card is RTX 2080.  So it is pretty mysterious to me that emu42 and I get such different results.

    Edit: oh.  I tried 'Instancing Optimization=Memory, and it rendered correctly!  I hope DAZ is reading all this.

    Post edited by Ostadan on
  • outrider42outrider42 Posts: 3,679
    Very interesting indeed. I wonder if this has been discussed on the official Nvidia Iray forums.
  • bsmcbride_b4dcae9181bsmcbride_b4dcae9181 Posts: 13
    edited August 2019

    Not sure if this helps, but I had a very (very) similar bug when using The Kids 4 with the awesome figure Katie for K4.

    After fiddling with lots of settings and reading a number of articles, I found an article on a site for Blender and it talked about a glossiness node.  I checked, found a "glossiness" setting and cranked it down to zero.  Viola...dark eyes are gone.  The eyes don't look glossy now, but it's better than them almost looking black.

    This may not work for other figures, but it worked using the K4 figure.

    Cheers.

    *edit* - just an extra note that this was on the eye surface that I made this change.  Your mileage may vary.

    Post edited by bsmcbride_b4dcae9181 on
  • emu42emu42 Posts: 50
    edited August 2019

    Ok, this issue just keeps getting weirder. I thought there was no problem with instancing optimization set to Speed instead of Memory, but now with 4.12 it's the other way around. Memory looks ok, Speed is messed up, and Auto looks even worse (?!?).

    See my test renders with G8F at <10000,0,0> rendered on GPU RTX 2080 Ti with Driver 436.02.

    First Daz 4.11.0.383 (Memory, Speed, Auto):

     

     

     

    daz4_11_0_383_memory.jpg
    400 x 400 - 36K
    daz4_11_0_383_speed.jpg
    400 x 400 - 36K
    daz4_11_0_383_auto.jpg
    400 x 400 - 36K
    Post edited by emu42 on
  • emu42emu42 Posts: 50
    edited August 2019

    Now Daz 4.12.0.60 (Memory, Speed, Auto):

    daz4_12_0_60_memory.jpg
    400 x 400 - 35K
    daz4_12_0_60_speed.jpg
    400 x 400 - 36K
    daz4_12_0_60_auto.jpg
    400 x 400 - 36K
    Post edited by emu42 on
Sign In or Register to comment.