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