So, in the course of making some documentation renders, it became apparent that
there were a few things that were puzzling, needed to be sorted out, and some of
that was related to the behaviour of other keywords.

The following is a summary:

sor {} can have control points ON the axis, just not crossing it.
Else you get a "Parse Error: Incorrect point in surface of revolution"
I believe this is hard-coded behaviour in the source algorithm.
If I were to edit the source, it would allow the first and last control points
to cross the axis, since those points only exist to calculate the tangent
direction.

I do recall discussing this briefly in a thread with clipka and suggesting to
use abs {} somewhere in the algorithm, but I'd have to familiarize myself more
deeply with the specifics of what is going on numerically.

When using the sor {] object as the "cutter" in a difference {}, I unexpectedly
got some interior_texture {} showing in the result. Strangely enough, when i use
sor {open} the interior_texture {} is NOT visible, and I only see the surface
texture {}

When cutting away from the sor {}, I see the expected result, though I haven't
pursued this to see what more complicated geometry / CSG yields.

According to the sor {} tutorial in the wiki:
https://wiki.povray.org/content/Documentation:Tutorial_Section_3#Surface_of_Revolution_Object
"First and last point from the list are used to determine slope at beginning and
end of curve and can be defined for any height."

However, I find that to not be the case.
Swapping the first and last control points causes a
"Parse Error: Incorrect point in surface of revolution"
But if I only set the LAST control point y value to zero, technically making the
spline double-back in the y-direction, everything works fine.

and finally on to what sparked this whole investigation off:
I wanted to make a render comparing sor{} with sor {open}, but I had a devil of
a time slicing the vase in half and seeing the interior.

jr managed to achieve the desired result using clipped_by

As shown, when I use cutaway_textures, I DON'T see the expected
interior_texture, but the surface texture {}.  And when I use sor {open}, I do
not see a hollow infinitely thin surface, I get a solid object sliced in half.

So, I would say that there are problems with the sor {} caps, possibly with the
normal vector.

As shown in the bottom left, when I slice the sor {open} in half with a box, I
get an apparently solid object.  This is of course counterintuitive to what the
user expects, even though the documentation cautions that the open version might
yield unexpected results when used in CSG.  I would probably classify this
result as sufficiently unexpected as to warrant its classification as a bug, or
for an extended warning with the clipped_by solution to be added to the
documentation.

Futhermore, if the documentation implies that a sor is solid - just look at the
CSG results of difference {} - then clipped_by ought to give me what I'm seeing
as difference {} only with the interior_texture {} properly displayed.


Other things I notice are that there is some noisy "cruft" at the base of the
clipped_by object.  I also see some of that at the bottom of the difference{}s.

The texture is a tiling with a color_map, and is uv_mapped onto the surface(s).
As you can see on the right side of the object, the pattern does not line up
properly at the edges.  In the model below that, "top cp doubles back", I
changed the scaling of the tiling to an even number, and it now lines up.

I recall reading about properly scaling patterns so that make them fit, and that
of course employed the use of pi or tau to calculate the proper scaling.  This
might be a worthwhile keyword to implement for uv-mapping, perhaps some sort of
"scaling warp".  Likely to be pattern and direction dependent.

All objects are rendered with sturm.

Enjoy & Discuss.

- BE

Post a reply to this message

Attachments:
Download 'sor permutations.png' (130 KB)

Preview of image 'sor permutations.png'

Same renderings, but of sor {open}

Post a reply to this message

Attachments:
Download 'sor open permutations.png' (133 KB)

Preview of image 'sor open permutations.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:

> As shown, when I use cutaway_textures, I DON'T see the expected
> interior_texture, but the surface texture {}.  And when I use sor {open}, I do
> not see a hollow infinitely thin surface, I get a solid object sliced in half.

Also, I'm curious as to why the cutaway_textures feature requires the use of an
untextured object as a cutter to be able to function properly.
One would reasonably expect that we should be able to use any object.
If, as per wiki documentation, the cutaway_textures feature result is based on
insidedness tests, then the texture of the cutter should be irrelevant.

- BE

Post a reply to this message

On 9/7/25 12:10, Bald Eagle wrote:
> According to the sor {} tutorial in the wiki:
> https://wiki.povray.org/content/ 
> Documentation:Tutorial_Section_3#Surface_of_Revolution_Object
> "First and last point from the list are used to determine slope at beginning and
> end of curve and can be defined for any height."
> 
> However, I find that to not be the case.
> Swapping the first and last control points causes a
> "Parse Error: Incorrect point in surface of revolution"
> But if I only set the LAST control point y value to zero, technically making the
> spline double-back in the y-direction, everything works fine.

First, Are you using v3.8 beta 2 for all your testing?

Second, Did you take care when you did the differences with the box to 
not have coincident surfaces with the caps (if there) or that y height 
when the caps are not there?

As to the point above, I don't see what you see. The following list 
works for me where I have flipped / crossed the first and last control 
points(*). See the attached image where the first is magenta and the 
last is yellow.

     <+1.5,+1.1> // C0
     <+0.4,0.0>  // C1
     <+0.3,0.5>  // C2
     <+0.4,0.9>  // C3
     <+1.5,+0.1> // C4

I'll try and look at some of the other issues you mention as I have 
time; Including temporarily removing the x>0.0 restriction on the first 
and last points to see what happens. Aside: we did remove a similar 
restriction for the lathe for v3.8 vs v3.7.

(*) 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.

Bill P.

Post a reply to this message

Attachments:
Download 'be_sor01.png' (12 KB)

Preview of image 'be_sor01.png'

On 9/8/25 07:08, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> As shown, when I use cutaway_textures, I DON'T see the expected
>> interior_texture, but the surface texture {}.  And when I use sor {open}, I do
>> not see a hollow infinitely thin surface, I get a solid object sliced in half.
> 
> Also, I'm curious as to why the cutaway_textures feature requires the use of an
> untextured object as a cutter to be able to function properly.
> One would reasonably expect that we should be able to use any object.
> If, as per wiki documentation, the cutaway_textures feature result is based on
> insidedness tests, then the texture of the cutter should be irrelevant.
> 
> - BE
> 
> 
> 

Answering without thinking much, I don't think the cutaway_textures 
feature copies the inside texture(*), but maybe I'm not remembering 
correctly.

A reminder the yuqk fork fixed a cutaway_textures bug which exists in 
official POV-Ray releases. See:

https://news.povray.org/povray.bugreports/thread/%3C65806257%241%40news.povray.org%3E/

Bill P.


(*) - The inside_texture{}s feature has a few inconsistencies, besides, 
with respect to how texture{}s are handled.

Post a reply to this message

On 9/8/25 10:04, William F Pokorny wrote:
> Answering without thinking much,

Ah, and to quote Alain:

"When using cutaway_texture, the object used to cut away part of the 
rest must NOT have any texture."

Unsure your set up with respect to the particular post, but the overall 
images suggest both the box and sor might have textures ?

Bill P.

Post a reply to this message

On 9/8/25 09:52, William F Pokorny wrote:
> I'll try and look at some of the other issues you mention as I have 
> time; Including temporarily removing the x>0.0 restriction on the first 
> and last points to see what happens. Aside: we did remove a similar 
> restriction for the lathe for v3.8 vs v3.7.

Well, the current code drops portions of the curve that get pulled into 
x<0 territory by control points x<0. See attached image.

Might be fixable / map-able to x>=0 as you, I think, were suggesting 
with the abs() comment. It might even acceptable as a final result, IF, 
the inside tests, normal calculations and uv mapping code map in a sane 
way to the result.

Thinking aloud, it might be possible to allow x<0 control points - ONLY 
- where both on curve points and off curve control points are forced to 
be always ascending (>= previous) in y. This, probably, would cover the 
'useful' x<0 control point cases while preventing the curve from 
crossing into -x?  I'll try to play with this thought some more when I 
again have time - need to run.

Bill P.

Post a reply to this message

Attachments:
Download 'be_sor02.png' (5 KB)

Preview of image 'be_sor02.png'

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

> First, Are you using v3.8 beta 2 for all your testing?
Probably.  Will confirm when I get home.

> Second, Did you take care when you did the differences with the box to
> not have coincident surfaces with the caps (if there) or that y height
> when the caps are not there?

Yeah, I have an E value set that I routinely use to avoid CS.
I had the caps present when I skipped adding/subtracting that, and then when I
fixed it, the caps went away.


> (*) 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.

Thanks for checking on these.  Will compare notes when I get back later.

- BW

Post a reply to this message

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

> Ah, and to quote Alain:
>
> "When using cutaway_texture, the object used to cut away part of the
> rest must NOT have any texture."
>
> Unsure your set up with respect to the particular post, but the overall
> images suggest both the box and sor might have textures ?

I initially did leave the textures attached to the objects when first doing the
differences, but my code is such that it was easy to leave them textureless for
use with cutaway_textures, so no, that doesn't appear to be the problem.

Will post the scene file when I get out of here in an hour.

With regard to c_t not using interior_texture, that seems to be a reasonably
expected behaviour, and one which I'd have to think hard about how to code a
workaround for.

I also had that recent scene where I was getting washed-out colors, and I really
don't believe that I have any overlapping objects, however I will have to make a
detailed check to be absolutely sure.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

using
3.8.0-beta.2+gh7.msvc14.win64


scene file attached

Post a reply to this message

Attachments:
Download 'sor permutations.pov.txt' (6 KB)