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'