On 6/27/22 10:23, Chris R wrote:
> In the scene, there is a quartic "drip" with translucent texture and an ior of
> 1.33 sitting behind a hollow box with a transparent pigment.  When I render it,
> the sides of the box become visible and seem to take on the texture/interior of
> the drip rather than the completely transparent texture I assigned.

The short explanation
---------------------
It's an issue with infinite shapes and inside determination which, here, 
can be fixed by manually bounding - and then rendering turning the 
stripping of user bounding(+ur) off with -ur.

I used a sloppy bounding box shape of:

           bounded_by { box {
             <-10, 0.1,  -2>,
             <10, 20.1,  +2>
             }
         }

A longer and still wildly incomplete description
--------------------------------------------------

The polynomial shape is generally treated as an infinite shape unless 
the user manually bounds it - and users always should... The 
insided-ness of any particular region - on seeing surfaces as the ray 
'travels'  becomes a flip of the coin without bounding(a). The shapes: 
cubic, quartic and poly have long been mapped to the polynomial shape 
internally(b).

(a) - Lying some. The better the manual bounding the smaller the lies.
(b) - Even the older explicit shape code often had similar issues as do 
shapes still with custom code like the quadric(b1).

(b1) - Which itself has unreliable auto-bounding - which at its worst 
differs depending upon CPU/compilers/build settings as reported a few 
years ago.

Some background. Internally, there is an initial atmospheric IOR value 
which is 1.0 unless changed in code as there is no way to access it via 
SDL. At any surface a working IOR is calculated based on the transition 
from the current IOR to the one specified by the new surface. The 
infinite shapes IOR value, if inside that shape, get used instead for 
the 'about to exit region' IOR value(c).

(c) - Yes, I think where we have >1 infinite shape testing as initially 
inside, what happens or even knowing what should happen is likely messy.

Other SDL ways to verify what is happening.
------------------------------------------

- We can add and interior { ior 1.33 } to the box making its IOR same as 
the infinite ior (from the not really inside inside ior of 1.33).

- We can flip the insided-ness of the quartic to be correct by adding 
the 'inverse' keyword rather than by adding user/manual bounding, but 
this a less 'good' option.

- We can trip the issue with the infinite plane rather than the quartic 
by changing to 'plane { -y, 0 ... } and setting the interior ior to 1.33.

- Things like a sphere with inverse, an ior of 1.33 and all boudning 
off(d) should work as a trigger too, but I didn't try it.
(d) - This an experiment which cannot be done with official v3.7/v3.8 
versions because -mb doesn't fully turn off bounding as it did in v3.6 
and prior.


Other random ramblings
----------------------

- The quartic drop is inside the box.

- The drops IOR treatment is backward in cases where it showed up in the 
shipped test case.

- In my povr branch once it was getting the proper IOR / insided-ness 
treatments it was a noisy result without 'sturm on'. Probably similar 
will be seen in official releases, but povr's solvers are different.

- The issue here is not at all tangled in the order reduction code 
problems in the shipped versions of POV-Ray as I supposed might be so in 
the binary images group thread.

- I changed the scene so the box is using filtered transparency and a 
partially transparent inside texture to better see the box.

- Image attached with the user bounding in place and using -ur to turn 
off the stripping of such user bounding.

- It should be once user bounding is in place you can flip renders 
between -ur and +ur and see the infinite shape count reported in the 
text output change.

- How the insided-ness gets done is different shape to shape. I'm not 
sure the user bounding get's used to 'initialize' the insided-ness in 
all shapes. It might be inverse is sometimes needed too(e)
(e) - IIRC a few old shapes don't handle inverse correctly (quadrics one 
I think).

- Anytime the inside test is off/wrong resulting csg can be too, though, 
this not an issue with unions.

Bill P.

Post a reply to this message

Attachments:
Download 'story.png' (182 KB)

Preview of image 'story.png'