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