On 6/23/22 15:48, Chris R wrote:
> I took my main scene and eliminated everything but the transparent box, and even
> added media to it and everything looked fine. I added one scene element at a
> time back and it was all fine until I added in the drip of water I had modeled
> falling from the downspout. As soon as I added that object back into the scene,
> the transparent box with media became a reflective mirror instead!
> The drip of water is modeled as a quartic. It had a material to look like
> water, (so transparent, ior 1.33, reflective, etc.). When I changed the
> material to just a simple gray pigment, the media box was no longer visible or
> reflective, but the media also disappeared.
What version of POV-Ray is being used?
Are the shapes involved part of the same union or merge?
The only obvious thing I can think of would be if the water material was
defined by name and happened to have the same name as the one used for
the media box - and the water material definition was seen last.
If you can get a simpler scene showing the issues I'll add it to my
collection for debug, though no promises as to when I'd dig. I've been
busy with other than POV-Ray of late.
--- Deeper and less likely possibility...
With some older shape types - due ill advised automatic polynomial order
reduction code combined with the lack of tight automatic / manual
bounding for some shapes - we sometimes end up with an additional root
(and so another surface) being introduced(a) by the auto-order reduction
Maybe something like this is going on but, that surface by order
reduction would have to have a very particular position to see the
results you posted.
A test for this fail would be to change your quartic to a simple sphere
or similar and see if the apparent reflection propagation to the box
(a) - One of the shipped scenes long has had a vertical line in the
result due the auto-order reduction changing two roots (4th order eqn)
to three roots (third order eqn) for one or more of the scene's shapes.
I cannot remember which it is for sure - primitiv.pov maybe? The povr
branch fixed this particular exposure(b) by ripping out the automatic
order reduction code.
(b) - Order reduction introduces slight root/surface shifts in the
intended roots even when it mostly works in a consistent way. The
reduction code also sometimes flips 'sturm on' to fixed solvers, without
notice due the order reduction, on a per ray->surface equation basis.
The sturm vs fixed solver results for identical equations are often not
themselves identical and this occasionally introduce at same surface,
subtle, consistency issues - which are sometimes visible. And there's
more 'solver noise' possible due the order reduction I won't detail -
partly because I no longer remember all the possible implications!
Post a reply to this message