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'