Howdy folks,

For those of you playing along at home, I have recently gotten involved in
digging through the source code for sor {}, and therefore lathe {}, and by
extension, parametric {}.

With regard to the documentation for sor {}, I felt it prudent to make a push
for slightly altering how the shape is referred to.  I propose that SOLID of
revolution is the proper expansion of "sor".
https://wiki.povray.org/content/Reference:Surface_of_Revolution

What do you all think?  Discuss.

The fundamental difference between the sor and the lathe is that the sor is an
implicit equation, and therefore we can solve for intersection with a ray using
only equations of degree 3.   The lathe on the other hand, is a parametric
equation, and so we cannot simply plug in some <x, y, z> coordinate and
determine if that point is on the surface.  So we need to use some matrix math
to solve a system of linear equations, and the Pythagorean theorem to determine
how far away from the surface any given point is - which means that a degree 3
equation squared is now a degree 6 equation.

And that's why lathe is both more flexible, and slower.  Because we need to use
numerical methods (an approximation algorithm) to solve a 6th degree polynomial.

Parametrics are trivial to _construct_ - we just plug in a <u, v> coordinate,
and out pops an <x, y, z> point on space.  But they are very difficult to
raytrace.  We need to do the exact opposite of that.  When we project a ray from
the camera through a screen pixel out into POV-space, we need to determine if we
intersect the parametric.  Good luck.
Doing this tends to involve, long, drawn out subdivision schemes that take a lot
of time.  Which is why the parametric {} object is so notoriously SLOW.

However, we do have a set of macros that provides a very good workaround.  Use
the forward method of constructing a parametric to literally do that.  Step
through u and v, make a grid, and subdivide every quadrilateral into
triangle{}s.  Raytracing the triangles is then very fast, and (especially when
using smooth_triangle{}s) look indistinguishable from doing it the hard, slow
way.

I propose (as I have in the past) that we change the parametric {} to use a
triangle approximation, or create a new parametric2 object, just like we have
mesh and mesh2.
If that sounds like a lot of work - keep in mind that we already have just about
everything we need already - in the form of the bicubic_patch {} object.  It's a
parametric surface using control points, and gets converted into triangles in
source before rendering.

So we just copy/paste that code into a new object, rewrite it for a rotational
sweep, and it should be just as good as parametric {} but blindingly FAST in
comparison.  Which means that people will USE it, whereas almost nobody uses the
original parametric {} at all.

I'd also suggest that future work involve adding more spline types, or creating
some mechanism whereby the can be user_defined spline types.

We could also use some additional parametric surfaces in addition to the Bezier
surface (bicubic_patch), and different ways of sweeping splines.
(I need to test an idea using a "1D" spline in a conical sweep to make a
triangular surface that follows a spline.) but extensions of that would make
modeling certain specific surfaces that much easier.

- BE

Post a reply to this message