SuperFly shadowing inaccurate away from scene origin



  • I can confirm the issue for both GPU and CPU render.
    Here i used EzDome + one inf. light:
    0_1542020251254_renderbug.jpg



  • @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 ;-)



  • @nagra_00_ Cheers!

    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:
    0_1542027718301_Camera+LightMovedButArtifactsDidNot.png 0_1542027741381_BodyCameraFocalPlaneArtifacts.png 0_1542027761976_Screen Shot 2018-09-15 at 3.42.10 am.png 0_1542027796598_Screen Shot 2018-09-15 at 3.29.28 am.png 0_1542027807656_MirrorOnPlaneOfArtifacts.png 0_1542027840071_YRot-135.png 0_1542027865214_HipZ+0.0.png 0_1542027884392_HipZ-0.1.png 0_1542027901093_HipZ-0.2.png
    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.



  • Don’t know about performance for 32 versa 64 bit floats on a CPU. Back in the day when we had the x87 FPU everything was calculated internal with 80 bits. With SSE this changed as we now have native 32 and 64 float support.
    About storage size, thought the smallest memory allocation for a variable on a 64 bit app is 64 bit. But i can easily be wrong here as i am out of such compiler internals since a long time.



  • The only suggestion I have is this
    Put your hrdi on the background material, not a sphere.
    Use an area light for the sun.

    There has been discussion that a sphere doesn't have all the render info with it.
    I'm not entirely sure of all the details, but it makes sense that if a sphere leaves out render info it would mess up.



  • @shvrdavid any further clues on what topic that would have been discussed under, so I can search for it?

    That's also going to be difficult if I want to have a cloud sphere casting sun shadows.



  • @shvrdavid while I was thinking about the transition from an infinite light to an area light, which I'm reluctant to do, since area lights are exclusively rectangular in the first instance, unless you meant to make something with geometry into a light emitter, I ran across an old post from @bagginsbill on Rendo in 2006 regarding a Light Meter. None of the links currently work, but the concept should be an excellent tool for matching the different lighting levels which result from area lights/mesh emitters vs infinite lights.

    Prior to setting up the color ramp nodes which the light meter consists of, I made a quick and dirty replacement, turning off the infinite sun light and slaving it's colour and intensity parameters to a cycles emission node plugged into the cycles root on the pre-existing sun sphere in my scene, which was already a light emitter, but was only using volumetric scatter and a glassBSDF node to give a nuanced image of the sun's disc when viewed at the horizon. With a prop as an emitter, the preview isn't illuminated (no big deal since I can change the preview mode), and the light isn't anywhere near as strong (due, no doubt, to inverse square light propagation being applied to the mesh light which wasn't applied to the infinite light), but the far-from-origin shadow artifacts are still evident, as they were when I'd made all of the environment spheres invisible in a previous test, so I don't think switching to the background for scene lighing will help at all.
    ***NSFW content***

    click to show

    Still the full complement of shadow artifacts at 406m from the origin. Sun Sphere at 2.77 intensity.



  • @shvrdavid Uhhh, no. Area Light for Sun doesn't work for me at the distance it needs to be to give sharp shadows (and subtend 0.53°) and approximately parallel rays.
    ***NSFW content***

    click to show

    I probably went overboard with the emissive sphere's intensity (2765 = 1000 x the infinite light intensity), but it's a lot closer than the overcast appearance in the previous render, which admittedly is mostly clear of fireflies. Can't win. Can't break even. Only thing left is to get out of the game D-X.



  • @anomalaus said in SuperFly shadowing inaccurate away from scene origin:

    @shvrdavid while I was thinking about the transition from an infinite light to an area light, which I'm reluctant to do, since area lights are exclusively rectangular in the first instance, unless you meant to make something with geometry into a light emitter, I ran across an old post from @bagginsbill on Rendo in 2006 regarding a Light Meter. None of the links currently work, but the concept should be an excellent tool for matching the different lighting levels which result from area lights/mesh emitters vs infinite lights.

    If you're talking about BB's Light Meter, you'll find it as the 4th item on this page of this "File Cabinet" --> https://sites.google.com/site/bagginsbill/file-cabinet



  • @miss-b cheers! I would have looked there eventually, but I was a bit distressed that I couldn't find a single thread older than August 2018 on Renderosity with their search, despite google finding the thread which mentioned the light meter. Of course all of the links within the thread were dead, hence my question.

    @nagra_00_ well, turning the groupingObject hierarchy on it's head did what I needed, bringing the scenery to the character, within close proximity to the origin and making the shadow artifacts go away.
    ***NSFW content***

    click to show
    though, of course, I still need to deal with render quality issue, but that re-enters the realms of possibility when the shadow artifacts are gone. The Sun angle's slightly different, but I think I can live with this solution.

    In truth, I really only need the sun sphere prop if I intend the sun to be in frame, such as a dawn or dusk situation, or when I want low angle "God rays" from cloud shadow.

    I'll have another go at the main render, and see if any of the other issues like the second skin water droplet figure rendering completely black has gone away too.



  • Side note: You can control the light fall off for light emitter by using the LightFallOff node. Something like this:
    0_1542124053191_lfo.jpg

    However i doubt that an emissive sphere works better with caustics. Placed in the distance it can be considered to be small and Cycles will have the same problems to hit it by random rays.



  • @anomalaus said in SuperFly shadowing inaccurate away from scene origin:

    @miss-b cheers! I would have looked there eventually, but I was a bit distressed that I couldn't find a single thread older than August 2018 on Renderosity with their search, despite google finding the thread which mentioned the light meter. Of course all of the links within the thread were dead, hence my question.

    I'm just the opposite. I'd rather go where I'm "fairly" sure I'll find something, than to go "searching" for it. In this case, I remember it still being active on his site, so that's where I would've gone to get it, if I didn't already have it. ~wink~



  • @miss-b interestingly, the thread I'd found from 2006 had a much earlier version of light meter prop
    0_1542167337709_Screen Shot 2018-11-14 at 2.47.41 pm.png rather than the more familiar one from 2011 which I found I'd already downloaded when it came out years ago
    0_1542167470727_BBLightMeter.png