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

On 9/2/25 20:09, Bald Eagle wrote:
> 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?

Why 'solid'?

Unsure what better name(s) might be, but both the sor and lathe objects 
are rotations of one or more 2d curve segments around the y axis. The 
sor object is 'solid' (has a well defined inside) only in the default 
case (less the 'open' keyword); The lathe only when the 2d curve(s) are 
carefully closed.

The 'Surface Of Revolution' terminology is, I think, the more common - 
for both objects. For me, 'lathe' implies solidness when we can create, 
for example, open shapes, torus shapes or many 2d profiles wrapped 
around the y axis at the same time.

Other random thoughts:

1) Both objects (mostly) end up as uni-variate polynomials (power series 
form) as fed to the solvers.

2) The polynomial order the solvers see with the lathe depends on the 
type of spline used.

3) For the attached image the sor is on the left and the lathe on the 
right. I'm using yuqk, so the solvers are changed from POV-Ray proper.

     5
     <+1.5,-0.1>
     <+0.4,0.0>
     <+0.3,0.5>
     <+0.4,0.9>
     <+1.5,1.1>

sor
---
21.43user 0.03system 0:06.11elapsed
25.28user 0.02system 0:07.06elapsed  (sturm)

lathe  (cubic_spline)
-----
26.33user 0.02system 0:07.27elapsed
26.30user 0.02system 0:07.31elapsed  (sturm)

Aside: What 'sturm' actually does (or not) with any given shape where 
the keyword is supported is very muddy in the code / documentation - a 
little less so with the yuqk fork. For example, the sturmian solver is 
always used where the polynomial order is >4 no matter the use of 
'sturm'. In official POV-Ray 'sturm' often doesn't control the inside 
test code when solving for polynomial's for roots, where in yuqk it more 
often (aways?) does. Further, in yuqk where 'sturm' is specified with 
lower order polynomials (order <= 4), the sturmian solver is used, where 
in official POV-Ray it often is not. In the official code base, there is 
too order reduction code (removed in yuqk) which routes equations to 
particular solver methods no matter the 'sturm' setting.

--------------

As for parametrics, agree with much of what you suggest, but thinking 
maybe a stand alone program cleaner / better. For example, just 
trundling through u,v coordinates forces very tiny steps (large numbers 
of triangles) universally where shapes / surfaces have sharp-ish edges / 
small features one wants maintained in the rendered result. Better would 
be optimizations of the initial mesh to reduce the size while 
maintaining 'sharp' / 'small' features - this sort of optimization 
should probably be done outside of SDL parsing. In any case we should 
look again at what was done for this feature in hgpovray38.

Other ideas logged. :-)

Bill P.

Post a reply to this message

Attachments:
Download 'sor_vs_lathe.png' (27 KB)

Preview of image 'sor_vs_lathe.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:

> What do you all think?  Discuss.

Yes.

But, for all objects. It means we'd need a whole mesh library (openMesh etc.?)
to build on.

quite a bit of "all" objects can be represented as parametric.
sphere(
  0, 1
  resolution = <60, 30>
)
resolution triggers the system to create the parametric sphere, instead of the
solid.

tracing parametrics "always" requires some form of iteration like Newton-Raphson
/ iterative root-finding, subdivision / bounding volume hierarchy, Bezier
clipping etc.

One can use a "coarse" mesh as starting point and then do subdivision to
subpixel level, using the parametric eq set.

A side effect that I would welcome, if we can generate internal mesh of objects,
global meshify setting, we can do openGL pre-views.

An other side effect, subdivision modelling, though purely by script it's not
fun.

If I could write POVRAY5, i'd look into language and parsers in such a way that
it can spit out multiple things to serve multiple rendering back ends.

ingo

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Why 'solid'?

Because that's the default case.
It's only not solid when you do the additional work to "hollow it out" with the
open keyword.
Let's say what we mean and mean what we say, rather than misleading the reader /
new user.

Calling it something slightly different but more accurate in the documentation
is (in my mind) better / more correct / proper, and leads to a better flow of
the documentation text when we get to invoking the keyword.
It also doesn't change the acronym sor {}.

I haven't rigorously experimented with the lathe object yet, but I've rendered a
non-closed curve, and it was solid / automatically closed.

> The 'Surface Of Revolution' terminology is, I think, the more common -
> for both objects.

I don't know what's "more common" but I'm less interested in what other people
do than the actual results of what our code does and how we describe it.
It's not (only) an infinitely thin surface - you can use it in CSG.  So why are
we calling it one?

> For me, 'lathe' implies solidness when we can create,
> for example, open shapes, torus shapes or many 2d profiles wrapped
> around the y axis at the same time.

I was renaming sor, not lathe.  I haven't gotten to scrutinizing the lathe yet,
so we'll see what I can learn / break with that one.

> Other random thoughts:
>
> 1) Both objects (mostly) end up as uni-variate polynomials (power series
> form) as fed to the solvers.

Seems right - I'm just doing this in 15-20 minute spurts, as the opportunities
arise.

> 2) The polynomial order the solvers see with the lathe depends on the
> type of spline used.

Well, yes. ("obviously") But the issue that I was trying to clarify was why the
lathe always has to solve a polynomial that is twice the _degree_ of the spline
segment being handled. (whereas the sor is happy to stick with the actual degree
of the spline)

>
> 3) For the attached image the sor is on the left and the lathe on the
> right. I'm using yuqk, so the solvers are changed from POV-Ray proper.
>
>      5
>      <+1.5,-0.1>
>      <+0.4,0.0>
>      <+0.3,0.5>
>      <+0.4,0.9>
>      <+1.5,1.1>

Please do not mislead - you're clearly using a non-specified type of spline, and
the open keyword.


> Aside: What 'sturm' actually does (or not) with any given shape where
> the keyword is supported is very muddy in the code / documentation - a
> little less so with the yuqk fork. For example, the sturmian solver is
> always used where the polynomial order is >4 no matter the use of
> 'sturm'. In official POV-Ray 'sturm' often doesn't control the inside
> test code when solving for polynomial's for roots, where in yuqk it more
> often (aways?) does. Further, in yuqk where 'sturm' is specified with
> lower order polynomials (order <= 4), the sturmian solver is used, where
> in official POV-Ray it often is not. In the official code base, there is
> too order reduction code (removed in yuqk) which routes equations to
> particular solver methods no matter the 'sturm' setting.

I have followed some of that code, and see all of that in there.
I recall posting something about the sturmian root solver in the past - couldn't
find it the last time I searched.


> As for parametrics, agree with much of what you suggest, but thinking
> maybe a stand alone program cleaner / better.

It may be, however I have a strong distaste for separable items, as well as
feeling that POV-Ray should have all of its own things as a starting point.

For example, just
> trundling through u,v coordinates forces very tiny steps (large numbers
> of triangles) universally where shapes / surfaces have sharp-ish edges /
> small features one wants maintained in the rendered result. Better would
> be optimizations of the initial mesh to reduce the size while
> maintaining 'sharp' / 'small' features

Yes, I've read some about doing just that.  I feel I'll be prepared to
understand further reading on that subject due to my work on surface curvature.

> - this sort of optimization
> should probably be done outside of SDL parsing.

It might _best_ be done that way, but I think not exclusively.
Let the user set an accuracy variable like in other shapes.

> In any case we should
> look again at what was done for this feature in hgpovray38.

Yes, always an excellent idea.  I can only unravel one code base at a time
(usually :D)

Ingo:

> A side effect that I would welcome, if we can generate internal mesh of objects,
> global meshify setting, we can do openGL pre-views.

Oh, yeah.  I hadn't thought about that!

> An other side effect, subdivision modelling, though purely by script it's not
fun.

I have dabbled with that in the past - and wasn't there a whole POV-Ray version
that had that sort of code in it?   May be time to revisit.

> If I could write POVRAY5, i'd look into language and parsers in such a way that
> it can spit out multiple things to serve multiple rendering back ends.

That would be nice - though unsure if we could handle _everything_ that way.
But keep talking - I'm listening.  :)



-BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> That would be nice - though unsure if we could handle _everything_ that way.
> But keep talking - I'm listening.  :)
>
>

"everything", wrt mesh depending on the object, either Parametric or Marching
"Cubes" / Dual Contouring. Prism, SOR, Lathe, all mesh extrusion/rotation of
some kind (is kind of parametric). The odd one out may be the sphere sweep
depending on the kind of result one wants.

Text I've never looked in to, maybe lofting a mesh, kind of parametric. ('t
would be nice to have the path of a glyph available in SDL for
interpolation/spline)

Lofting may be a mesh thing that has no equivalent in the "solid" world.

Subdivision modelling. Iirc John VanSickle wrote a macro for it. I don't
remember a POV-Ray patch that was able to do it, may have missed it.

An other thing that comes with mesh is displacement mapping (combined with
subdivision or parametric) as is currently possible through the macro route an
using an image as a function.

For CSG there are mesh libraries.

"everything" wrt backend. When there would be a meshify option for objects, 3D
printing etc. would be easier. It would require testing for closed mesh' and
probably a few more things.

I've been dabbling with Half Edge Mesh data structures in Nim. Once you have one
it is relative easy to convert it to any mesh format. They are also useful for
operations on mesh.

Almost all of this is available in libraries, https://www.cgal.org/ for example.

ingo

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Aside: What 'sturm' actually does (or not) with any given shape where
> the keyword is supported is very muddy in the code / documentation

What _anything_ actually does is often very muddy in the code / documentation.

It shouldn't take me a week to unravel something like sor because there's a
complete absence of any explanatory / guiding comments.

Some people have this attitude that "Well, it just _expected_ that if you're
using a computer graphics package, that you'd at least know about XYZPDQ...."
But I'd say that from a developer's perspective, the comments ought to be in
there just as part of good coding practice, and not every c++ coder is going to
be a graphics expert or experienced mathematician.  I'm perpetually mystified as
to why someone would be expected to "just figure it out", when someone already
had it all figured out when they wrote the source code.

I would say that if POV-Ray still actually has an active user base, and we want
to actually make the push forward to 4.0 or 5.0 or whatever --- then folks
should take a peek into the code for their favorite object, one that they
understand the CG theory of, or one that they've always been curious about how
it worked - and make some notes about what the source code does and how.

Because even just having a patch version that consists of nothing more than
user-added commentary and theoretical references for all of the various
algorithms would be a big step forward for us, and a giant help to anyone we
might find willing to be a developer.

The comments don't even necessarily have to be IN "the code" - we could just
have a .h, a .cpp, and then an additional .doc or some other extension (.prd Pov
Ray Documentation) text file where everything can get hashed out and unfinished
work can be left as empty outline sections for others to continue work on.

If we had all of that available as an additional "developer documentation"
section of the distribution, then 1. our code would be far more well documented
than it currently is, 2. anyone debugging or adding to the code would be way
ahead of the curve rather than way behind, and 3. all of that theory and
under-the-hood operational stuff would be readily available as a resource to
point to when people on the forum ask the usual questions.

- BE

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> The odd one out may be the sphere sweep
> depending on the kind of result one wants.

I'm guessing that we might be able to use what was learned in the whole tubular
function thread to rewrite the sphere sweep object code in triangle mesh form.

(Just because it would be cool, I'd like to see that hexagonal surface
tesselation used to cover surfaces, because the triangle mesh is just a subset
of that method)

> Text I've never looked in to, maybe lofting a mesh, kind of parametric. ('t
> would be nice to have the path of a glyph available in SDL for
> interpolation/spline)

Cousin Ricky and I have both manually converted text to splines.
Clipka was talking about converting all of the text to prisms.

> Lofting may be a mesh thing that has no equivalent in the "solid" world.

I had been interested in creating lofting some time back, but never had the
opportunity to bite into that. (yet...  ;) )

> Subdivision modelling. Iirc John VanSickle wrote a macro for it. I don't
> remember a POV-Ray patch that was able to do it, may have missed it.

http://news.povray.org/povray.news-submissions/message/%3C40a14e8c%40news.povray.org%3E/#%3C40a14e8c%40news.povray.org%
3E

https://news.povray.org/povray.advanced-users/thread/%3C53de2167%40news.povray.org%3E/

https://news.povray.org/povray.unofficial.patches/message/%3C40aeaf37%40news.povray.org%3E/#%3C40aeaf37%40news.povray.o
rg%3E


> For CSG there are mesh libraries.

Ah, libraries . . . and licenses.  :/

> I've been dabbling with Half Edge Mesh data structures in Nim. Once you have one
> it is relative easy to convert it to any mesh format. They are also useful for
> operations on mesh.

Very interested.
I've been wanting to do a user-controlled Voronoi pattern / object, and one of
the algorithms involves using a half-edge data structure.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:

> Ah, libraries . . . and licenses.  :/

Politics and silo's :(

lofting in SDL:
https://news.povray.org/povray.binaries.utilities/thread/%3CXns94D4AF6BE46A0seed7%40news.povray.org%3E/?ttop=445117&tof
f=150


half edge mesh for for voronoi is a good one. In 2d each cell is a polygon, in
3d a mesh of polygons. Multiple connected cells may need some special design in
3d as most versions don't like manifolds, more than two faces connected to an
edge, so less than halve an edge. Can get messy. Wait, there's space between the
cells, are they ever touching/connected? If not it's just a "bag of cells" and
half edge works fine. I'll try it a bit ... mmm ... if jr. allows as he gave me
a job I still haven't finished.

Prisms/extrusions for text, yes of course.

Speresweeps can be lofts. Blob-sweeps are isosurfaces, marching thingies.

So it boils down to two well implemented algorithms to cover all shapes in mesh
form.

thanks for the links, I'll have a look,

ingo

Post a reply to this message

regarding Voronoi:

Voronoi cells are connected.

This means one gets manifolds and the half edge mesh system chokes on that.

Voro++ uses the bag of cells approach. But there is no further relation between
the cells. That's a pity. While constructing the voronoi pattern we gather data
about neigbours. These can be put in a record/struct together with the vertex
and face data of the cell. This makes it possible to traverse through the voroni
cells. The halfe edge datastructure can still be used for the single cell mesh.
Simplified:

VornoiCell = object
  geometry: ConvexPolyhedron  // halfedgemesh or just array of vertices & faces
  seedPoint: Vec3
  neighbors: seq[CellID]     // adjacent cells
  sharedFaces: Table[CellID, FaceID]  // which face is shared with which
neighbour

VoronoiBag = objec
  cells: Table[CellID, VoronoiCell] // if cellId is ordered, seq[VoroinoCell]


Then I thought, what if we transpose the (half) edge to a higher dimension.
That/what would be a half face/facet mesh datastructure. Very implified:

type
  HalfFace = object
    face: Face                   // geometric face (vertices, normal, etc.)
    adjacentCell: CellID         // which cell this half-face belongs to
    twinHalfFace: HalfFaceID     // opposite half-face in neighboring cell
    nextAroundCell: HalfFaceID   // next face around this cell

  VoronoiMesh = object
    halfFaces: List<HalfFace>
    cells: List<Cell>            // each cell references its half-faces


pattern :
1D: vertices bind line segments
2D: edges bind faces
3D: faces bind volumes/cells
4D: volumes would bind 4D regions

Half-edge works for 2D as edges are the boundaries between faces
Half-face makes sense for 3D as faces are the boundaries between cells
Half-volume would work for 4D as volumes are the boundaries between 4D cells?

for n-dimensional mesh elements (n-1)-faces separate n-dimensional regions?


After some searching it is actually something that exists to create 3d connected
mesh' : OpenVolumeMesh
https://www.graphics.rwth-aachen.de/software/openvolumemesh/

The choice depends on the goal,

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> Speresweeps can be lofts. Blob-sweeps are isosurfaces, marching thingies.

37 page paper to ... concatenate spheres and cylinders/cones.
Just like I've (re)written hundreds of times every time I want to graph
something.

But - what's that? They calculate the tangents between the spheres to smoothly
connect them?

And the manuscript was written in ... 2019?

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5da27a2a65c96eb4eec112d0%40news.povray.org%3E/?ttop=445868
&toff=650&mtop=428668

https://news.povray.org/povray.text.scene-files/thread/%3Cweb.5dd1666f8983c4eb4eec112d0%40news.povray.org%3E/?ttop=4458
70&toff=50&mtop=429362

Must just be wild coincidence.
Just like that curvature of splines YT video.

But I do think that we can rewrite the spheresweep with some better code - both
analytically as well as tesselation.

- BW

Post a reply to this message