On 9/3/25 07:10, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Why 'solid'?
> 
> Because that's the default case....> 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.

I'm not opposed to better descriptions or feature names. That said, I 
don't see "solid of revolution" as better terminology. It might be just 
me though :-).

Many shapes have caps, or not, while still having defined inside(0) 
regions. The cone, cylinder, prism, etc, have caps or not.

The lathe does not include caps - and doesn't automatically close loops. 
Perhaps you are remembering prism{}s / polygon{}s which have code to 
close spline loops (linear_spline only?).

(0) - Less caps, these shapes are all 'tricky' to use with features 
where clean ray->surface pairs / ray-intervals are expected - CSG included.

> 
>> 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)

I believe it relates to the sor not allowing folds in y. The defining 
points for the sor must be ever increasing or decreasing in y. Beyond 
that (which you probably knew), you've done far more work than I have in 
trying to 'really' understand the particulars of the sor & lathe 
polynomial set up code / method(s).

> 
>>
>> 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.

With 2,3 and the sturm 'aside', I was - poorly - trying to point out the 
broad, sweeping statements about sor vs lathe performance, sturm vs not 
accuracy and performance mentioned in our documentation - and often in 
our forums - are iffy at best and sometimes outright wrong(a).

I included the sor vs lathe image to show I was using 'open' with the 
sor. The lathe doesn't do caps - and the performance numbers would be 
'unfair' to the sor otherwise. I noted too the lathe in the performance 
comparison was using cubic_spline (order 6).

(a) - In yuqk, where many solver issues are fixed / refined and 'sturm' 
more reliably invokes the sturmian solver, or not, there is seldom any 
difference in accuracy between the dedicated <=4 order solvers and the 
sturmian solver. While 'sturm' is usually slower, it's often by not that 
much. Its also true for lower (<=4) order equations 'sturm' is, 
occasionally, faster than the fixed solvers! It depends on stuff.

>> 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)

Indeed, multiple code bases are hard to keep straight. :-(

I get tangled up all the time trying to remember differences - v3.7, 
v3.8 (at where yuqk forked), v3.8 as backed up to something different 
for our two beta releases - and the great many yuqk fork specific 
changes / fixes relative to all the official, v3.7 / v3/8, POV-Ray code 
releases.

Bill P.

Post a reply to this message

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


> >> 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)


I tried to reach to LeFogeron, but failed. If anyone could... please attract his
attention to this discussion, trying to get him involved, so that more of the
povers who are really advanced in this area can actually also shed their light
on this topic!

Post a reply to this message

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

> I'm not opposed to better descriptions or feature names. That said, I
> don't see "solid of revolution" as better terminology. It might be just
> me though :-).

Because it looks and acts solid without any special treatment.
Regardless of caps or inside regions, if I can't see through the inside, and I
can use it in CSG, then it's solid.

If I apply the open keyword, then I can (depending on the specific location of
control points) see through it, not properly use it in CSG, and it's an
infinitely thin shell.

This is fun.  You play clipka, and I'll play Warp.  ;D

> Many shapes have caps, or not, while still having defined inside(0)
> regions. The cone, cylinder, prism, etc, have caps or not.
>
> The lathe does not include caps - and doesn't automatically close loops.
> Perhaps you are remembering prism{}s / polygon{}s which have code to
> close spline loops (linear_spline only?).

While I was very briefly making a lathe shape to contrast it with sor, I made a
square U shape, where I only supplied 8 points, not repeating the starting
point.   I didn't use an interior_texture, so I'll to try that when I get the
chance.


> I believe it relates to the sor not allowing folds in y. The defining
> points for the sor must be ever increasing or decreasing in y.

However, the documentation points out that you can use ANY point for the
"oof-spline" control points to set the tangent directions.  Haven't tried it
yet.

> With 2,3 and the sturm 'aside', I was - poorly - trying to point out the
> broad, sweeping statements about sor vs lathe performance, sturm vs not
> accuracy and performance mentioned in our documentation - and often in
> our forums - are iffy at best and sometimes outright wrong(a).

I'd probably have to try that with a much longer spline to really see.

> (a) - In yuqk, where many solver issues are fixed / refined and 'sturm'
> more reliably invokes the sturmian solver, or not, there is seldom any
> difference in accuracy between the dedicated <=4 order solvers and the
> sturmian solver. While 'sturm' is usually slower, it's often by not that
> much. Its also true for lower (<=4) order equations 'sturm' is,
> occasionally, faster than the fixed solvers! It depends on stuff.

Yes, it can get complicated, and I find myself looking into all of this solver
stuff myself, and reading about how others handle some of the quartic and higher
equations.  So far I've only written my own simple Newton-Raphson solver, and
copy-pasted the matrix multiplicative inverse method from source into SDL
(because why rewrite it...)


Thanks for chiming in - there's always more to be learned.
I wish I hadn't been so busy with graduate school in "the golden days" of
POV-Ray.  I also wish I had kept up with my programming skills.  I always feel
like I'm so very late in the game to be trying to make meaningful contributions.

- BW

Post a reply to this message