Is DAZ addressing the Black Sclera when character is far from world origin issue?
jdavison67
Posts: 650
in The Commons
I've run in to this problem way too many times now.
It seems like this should have been addressed by now, without us having to build new morphs to push the eye moisture out.
JD
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Itbis, as far as I know, an Iray issue so not soemthing Daz itself can address.
I could see it as an Iray only issue if the workaround wasn't to expand the eye moisture layer.
I would think they would at least make the eye moisture layer morph a standard morph option at least...
But I get it...
JD
The problem is, as I understand it, the limitation of floating point numbers - they have only a certain number of bits each, so can carry only a limited number of significant digits. As the part in front of the decimal needs more digits, moving away from 0, so there are fewer available for after the decimal and so Iray can no longer correctly resolve the gap between close surfaces. Why it affects Iray and not other engines I don't know - at a gess it's related to the way the scene is represented, to the precise calculations performed, or both (or something else entrely).
Adding a morph to increase the gap might well be a sensible feature request for figures.
It is an Iray specific issue, Daz has no control over that. Though maybe Daz reps could ask the Iray devs about fixing it. Its existed ever since the introduction of Iray. All you can do is use either Speed or Memory optimization and see which works better. Some people say Speed works better now, and would have agreed, but then I had a scene just a week ago that clearly worked better with Memory than Speed. I tried it multiple times to verify. But other times Speed is indeed better. Why it might change from one to the other I have no idea. I would stay away from "auto" as it seems to always be the worst possible option.
You would have to contact the developers of Iray about this issue.
BTW I made such a morph for G8 Female which is at sharecg. Its pretty much universal so should work on any G8F. However, the black sclera is only the most visible issue. If you are getting the black sclera, it is highly likely you are getting other issues that maybe you are not noticing. You can get this issue in hair scalps and other hair items. Go far enough from world center and you might also find seams on the borders of UV maps for skin. Geografts can also be effected. Basically any surfaces with transparancy that touch each other can present this issue depending on how far from world center you go. So you might want to take a close look and see if there are other spots like this in your render.
May be this is relevant to explain the issue. And why they don't fix it. The article is 10 years old but it says that using double precision would make iray 8x slower. If you ask me it doesn't make sense to have a pbr engine with single precision, it may be good for game engines.
https://stackoverflow.com/questions/2816992/double-precision-floating-point-in-cuda
My workaround has been to group my entire scene and move the area I'm rendering to the world center...It ain't fancy...but it works.
Thanks all!
JD
Just noting that this issue also extends to other reflective surfaces. I've seen a bit of wonkiness with say polished chrome when the item in question is a significant distance from world center. Mentioning this as it's related to this issue, and would be relevant to anytihng that Daz/Nvidia might want to fix in the future. Also, to let people know it's not just eyes that are affected by this issue.
Yeah, like I said this effects way more than just the sclera, its just that the sclera is usually the most noticeable.
But does this happen in other render engines? Or just Iray? There are certainly other engines that rely on CUDA and are also pretty fast. If this is an Iray only issue, then yes Nvidia (or whoever is handling Iray) really needs to address it. Since this does effect a lot more than just sclera, it only makes sense that this should be kind of important.
After all, Iray is supposed to be PBR, a physically accurate renderer. This...is not physically accurate! Its kind of hard to take it seriously when it has a problem like this. Given that newer versions of Daz Iray have 3 options for optimization rather than 2 (even though one is 'auto'), it is possible they have made some attempt of addressing it.
The thing that gets me is how in one scene "speed" works better, and in another "memory" works better. I would really like to know why that is. It used to be that memory was the logical choice, but in 4.12 many people say speed is better now, but my own testing it seems almost random which setting works better. Speed does seem to work more often, but it is not always the case. So the only thing I can say is if you see this issue, you have to try both options and hopefully one will work better. And of course the other option being relocating everything around your character of focus point as world center.
Is this the same anomaly as black squigglies appearing on a characters face and mostly forehead?
And is there something to turn invisible ( a sclera?) to remove the squigs- for a composite spot-render patch?
The instances optimization is for instances, it is basically meant to decide how many items get instanced at the same time beacuse this makes things faster for the render engine at the cost of more memory. It should do nothing for non-instanced geometry such as eyes. If it does then it is a side effect of some sort and it only means it's a bug affecting another bug, that's different from a fix.
Then I agree that the precision issue should be fixed by nvidia, but from what I found around it seems this would make iray much slower.
Dark Eye Fix From World Center
https://www.sharecg.com/v/94366/
I find myself having to hide head caps / skull caps on very recent products in the DAZ Store even with the character wearing the hair with the offending hair cap at (0, 0, 0). If looks like someone bloodied their forhead when that happens.
If that is an nVidia iRay SDK bug then nVidia need to go back to the drawing board and fix it.
I've gotten around this by shifting the entire scene, of course, but I wonder if a possible workaround for Daz Studio would be to dynamically shift the location of all the top-level objects so that the camera through which iray was rendering was at (0,0,0). In other words, "center the camera" as it passed everything to iray. This way, anything close enough for this effect to be seen would also be near zero.
Of course, this might introduce other problems...
just musing...
In my experience (like many) switching to speed optimisation instead of auto or memory fixes the issue. Personally, this seems to always work for me, although some people indicate that it doesn't always work and I'm not disagreeing with this. Anyway, this could offer another easy fix, just have the software default to speed optimisation instead of memory optimisation.
The thing is, if it's working in speed optimisation and not in memory optimisation then this implies that something is being done differently. I recall (I think in ULTIMATE Grass & Meadow Worldbuilder package) it was mentioned that you need to switch to memory optimisation to get instancing to work properly, that is without just increasing the geometric memory usage. If you try to use UGMW with speed optimisation, it will just crash, unless you have a crazy amount of memory.
The big question is, why would enabling instancing cause an issue if you only have one of something?
What I think might be happening is that the rendering system is instancing everything, even if there is only one of something. A reference version is created and then that reference is multiplied by scaling and added to the positional offset which might introduce floating point errors. If this is true, then the fix could be as simple as either not having instancing used for singular objects (side-by-side with stuff that is instanced, this may not be possible with the framework) or ensuring that the positional offset is 0.0 and the scaling is 1.0 to the reference.
Makes me miss Reality even more.
Yes, floating point numbers are the bane of digital computers. Think about the teeth of a comb. Some have them very close together and don't tend to do much hair at once, while comsb with teeth further part will cover more hair, the combing will not be as fine. So floating point support either holds large numbers with limited decimal places or smaller numbers with many, many decimals places.
That's the thing, this setting has been known to effect this black sclera (and other things) for some time. It used to be that flipping the option to memory would help. In recent versions of Daz, I am not sure when it started, using the speed option seemed to help more often. Recently I had a hair that was giving me this issue, a portion that was supposed to be transparent on the forehead had marks popping through it. I noticed Daz had defaulted to 'auto' for some reason. I switched it to speed, the marks were smaller, but not gone. I tried one more time with memory, and this time the marks were totally gone. Nothing in the scene was instanced at all. Actually I rarely ever use instances. However, for other scenes I had the opposite hold true, speed made the marks go away, while memory did not. While the "auto' setting performed the worst of the three. (Which again makes me wonder just what on Earth is "auto" supposed to be doing???)
Either way, make no mistake, the instancing optimization has had an impact on this for a long time. If you search for this issue and go back far enough in time, you will find forum posts discussing that the setting for memory sometimes helped with this issue. So that does add to the question as to what exactly is going on, and why I do not believe this is just a floating point number issue. Plus there are plenty of other CUDA GPU rendering engines that do not seem to have this problem, at least as far as I can tell, and they can be just as fast or faster than Iray.
The scenes where I had this issue pop up were somewhat large. I have a couple 1080tis, and the scenes in question were starting to push the limit on their VRAM. So considering that instancing optimization impacts it, perhaps there is a memory problem with Iray.
what if you set the eye surfaces to dzdefault shader?
iirc, it is possible to use a iray and a dzdefault on the same figure.
i usually convert all the transparent surfaces to dz default shader.
Similar to the ENORMOUS pins when far away from tyhe origin, the only solution I know of is to parent the scene to a null and move your focus point to the world origin (and remember to unparent cameras after!)
i do that to move the dream home rooms around.
Translucency/opacity artifacts are now regularly occuring even when character is at (0,0,0) in the newest DAZ Studio 4.1.12.55 but not to the point of making the entire sclera black.
Is that with all 3 of the instancing options?
Iray itself has not changed in this version since the previous release. Did you have the last version of Studio or did you skip one that had an update to Iray?
I have not actually updated Studio in a while, before the whole Multiple Instances of Studio Saga® began. And since Studio is currently working fine for me, I have felt no urge to beta test anything nor play with fire.
Here's why changing Memory Optimization has an effect on this (despite the fact that memory optimization itself indeed has nothing directly to do with the matter at hand):
3.6.2 Increasing computational precision and accuracy
When instancing mode is set to “on”, “auto” or “user”, the scene is automatically shifted in space. This increases the precision and accuracy of rendering computations and reduces precision artifacts that originate from self-intersection. To disable this behavior, set bool instancing_shift_camera to “false”. - NVIDIA Iray Programmer's Manual
In other words, each time you set Memory Optimization to either Speed or Auto (in scenes where there are no instance-friendly objects present) and then set it back to either Memory or Auto (in scenes where there are instance-friendly objects present.) Iray is transparently shifting (no XYZ coordinates reported in the Daz Studio interface change as a result of this) the center of the entire scene to coincide with whatever camera is currently being used. Thereby eliminating the black sclera phenomenon from view - until you get around to reconfiguring your scene enough to once again end up with a visible scene space/camera arrangement far distant from the scene's true mathematical center.
As to what it is exactly that is going on here in the first place - it does indeed have to do with the inherent limitations of floating point math structures. It is officially known (to some, at least) as "shadow acne" and is a type of self-intersection artifact resulting from surfaces inadvertently casting shadows on themselves due to running out of bits for storing a precise number to the right of the decimal point. Here's a 9-page paper from Raytracing Gems (published just last year) written by two Nvidia developers wherein they describe the issue in detail as well as the various methods used to mitigate it.
And it isn't just an Iray issue. Any physically based rendering engine is suceptible to it once object distances from center begin to exhaust the bounds of whatever precision of floating point math the engine uses.
I always use the latest public beta but I'm guessing that the problem occurs on multiple public beta versions I've used in the past.
It was super bad on, eg, Ezra's scleras. Only one character in the scene and it's at (0,0,0) and has such a problem like that is hugely disappointing.
I'm rendering a different scene outdoors now with sun-sky & a spotlight with seemingly no similar problem while the problem scene with Ezra involved lighting from the Ultra Genesis product line so perhaps that's the problem. It was like a lot of very visible black lines reflecting something elsewhere in the environment meandered their way through as reflections on the surface tears on the character's eyeballs. Something that would not happen in the real world I don't believe. At least I've never seen that. If that's realistic iRay lighting, nVidia, please show me a real world example of that happening.
Thank you for the explanation, always very interesting as usual.
No, those are generally a problem caused by the hair cap not fitting properly on the character. The fastest way to get rid of them, is by slightly scaling up the size of the hair cap. Somewhere between 1 and 5 percent usually suffices. I think there is some better method by refitting or conforming or something, but would need someone else to mention again what the method was.
I just switched to iray at the beginning of the year and recently ran into this problem too, as well as body moisture shells acting this way. Changing my scenes to make characters at world center is a no go for me, so I've been experimenting a little. For the body moisture shell, I've had some success by increasing the shell's offset, but the further from world center the more I'm having to increase the offset (doing this right now). For the sclera I've had some success by changing the refraction weight (may have also changed refraction index but can't check right now) - this has helped to get rid of the blackness, but no doubt it is negatively affecting the reflection quality and other appearance qualities.
Will give Kerya's suggestion a try.
Just change your Instance Optimization setting. It's one dropdown box, and you don't need to fiddle with surfaces or shift objects around.
But beware: as Padone mentioned, "Speed" disables instancing, so you need to use "Memory" if your scene has a lot of instances.
See my post above. Just toggling the control between the available settings in the dropdown is what "fixes" the problem. Just make sure to switch it back to the vaule you actually want after playing around with it.
All rendering engines have their quirks, so I wouldn't get all upity about this.
Octane doesn't have this issue, but it goes black when geometry intersects. V4 and M4 eyebrow planes show the issue best. Hair caps may also show this. Push Modifiers can help with hair (then dial it back till you're happy).
As a programmer who only writes real time number crunching firmware, I can say doubling precision isn't simple, and may or may not even solve it, and it will most likely cost a hefty amount of performance.