I've been digging down to the foundations of computing normals, and I was
re-reading the following threads with fresh eyes.

https://news.povray.org/povray.binaries.images/thread/%3C609265e2%40news.povray.org%3E/?mtop=434022

http://news.povray.org/povray.binaries.images/thread/%3C5ff4b8da%241%40news.povray.org%3E/

https://iquilezles.org/articles/normalsSDF/
(Original pouet.net link: https://www.pouet.net/topic.php?which=5604 )

This thread recently got updated due to my inquiries, with no explanations, thus
the pyramid vectors straight from POV-Ray's normals.cpp

https://rodolphe-vaillant.fr/entry/87/normal-to-an-implicit-surface

I was also trying to re-code an old scene where I was initially trying to
replicate source-code methods in SDL, and I believe I was trying to do what
Cousin Ricky was doing - which is trying to use a scalar value to create a
"normal".

A surface normal is, by definition, a vector perpendicular to the surface at
that point.   It's a vector, not a scalar, so using the scalar result from an
SDL function as a normal really doesn't make any sense.

I believe one would need to use a spline function, a pigment function, or some
other vector-valued function to properly use a function {} in a normal statement
to get meaningful if not proper results.

Perhaps what Richard is seeing is the result of vector promotion or some other
under-the-hood modification of the scalar function, and that' why the raytraced
result is wrong.

I myself am currently trying to unravel the requirements and limitations of
trying to create normals in sdf using the pyramid vector method.

All I can say is that there is no inherent bias introduced by the pyramid vector
method, since everything cancels out to give straightforward central differences
in any orientation.

- BE

Post a reply to this message