William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/8/25 14:06, Bald Eagle wrote:
> >> (*) I tried inverting all the on curve points and this does NOT work as
> >> I incorrectly remembered for some recent sor{} post - that must be a
> >> lathe{} only thing.
> ...> Right, because sor is an implicit interpolation, and lathe is a
> parametric
> > interpolation.
>
> Unsure. With the lathe the reason to flip the point set order is to flip
> the normals (and perhaps too textures on parts of the resulting shape). Ref:
>
>
https://news.povray.org/povray.binaries.images/thread/%3C5745b756%241@news.povray.org%3E/

Yes, but this is not what I'm talking about.
I'm not trying to reverse the order of the entire point set, (which _ought_ to
be a valid point set for the sor - I think it's just "lazily" coded to check in
one direction - I think it could easily check for points going sequentially in
either direction)  I'm just trying to use ANY value for either the first or last
control point to change the tangent direction at the endpoints.

> I see no reason this couldn't be true for the sor too - even if all that
> happens internally is normalizing the decreasing point during parsing
> and setting a flag to flip the normals.

Yes, but even if we still just had the current sor monotonically increasing in
y, we could just switch texture and interior_texture to achieve the same result.
But I agree that given your point, sor could really use a much more in-depth
investigation and possible/probable recoding.

With regard to the abs() implementation, that was only to be applied to the r
result of the sor, so that anything that crossed the rotation axis would be a
valid control point.  I just didn't see why a mirror-image control point would
be invalid.

> That said. When I relaxed the parser's sanity checking so I could try
> and render the reversed point set I got no sor result. Given other
> discoveries this morning this might also be related to segments simply
> dropping out due how the internal cylinder bounding is being done.

I skimmed over the internal bounding part, but can try to devote some more time
to verifying what it does and how.

One thing that I noticed with going over the source code several different
objects is that we have a repetition of spline code - why don't we have all the
splines in one place and use them as the basis for all the various objects that
use them?

Simplifying things like that would make sure that the splines are consistent
between the various objects, and potentially open up the ability to use
user-defined spline interpolations for defining the outline of the objects.

- BW

Post a reply to this message