Fixing Black Forehead Lines, Black Eyes, and Red Skin Correctly
margrave
Posts: 1,822
Because people keep making this issue more complicated than it needs to be...
Floating point numbers have inherently limited precision. When objects are too far from world origin (0,0,0), it introduces rounding errors into the calculations that affect the quality of the render, typically transparency and subsurface scattering issues in the eyes and skin or Z-fighting that makes black lines appear around the skullcap. Circa 2019, the Iray engineers programmed a way to fix this into Iray, and it's dead-simple. If you change your Instance Optimization setting to "Memory", Iray will re-center your scene at world origin, restoring the lost flops precision and making all your rendering calculations more efficient in addition to solving self-intersection errors.
Yet people on these forums keep offering less effective (changing the scale and/or morphing the skullcap) or outdated (parenting your scene to a null and manually moving it to world origin, which is only useful for pre-2019 versions of Iray) solutions, which are then picked up by new users Googling these forums for solutions. These solutions might work, but they are objectively inferior to the one solution which improves all of your rendering calculations and solves most self-intersection problems with a single dropdown box.
Even if you don't have rendering issues, it's still a good idea to set your Instance Optimization to "Memory" due to the (however slight, depending on your distance from world origin) accuracy improvements.
Let's see how good it is.
Jonathan 8 with autofitted Stella Hair, positioned 1,000 centimeters away from the origin on the X axis. As you can see, with Instancing Optimization set to "Auto", it's introduced some artifacting near the hairline.
Changing Instance Optimization to "Speed" offers a slight improvement, but it's still visible.
Changing Instance Optimization to "Memory" solves the issue completely.
Next, Jonathan has been moved to 10,000 centimeters from the origin. On "Auto", the self-intersection has started carving chunks out of his mesh.
On "Speed", the problem is again diminished, but still evident.
"Memory" fixes the problem entirely.
Still don't believe me? Let's try moving him to 100,000 centimeters from world origin.
"Auto".
"Speed".
"Memory".
How about 1,000,000 centimeters from world origin?
At this point, the extreme distance has started to distort the actual vertex coordinates, and changing Instance Optimization can't fix that.
"Auto".
"Speed".
"Memory".
Despite the noticable vertex distortion, "Memory" still fixes most of the material issues.
If you see a rendering artifact, the absolute first thing you should reach for is that "Instance Optimization" button, 100% of the time. Only if that fails to solve the problem (and it rarely fails, in my experience) should you start reaching for the other, lesser solutions like (in order of effectiveness and convenience) a smoothing modifier, morphing/scaling the scalp, or using Mesh Grabber.
Edited to Add:
Sometimes when moving a figure or changing a camera, the program will not update correctly even if Instance Optimization is set to "Memory". If that happens, just change the value to one of the other options and then change it back to Memory to refresh the mesh.
For this reason, I'm not sure if this technique would be suitable for animation, but frankly I wouldn't recommend Daz Studio for animation anyway.
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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Coincidentally, I just started a thread about placing figures far from World Centre too. They both appeared together just now.
Just a quick comment about the black lines on the forehead ... sometimes it IS the skull cap and the fix IS to change the scale slightly. I say this because those lines show no matter where the figure is placed (even at WC).
I covered that in the last paragraph. Change Instance Optimization first, and then try other solutions. For the 1% of times Instance Optimization does not work, a smoothing modifier will conform the skullcap to the head perfectly and prevent self-intersection.
Yeah, unfortunately we have three threads going now discussing the same thing for various reasons.
Only three?
That's a good day.
@margrave be advised that Iray uses the currently active camera position to determine what becomes 0,0 on its own internal coordinate plane and not Daz Studio's definition of 0,0 for a given scene when a re-centering of its coordinate plane is triggered by eg. cycling through the options on the Instancing Optimization dropdown list. Meaning that in situations where the camera is placed very far away from and zoomed in on objects/characters in a scene, cycling through Instancing Optmization options can actually cause these anomalies (precision artifacts) to show up rather than eliminate them. Scene composition is key.
I did some tests, and while what you said is true in certain circumstances, you need an absurdly high focal length (well beyond what a physical camera is capable of) to even see the rendering artifacts on a distant figure, while if you changed it to Speed then anything that's not in the narrow plane defined by the world origin would suffer from the same rendering artifacts.
Iray was designed for car manufacturers to make showroom/product renders, which is why the default units are centimeters and not meters. If you want to render distances well, you need an engine with meters as its default unit, like Cycles.
Stick to photorealism (i.e. don't take your focal length above 300mm). Iray wasn't designed to work beyond the limits of physical cameras.
Or to have unwittingly switched between camera angles in a scene with multiple cameras (spaced far enough apart) in an order that results in precision artifacts for the last camera selected. There are ways to run into this that have nothing directly to do with going beyond the bounds of photorealistic photography or scene composition.
Precision artifacting occurs because of limitations in how precise floating point values are able to be calculated in relation to each other in a given situation - not because of what unit happens to be defined as 1. Cycles is every bit as susceptible as Iray to precision artifacts in scenes with a combination of extremely close things (such as skin layers) and extremely far away things (such as mountain ranges.) If Cycles seems better at avoiding such artifacting then it would be because of better management on the host application side (practicality requires render engines like Iray/Cycles rely on Daz Studio/Blender to make desicisons like this) of automatically recalculating 0,0 when scene composition changes call for it. Which wouldn't be a shock since Daz's developers only started actively paying attention to it as an issue early this year (see bulletpoints 4-6 in the Daz Studio changlelog for 4.15.0.12.) There's still a lot for them to be doing to be making this largely a non-issue.
You're right, but I always check and make sure there aren't any rendering artifacts before doing a final render. If there are, then I refresh the Instance Optimization and they go away.
But I'll add that to my first post.
Blender does not recalculate world origin. They experimented with changing it, but it didn't work and it's still using raw coordinates.
I don't think you're correct about floats only being calculated in relation to each other. If that was true, then moving Jonathan 8 1,000,000 units along the X axis wouldn't affect his vertex coordinates, since there's nothing at world origin his vertices are being compared again. So it must be the actual coordinates degrading due to precision errors.
For what it's worth, neither does Daz Studio (remember that Iray is technically an entirely separate entity - with its own internal corordinate grid and mathematical calculation pipeline completely separate from what Daz Studio presents to the user.) Which is why:
The reason why there are still noticeable distortion artifacts in Johnathan 8's shape in the final example you gave above (despite virtually all of the material surface self-intersection problems going away thanks to playing around with the Instancing control) is because those distortions originated with Daz Studio itself - not Iray.
Consider this non-authoratative complete lifecycle of Johnathan 8's vertex and material surface coordinates in that final series of examples:
Thus resulting in the abomination of your final series of examples. By moving the active camera to a reasonable distance from Johnathan 8 and triggering a reset of Iray's coordinate plane to that camera's position (what playing with the Instancing Optimization control programmatically does) you are able to correct the precision artifacts caused by Iray in step 5 and 6 above. But there is no way to correct for the distortions originating from Daz Studio itself in step 3 short of moving Johnathan 8 in Daz Studio closer to center and then resending the scene to Iray.
Garbage in, garbage out.
Great thread people. Margrave's solution in the OP works beautifully.