SuperFly shadowing inaccurate away from scene origin
This issue has plagued me with SuperFly since it's introduction to Poser. With FireFly, such issues were usually attributable to, or at least correctable by, adjustment of Shading Rate settings for proximate objects.
I have a V4 figure in a large (dimensionally) scene. Now V4 is
famousnotorious for her transmapped eyebrows. I've also given her some transmapped hair, which closely follows the head shape at the brow, temples and cheeks. All of which renders, more or less, perfectly when the figure is placed at the coordinate origin of the scene.
However, when I try to place the figure in proximity to some buildings (Red Hill Studios' Dream Home) which are remote from the origin, due to an attempt to include actual modelled background scenery (WorldBase-Xtreme), rather than pure HDRI panoramic backgrounds, I get shadowing artifacts at the completely transparent parts (absolute black 0,0,0 in the transmaps) of V4's eyebrows and the conformed hair figure.
I thought, at first, this might be due to some number of figures limitation or number of loaded transmaps (lots of building figures with transparent window panes), but then I tried relocating the figure back to the origin, without changing the lighting at all, the figure renders correctly.
[Offsets applied to hair and eyebrow]
I'm using a groupingObject (which the figure is parented to) with constraints, to effectively change the origin of poses applied to the figure to move between rooms. Zeroing the constraint parameters of the groupingObject returns it to it's original orientation and position at the scene origin.
I suspect, but am not certain, that the render shadow artifacts I'm seeing are related to floating point underflow of the vertex coordinates when the object is far (more than 500 metres, with units set to metres) from the origin.
If this is actually the case, then a possible solution might be to always leave the subject figure being rendered exactly at the origin, and instead move everything else. but that gets really complicated when combining placement poses that include rotations. The rotations have to happen first, and in the right order before a translation, or else the scene won't match where the figure was supposed to be.
Again, it really feels like I shouldn't have to do this.
What's also less obvious from the RayTrace Preview thumbnails posted above, is that the transparent Eye Surface material covering V4's corneas and sclera is also exhibiting shadowing artifacts far from the origin, when it should be completely transparent (it's only bumpmapped to give some texturing to surface specularity).
Full face renders far from the origin also show shadow artifacts in deep creases which aren't there at the origin.
Note the cheek crease artifacts and strange eye appearance.
Interesting to note that though the chin shadow from the Infinite light Sun doesn't appear to have changed, the hair highlights are quite different (but that's another thread's worth of discussion)
How are you lighting the scene?
@shvrdavid with a single, infinite light enclosed in a glass sphere with volumetric scatter applied.
Material for Sun Sphere
Incomplete Raytrace preview at X=500 with Sun Sphere turned off (hidden), showing no difference in shadow artifacts.
@shvrdavid I'd used the glass sphere enclosure of the sun light previously without artifacts in the Marisa Miller Beach Scene many people posted renders in. I think it was titled Poser 12, or something like that. I saw no such artifacts, because all of the renders had the figure within 10 metres of the origin. This new scene uses exactly the same lighting construct, with a time of day input determining the sun light's Right Ascension.
The Sun Sphere is to give a visible disc, for renders when the sun is near the horizon.
I went to a great deal of effort to find and eliminate all of the other sources of ambient emission in the scene, and there were hundreds in the Dream Home legacy FireFly materials. They all got animated and slaved to a central control which is off. It made no difference to the artifacts, though it certainly made the night scene truly dark (I have a star envsphere that is visible when the sun is below the horizon)
D'Oh, I'd better make that invisible too for testing, but it still doesn't affect the artifacts only appearing when the figure is not close to the origin.
@shvrdavid outermost sphere is stars, next inner is sky with the Sun infinite light just inside it's surface, third is clouds which can cast shadows when in front of the sun. WorldBase has it's skydome invisible.
@shvrdavid the half-dome is a manifold atmosphere prop for volumetric (fog) effects, currently disabled.
When I turn all of the environment spheres, sun sphere and worldbase groundpland & mountain props off, so the Poser background is visible, I get exactly the same artifacts at X=500 metres.
This precision problems leads me to think that I'm on the right track with the shadow artifacts being due to floating point underflow, but gives me zero confidence that SMS devs would choose to modify Poser to compensate for this issue D-X.
Also this floating point error given a far away camera.
The answer to the question in the previous link (which I will deliberately refrain from reposting here, as that's impolite and may infringe on the poster's rights) mentions the I-Novae (previously Infinity) Render Engine as having chosen to solve these particular scale and precision problems. I concede that their scope of operations is way beyond what Poser's is presented as, but still presents the possibility of a way forward.
Of course, none of this is directly relevant to Clothing, Prop or Figure Vendors and their livelihoods, but it still presents a potential difficulty for Poser Artists, which I (perhaps without justification) still consider myself.
I can confirm the issue for both GPU and CPU render.
Here i used EzDome + one inf. light:
@nagra_00_ thank you for the confirmation. I shall submit a report, though I'm sure this will be even more onerous to fix than a core-rewrite to eliminate mesh group breaking.
Now, at least, I can change the script I was working on to delete hundreds of building-related figures in my scene to test whether they were affecting the render shadow artifacts, to one which parents them all to a groupingObject and reverse the constraint effects to move the whole environment so that the camera target figure is at the origin, rather than the other way around. Grrr! Unfortunately, until that's done, I can't do any more human renders by the Dream Home's pool side. Everything will have to be done in the main street of town! [Oops, blush! Sorry X-/]
BTW, can you confirm what distance from the origin your figure is? It might be nice to derive a distance from the origin in PNU that scene renders have to remain within to avoid these precision underflow artifacts. It's quite tragic that all of the world builders' environments are essentially useless in SuperFly renders (not that this necessarily eliminates a similar problem in FireFly renders) unless they're translated so the subjects are at or near the origin.
***=NSFW content (Black Eyes! Broken Teeth! Render Shadow Artifacts! Strawberry Apron!)***click to show
Here's what I was trying to fix, without success, yet. Imagine having let that run for a day or two, with sufficient samples to kill all the fireflies, only to discover spinach between your teeth, and that the mascara was supposed to be around your eyes, not in them!
There's also some stupid clipping plane thing happening round the forward knee! What?
Here we go, i made some tests moving the character along the x-axis. The artifacts start at about 49 PNU. Adding some security it should be safe as long as you are within a 40 PNU area around the origin.
Good point about this issue is that it can be worked around unlike others ;-)
I was so pleased that I'd worked out that all the room positioning poses I'd spent days populating the Dream Home pose library with weren't wasted, when I incorporated it into a remote location in the WorldBase-Xtreme set. Just parent the figure to a constraint which reset the origin an y-rotation to match the architecture and apply the original poses directly to the figure to place it in any room. At least that will still work. I think the whole mansion will be within a 40 PNU radius of the origin. I just have to work out the logistics of using the constraints to move the rest of the scene so the mansion's centre comes back to the origin.
This all reminds me very much of the era, decades ago, when everyone was scaling their scenes up 1000x to overcome some problem or other. I think it was to do with the scale of bump units, but I can't remember exactly, and I'm not prepared to waste hours trying to find old threads at Renderosity in the hope that they're still there. All was good until it was subsequently discovered that the bump scale fix didn't replicate in reflections. Ah, the good old, bad old days! Might have even been pre-FireFly, but I don't think that can be right, since we didn't have ray traced reflections prior to that.
@nagra_00_ looking back through some other SuperFly renders in my cache, I've just realised that I still have weird render artifacts in a scene that I know for certain is at the origin, so they're not all strictly related to floating point underflow.
The area round the knee of this figure looks similar to features I was seeing in a render I was trying to complete about two months ago, and posted in the SuperFly Renders thread the artifacts I was seeing there:
In the current scene I had to completely abandon the second skin I was using for water droplets on leaving the pool, as it rendered completely black due to the origin offset problem, but that curve on the knee in the previous post looks just like the insanity that occurred where the figure passed through this arbitrary plane.
I've left out the explanations from the screen shots which were in the SuperFly Renders thread from two months ago, but the one observation that stands out as related to both problems, is the use of an Infinite Light. I've vivid (but not necessarily accurate) memories of one of @bagginsbill 's comments that the SuperFly raytracer has trouble finding infinite lights.
Perhaps there's a better solution for outdoor, daytime SuperFly renders that a single, infinite sun light.
AFAIK the problem with infinite lights is related to caustics only. For non-caustic Cycles does use MIS that means the render engine sends a shadow ray directly to the light source as it does know where the light actually is. For caustic related issues Cycles does not use MIS and sends random rays. Its obvious that i has a really hard time to hit a small infinite light in that case. Thats why we have the tricky glass shader;)
I wonder if the origin related artifacts are a result of using 32-bit floats in a 64-bit application.
@nagra_00_ I read recently that the OpenEXR file format uses half-floating point precision to store HDR information for pixels as an intermediate between 32 bit binary RGBA and full floating point as used by TIFF, in order to present the dynamic range required without using the full storage requirement of full floating point representations, so OpenEXR files are smaller than TIFF. The article went on to say that this half-precision floating point was also adopted for internal GPU use as a memory saving measure. No doubt it also speeds calculation when less bytes have to be moved around, though I'm less certain that calculating with a smaller mantissa would be any faster. If such is the case, it may be that expediency has dictated that Poser's internal calculations are less precise for the sake of speed of calculation. [This is speculation only. I have no information which upholds or refutes this supposition]
I long ago ran into underflow territory with parameter angles in Poser's interface when trying to aim something precisely. Nothing smaller than 0.01 of a degree is significant as a parameter value. I seem to remember a brief flirtation with lower precision for the sake of performance ages ago, but that quickly got rolled back when inaccuracies were too blatantly obvious for users to accept. I suspect that Poser's transition to 64 bit code had no impact or influence on the precision it calculates with internally. I would have to ask those who know what the code base uses.
All of my current renders have caustics enabled, as there's usually water in the scene somewhere, even if it's only tears ;-).
Going to crash now. Back in a Morpheus.
@anomalaus Ok, when you are using refractive materials and do rely on Cycles caustic calculation you have to life with its limitations. Or in other words, shadow rays are terminated when they hit a surface with refraction and can therefor not collect lightning information through this optimization pass. What the tricky glass shader does is: You are a shadow ray, fine for you i am transparent.