

On 7/10/22 15:27, jceddy wrote:
> Can I inversetransform the point being tested, run the minimumdistance
> calculation against the original data to get a minimumdistance*VECTOR* from
> the test point to the original mesh, then just apply the object's transformation
> matrix to that vector before measuring its length?
I've never attempted a complete survey, but I'd say this the more common
approach inside POVRay's code for various calculations, but it's not
universal.

The numerical issues Cousin Ricky suggested as applying to the inverse
transform in particular(a) are very complicated on the whole. Especially
true in POVRay's code base where over the years numerically
inconsistent numerical approaches were employed.
The parsing stage today flattens 'some' transforms for some shapes.
Spheres and sphere sweeps come to mind. This kind of xfrm flattening I
believe was done to try and help performance(b). This flattening crashes
into the base v3.7/v3.8/v4.0 issue of pull request:
https://github.com/POVRay/povray/pull/358
Though, the discussion thread for that pull req goes on to look at
additional numerical issues; including fundamental limits at the end
related to loss of accuracy due the length of rays and polynomial
representations for the raysurface intersections.
We can work to reduce the exposure to numerical issues in ray tracing,
but we can never eliminate them. More so the case due needing to use
fast floating point hardware for good performance.
Bill P.
(a)  The span and locality of references for many 'object'
representations are effectively better with inverse transformations
where the working numerical space is more robust. It can be less robust
too. However, I think this less common in practice. In other words, it
doesn't matter if the inverse transform / resultretransform is
somewhat inaccurate for planet X, if all the local calculations on and
near planet X are more accurate. I'm lying much less here where planet X
exists in 'effective' isolation in the global numerical space of the
scene.
(b)  The issue pull 358 is trying to address is the unfortunate
introduction of a kind of min intersection depth filter in the "global"
numerical space in v3.7+ which results in the trimming or elimination of
shapes from raysurface intersection calculations. In povr  where this
issue fixed in a way different than the actual #358 pull req  I've got
sphere point cloud test cases which now run 3040% slower! Why? Well
povr isn't ignoring 3040% of the ray>sphere calculations. Makes me
wonder what portion of the performance gains from the parser
flattening/eliminating of transforms was foolsgold when measured.
Post a reply to this message

