On 9/21/25 13:44, jr wrote:
> v confusing.  intervals (media) is a numeric value, your sor{} ones are string
> values.  how do those 5-char strings relate to the 8-element/point arrays ?

Documentation needs to be created. :-) A quick answer is that the number 
of spline-segments for the sor{} is always 3 less than the number of 
points specified. The length of the boolean bit string for control over 
all spline-segments is therefore (8-3).

For the lathe, the bit string length will differ depending upon the 
spline type. The same would be true for the sphere_sweep should the 
'intervals' feature be implemented there.

> on topic "sor{}" - is it "hollow" or "solid" as suggested ?  (I have an email
> thread "stalled" on this question :-))
One of my all time favorite streaming series is a show called "Patriot" 
on Amazon's Prime Video service.

https://en.wikipedia.org/wiki/Patriot_(TV_series)

On seeing questions, I often hear Michael Dorman's character saying 
"It's never that simple."

Depends on stuff - and for the keyword 'hollow' there is a pile of stuff 
I know, I don't know. I've never done a deep dive on how the setting 
cascades throughout the code. There is some weirdness with how it works 
and, IIRC, Alain pointed out one of those in the last year or two for 
some situation where adding 'hollow' magically fixed things.

The keyword 'hollow' means something closer to "You can stick media in 
this object" - except where it doesn't.

For the concept of solid, it mostly means the shape has a defined inside 
test in POV-Ray. That inside test can be kinda, arbitrarily, there at 
times - as is  the case with disc{}s, for example. Further, solid(as 
defined inside), doesn't necessarily mean closed-solid or 
surface-bounded-volume, which is often the stricter requirement for 
features like media and interior fading to work correctly.

With respect to Bill W's suggestion that the sor acronym assignment 
/alignment be changed to "solid of revolution", it just hits me as 
wrong. Perhaps this only due what I was exposed to over time. To me, 
when someone says "solid of revolution", it is the 3D volume a 3D object 
(a more mechanical thingy) requires when fully rotated about one more 
axes(*).

(*) - It would be an interesting way to define shapes in POV-Ray, if we 
work out how to do it(**).

(**) - I've wondered occasionally about adding an f_reuleaux_prism() 
inbuilt function and/or shape. The rotation of the defining triangle's 
center around a circle produces a nice, beveled "solid of revolution."

Post a reply to this message

On 9/21/25 18:34, William F Pokorny wrote:
> when fully rotated about one more axes(*).

...when fully rotated about one OR more axes(*).

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/21/25 13:44, jr wrote:
> > v confusing. ...
> Documentation needs to be created. :-) A quick answer is that the number
> of spline-segments for the sor{} is always 3 less than the number of
> points specified. The length of the boolean bit string for control over
> all spline-segments is therefore (8-3).

thanks.  I'd better wait for the next yuqk release, I don't think I'm ready for
an answer to "three less ?" </grin>


> ...
> Depends on stuff - and for the keyword 'hollow' there is a pile of stuff
> I know, I don't know. I've never done a deep dive on how the setting
> cascades throughout the code. There is some weirdness with how it works
> and, IIRC, Alain pointed out one of those in the last year or two for
> some situation where adding 'hollow' magically fixed things.
> The keyword 'hollow' means something closer to "You can stick media in
> this object" - except where it doesn't.

I like the "can fill with" definition, feels "intuitive".


> ...
> With respect to Bill W's suggestion that the sor acronym assignment
> /alignment be changed to "solid of revolution", it just hits me as
> wrong.

sorry, still "no good".  I'd hoped for something along the lines "reading the
code at ...", that is for some "evidence-based" words.

and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
required "infrastructure" exist already (in part, at least) ?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> thanks.  I'd better wait for the next yuqk release, I don't think I'm ready for
> an answer to "three less ?" </grin>

https://wiki.povray.org/content/Reference:Surface_of_Revolution
"If there are n points we will have n-3 segments."


> I like the "can fill with" definition, feels "intuitive".

I hate it.   Because it is so very, very misleading.
Primarily because we can use SOLID objects as containers for media but still use
them in CSG.

So you're using language to describe something that can simultaneously have two
fundamentally different attributes.

There needs to be a checklist.
There also likely needs to be a reclassification of primitives.

Just going off the top of my head:
We have surfaces - and some may have an inside/outside whereas others may simply
have a normal vector/direction.
We have some objects that _can_ be closed (parametric) but might not be.  It
would great if the closed shape could be solid, but I'm not sure if there's a
way to always reliably determine if the parametric equations form a closed
shape.
As Jerome Grimbert quite properly pointed out when I was working on calculating
surface normals - the Mobius strip really throws a wrench into the works.

Then we have things that in my opinion ought to be fully solid, but for various
code limitations and unimplemented algorithms/features - aren't fully solid.
They're mostly solid.   This might be the case with sor {}
The point being, that we ought to have an explicit means of documenting in what
cases the object acts as a solid, and in what cases it doesn't (and why).
Because there's no reason the sor {} shouldn't be fully solid - since I can't at
the moment envision a case where the un-open sor would have to be hollow.

I think that the lathe - with the ability to intersect itself - might be tricky,
and should properly use the same crossing-number as the polygon to determine if
that section is inside or outside.

> > With respect to Bill W's suggestion that the sor acronym assignment
> > /alignment be changed to "solid of revolution", it just hits me as
> > wrong.
>
> sorry, still "no good".  I'd hoped for something along the lines "reading the
> code at ...", that is for some "evidence-based" words.

If it looks solid, and acts solid, then I would imagine that we could agree that
it was solid.  If we need to specify "open" to make it (non-keyword) hollow,
then what was it before we changed it to hollow?

> and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> required "infrastructure" exist already (in part, at least) ?

In a sense, yes.   The lathe sweeps a spline, or, if you consider the closed
spline a polygon - a 2D shape, then we already have that.   Anything that
projects outside of the 2D plane of the spline's control polygon is redundant
(it gets embedded inside the swept volume) and doesn't appear (assuming it's
smaller than the projected cross section).

If we're talking about "actually" revolving the whole solid object around an
axis and getting the swept volume as an object - I suppose one could project the
3D object onto a plane and get the maximal cross-sectional representation to
sweep (or just scale the object very small in one dimension), and it would have
flat start and end "caps".
If you wanted the 3D shape to define the ends of the swept volume, you could
instantiate the object at the start and end points to make the object bulge out
the ends.

Presumably we could write a simple macro to take that scaled object and
instantiate it around a circle using a loop in a union {}, and connect 2
instances of the 3D object.   Just like many people do with a union of spheres
and cylinders to make a substitute sphere-sweep.

There's likely a clever (and slightly painful) way to do it with an isosurface
and the object pattern.

Lots of interesting things to think about and experiment with.

- bw

Post a reply to this message

On 9/22/25 13:44, jr wrote:
>> ...
>> With respect to Bill W's suggestion that the sor acronym assignment
>> /alignment be changed to "solid of revolution", it just hits me as
>> wrong.
> sorry, still "no good".  I'd hoped for something along the lines "reading the
> code at ...", that is for some "evidence-based" words.

First, let me say I don't really know what you are after. :-) And, Bill 
W, I saw your recent post responding to jr's post.

We have in our documentation:

https://wiki.povray.org/content/Reference:Interior#Empty_and_Solid_Objects

which introduces a couple concepts. Those two concepts don't map 
directly to anything in the code - though users (including me) commonly 
use those terms(*).

In the code we do track patch objects / shapes in the base object class 
with a flags integer for which the bit used is PATCH_OBJECT. The 
PATCH_OBJECT bit being on, when initially constructed, essentially means 
the shape does not, start, with an inside test which can return true.

Patch class shapes are derived from a helper class called NonsolidObject 
which inherits from the base object class. That helper class currently 
sets an integer value that maps directly to the particular patch type. 
The additional information is never used that I see. Despite the class 
name it is way to track the patch type (TypeOfPatchObject would be a 
better class name I think, but, I lean toward it being deleted from the 
class hierarchy).

Strictly speaking, all we have inside the ray tracer are ray-surface 
intersections. We can link functionality to those surfaces - that's 
it(**). Bill W, I agree shapes can situationally, appear to be solid, 
but it's always conditional in POV-Ray(***).

---

We have disc{} and height_field{} which are arguably patch objects that 
are not because someone created inside test code that can return true. 
With the height_field that inside test can be adjusted using water_level.

We have mesh{} and mesh2{} which start as patch objects, but that status 
bit is cleared on seeing inside_vector.

We can effectively corrupt (or turn off) the inside test with many 
shapes by collapsing one dimension of the shape as with box { 
<-1,-1,0>,<1,1,0>}.

We can perform CSG with patch objects so long as another shape in the 
CSG has a inside test which returns true in a way that covers at least 
part of the patch object's surface. The result has no effective inside 
test where it is later used in CSG.

Where we have or 'intersect' / 'and' regions where inside tests are 
true, but the originating surfaces for the inside test are not in scope, 
nothing shows up unless we stick other surface(s) into that region.

---

Code wise nothing stops us from:

- Defining an inside test which can return true for existing patch 
objects where today the inside test always returns false.

- Implementing functionality which twiddles with the behavior of the 
inside test for effects / modified CSG results.

- Adding a shape option which forces an existing inside test sometimes 
returning true to always return false - 'inside off', perhaps.

(*) - Yes, there is too "Constructive Solid Geometry (CSG)." While 
'Solid' there might-have-been / may-still-be a decent choice, it is not 
completely accurate in the context of ray tracing.

(**) - Yeh, I'm lying a little. Media, for example, doesn't require any 
container, but it does require a terminating ray-surface intersection to 
be rendered. Fog is similar. Somewhere, for ray traced features, there 
is at least one effective surface. A feature might not be originally 
linked to a surface, but be work accomplished after the ray-surface 
intersection is determined - or faked (sky_sphere).

(***) - See attached image. Is the sphere solid in this situation? Code 
used:

...
#declare Sphere00 = sphere {
     0, 0.7
     texture { pigment { White } finish { ambient 0.02 } }
     interior_texture {
         pigment { rgb <1,0,1> }
         finish { ambient 0.02 }
     }
}
#declare Cyl00 = cylinder { 0.0, <1,1,-1>, 1 open }

difference {
     object { Sphere00 }
     object { Cyl00 }
     cutaway_textures
}
...

> 
> and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> required "infrastructure" exist already (in part, at least) ?

No. As Bill W suggested there might be some brute force ways to approach 
it. Where we have value field defined shapes, it should be we could come 
up with optimizations. Whether we could ever get to something which 
would work well enough for on the fly ray-surface intersections, I'm not 
sure.

Mechanical engineers surely have software which can determine the 
rotational volume required for 3D things - whether any methods are fast 
enough to run real time (without massive parallelism) I have doubts, but 
who knows. I've not dug.

Bill P.

Post a reply to this message

Attachments:
Download 'billw_solidnotsolid.png' (46 KB)

Preview of image 'billw_solidnotsolid.png'

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

> > sorry, still "no good".  I'd hoped for something along the lines "reading the
> > code at ...", that is for some "evidence-based" words.
>
> First, let me say I don't really know what you are after. :-) And, Bill
> W, I saw your recent post responding to jr's post.

I think he was under the impression that there was some definitive code fragment
that would unambiguously establish the solidness of a primitive.

> We have in our documentation:
>
> https://wiki.povray.org/content/Reference:Interior#Empty_and_Solid_Objects
>
> which introduces a couple concepts. Those two concepts don't map
> directly to anything in the code - though users (including me) commonly
> use those terms(*).

Nice.  With regard to sor:  "By default all objects are assumed to be solid."
:P

"You should be aware that solid objects are conceptual things. If you clip away
parts of the sphere you will clearly see that the interior is empty and it just
has a very thin surface.

This is not contrary to the concept of a solid object used in POV-Ray. It is
assumed that all space inside the sphere is covered by the sphere's interior."

So, I'd say that we either have:
misleading documentation - with regard to the terminology used and the
implication of words
Code that needs to be rewritten to better represent objects to meet user
expectations
buggy code

or just a whole pile of things that collectively are "POV-Ray" and need to be
better hashed-out and better organized to more accurately represent what's going
on.   That's just the nature of an open source project that has organically
grown over the past 30 years.

> In the code we do track patch objects / shapes in the base object class
> with a flags integer for which the bit used is PATCH_OBJECT. The
> PATCH_OBJECT bit being on, when initially constructed, essentially means
> the shape does not, start, with an inside test which can return true.
>
> Patch class shapes are derived from a helper class called NonsolidObject
> which inherits from the base object class. That helper class currently
> sets an integer value that maps directly to the particular patch type.
> The additional information is never used that I see. Despite the class
> name it is way to track the patch type (TypeOfPatchObject would be a
> better class name I think, but, I lean toward it being deleted from the
> class hierarchy).

As I get deeper into these things, it's very helpful to read this kind of
brass-tacks explanation.

> Strictly speaking, all we have inside the ray tracer are ray-surface
> intersections. We can link functionality to those surfaces - that's
> it(**).

Mmmmmm - I think we have at least a little more than that.
We can conduct insidedness tests without actually raytracing anything, and
probably a few more things that I can't bring to mind atm.

> Bill W, I agree shapes can situationally, appear to be solid,
> but it's always conditional in POV-Ray(***).

Yes, but I'm trying to not step into the trap of incomplete / poorly implemented
 code, or code that has bugs that haven't yet been rooted out.
I'd like to approach these things from "what ought to be the case" in some sort
of "this is what other mature, production raytracing/rendering packages do / are
capable of" with some form of formal Boolean logical result.

> We have disc{} and height_field{} which are arguably patch objects that
> are not because someone created inside test code that can return true.
> With the height_field that inside test can be adjusted using water_level.

Aye, but I make a distinction in those cases - because
1. we have a convention for things like planes and discs where one side is
"inside" and the other side is "outside".  It's not unexpected that how a plane
works got extended to a circular subset of a plane - a disc.
and
2. we can conceptually extend/project the edges of a heightfield onto a plane,
which provides the boundaries for making the object solid.   What was once
hollow is now solid, because the user invoked a special keyword.
Just like when a user takes a solid of revolution which is assumed to be solid,
and makes it hollow by invoking the open keyword.  {zing!} :D

> We have mesh{} and mesh2{} which start as patch objects, but that status
> bit is cleared on seeing inside_vector.

Which makes sense, because it's only a small conceptual jump between having an
inflatable Stanford Bunny, and a solid one.

> We can effectively corrupt (or turn off) the inside test with many
> shapes by collapsing one dimension of the shape as with box {
> <-1,-1,0>,<1,1,0>}.

Yes - and I'm sure that if we closely analyzed what we are doing in source, and
what the meaning of our return values from the c++ functions are, then we might
discover that there are better ways to conceptually represent what we are doing,
which would allow us to straighten a lot of these funny things out.
I have a feeling that that would be a lot like how we deal with things like
i=sqrt(-1), pow (0, 0), representing 4th dimensional objects, etc.

It might not have made much sense at one time, but math matured.
There may have been more limited examples that initially got developed, but like
splines, more general forms were worked out that allow a broader range of things
to be represented by a single more general form.

And I think I would like to see a more general form for a lot of our primitives.
   That doesn't exclude us having more nimble single-purpose primitives for
speed and efficiency, but I think we would be well served to try and
conceptualize all of our shapes so that they can all be described by similar
attributes, data structures, and raytracing algorithms.
We have a lot of redundant code in the code base.

> We can perform CSG with patch objects so long as another shape in the
> CSG has a inside test which returns true in a way that covers at least
> part of the patch object's surface. The result has no effective inside
> test where it is later used in CSG.

Hmmm.  That would be an interesting case to render as an example.

> Where we have or 'intersect' / 'and' regions where inside tests are
> true, but the originating surfaces for the inside test are not in scope,
> nothing shows up unless we stick other surface(s) into that region.

I'll have to a lot of thinking on that one to understand what you mean.

> Code wise nothing stops us from:
>
> - Defining an inside test which can return true for existing patch
> objects where today the inside test always returns false.

Probably.   It's just that no one ever got around to writing the inside ()
function for that primitive.

> - Implementing functionality which twiddles with the behavior of the
> inside test for effects / modified CSG results.

I'm sure that there's all sorts of interesting tricks one can play with that!
:)

> - Adding a shape option which forces an existing inside test sometimes
> returning true to always return false - 'inside off', perhaps.

I would say that now we're deep into the details of the primitives and the
consequences of how they are evaluated, then we should begin compiling a list of
better terminology.

Having said that, something like no_inside would probably fit better with
current SDL keyword forms.


> (***) - See attached image. Is the sphere solid in this situation? Code
> used:

And here I was still thinking that Tekno Franansia was the Evil Supergenius!
Master Pokorny is a tricksy little hobbit, yes, yes, very tricksy, my Precious.

> ...
> #declare Sphere00 = sphere {
>      0, 0.7
>      texture { pigment { White } finish { ambient 0.02 } }
>      interior_texture {
>          pigment { rgb <1,0,1> }
>          finish { ambient 0.02 }
>      }
> }
> #declare Cyl00 = cylinder { 0.0, <1,1,-1>, 1 open }
>
> difference {
>      object { Sphere00 }
>      object { Cyl00 }
>      cutaway_textures
> }

Now, I would have to say that in this instance it seems that this might just be
the result of buggy code, because we have not formally worked out what the
"proper" CSG result ought to be, and made our code consistent with that.

Still - a very clever and unexpected result!


> > and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
> > required "infrastructure" exist already (in part, at least) ?
>
> No. As Bill W suggested there might be some brute force ways to approach
> it. Where we have value field defined shapes, it should be we could come
> up with optimizations. Whether we could ever get to something which
> would work well enough for on the fly ray-surface intersections, I'm not
> sure.

I think we could - it would just a project of its own.
I have looked into signed distance functions of meshes, and people have worked
out how to do that, so it may very likely be possible.

> Mechanical engineers surely have software which can determine the
> rotational volume required for 3D things - whether any methods are fast
> enough to run real time (without massive parallelism) I have doubts, but
> who knows. I've not dug.

I would guess that those are either triangle-based (FEM) or some other similar
numerical method.

Once again I will briefly reiterate the need for some sort of editable to-do
list, program management software, or other means of logging ideas, references,
proofs of concept, partial or naive implementations in SDL, c++ or other
languages, etc.

Experiments that languish on my hard drive don't do the development of POV-Ray
any good.  Adding them to a collection of ideas, references, and functional code
would.

- BW

Post a reply to this message

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

> I have looked into signed distance functions of meshes, and people have worked
> out how to do that, so it may very likely be possible.
>

first you'd have to make sure the winding per triangle/polygon is consisten
cw/ccw.

then you can look at the "general winding number" to find wheter inside or
outside the mesh and to find whether the mesh is closed.

If winding number is 1, inside mesh, else if 0 outside mesh, else mesh not
closed
The winding number should be consisten for all polygons, else the mesh is not
closed.

This can then turned into a signed distance value / field (SDF): distance = + /
- distance] negative distance = inside.

triangle [v1, v2, v3]
p = test point
a = v1 - p
b = v2 - p
c = v3 - p
num = dot(a, cross(b, c)) (the scalar triple product)
den = |a||b||c| + dot(a,b)*|c| + dot(b,c)*|a| + dot(c,a)*|b|
omega_triangle = 2 * atan2(num, den )
omega_mesh = sum(omega_triangle)
generalised winding number = omega_mesh / 4*PI


if you're shure th mesh is closed you can fall back to trace and count
intersections to determine inside/outside.

Any one ever peeked at the code of OpenScad? They have this or similar
routinely,

ingo

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/22/25 13:44, jr wrote:
> >> ...
> > I'd hoped ... for some "evidence-based" words.
>
> First, let me say I don't really know what you are after. :-)

well, confidentially, that makes two of us.  </grin>


> And, Bill W, I saw your recent post responding to jr's post.

replied to below.


> which introduces a couple concepts. Those two concepts don't map
> directly to anything in the code - though users (including me) commonly
> use those terms(*).
>
> In the code we do track patch objects / shapes in the base object class
> with a flags integer for which the bit used is PATCH_OBJECT. The
> PATCH_OBJECT bit being on, when initially constructed, essentially means
> the shape does not, start, with an inside test which can return true.
>
> Patch class shapes are derived from a helper class called NonsolidObject
> which inherits from the base object class. That helper class currently
> sets an integer value that maps directly to the particular patch type.
> The additional information is never used that I see. Despite the class
> name it is way to track the patch type (TypeOfPatchObject would be a
> better class name I think, but, I lean toward it being deleted from the
> class hierarchy).
>
> Strictly speaking, all we have inside the ray tracer are ray-surface
> intersections. We can link functionality to those surfaces - that's
> it(**). Bill W, I agree shapes can situationally, appear to be solid,
> but it's always conditional in POV-Ray(***).

thank you, very much.  like BW I get much from your explanations; the 'aside's
often offer even "better value for money" :-).

> ...
> (***) - See attached image. Is the sphere solid in this situation? Code
> used:

what a teaser..  :-)

on the 'sor{}'.  I've decided to be "guided by" the 'open' keyword.  that is
accept that it can be described solid while "capped", but for documentation
purposes keep the current moniker; when that page gets updated (along with the
tutorial), we can add (maybe under "Finite Solid Primitives" ?) a sentence or
two on the "difficulties" finding defining words.


> > ... required "infrastructure" ...
> No. As Bill W suggested there might be some brute force ways to approach
> it. Where we have value field defined shapes, it should be we could come
> up with optimizations. Whether we could ever get to something which
> would work well enough for on the fly ray-surface intersections, I'm not
> sure.
> Mechanical engineers surely have software which can determine the
> rotational volume required for 3D things - whether any methods are fast
> enough to run real time (without massive parallelism) I have doubts, but
> who knows. I've not dug.

"on the fly" ?  </grin>  thanks though, I now think that, while we wait for a
new POV-Ray development and or the heat death of the universe, a macro will have
to do to simulate the "sweeping".



@Bald Eagle

> So you're using language to describe something that can simultaneously have two
fundamentally different attributes.

agree, the (English) language gets in the way.  we'll (need to) add a
"clarifying" paragraph.


> If it looks solid, and acts solid, then I would imagine that we could agree that
> it was solid.  If we need to specify "open" to make it (non-keyword) hollow,
> then what was it before we changed it to hollow?

"solid" argument :-).  see above.


> "If there are n points we will have n-3 segments."

_hiding_ in all that "formula stuff", thanks for the reference.


regards ,jr.

Post a reply to this message

"ingo" <nomail@nomail> wrote:

Very nice and concise explanation.  :)

> Any one ever peeked at the code of OpenScad? They have this or similar
> routinely,

I may have - ages ago.
If you USE OpenScad, you'll notice, IIRC, that you have to provide a sort of
step value for these things, which makes me think they just have a brute-force
iteration thing going on.

OpenScad is SO similar to POV-Ray that I often wonder if it's a forked
development project.  "POV-Ray for 3D printing"

Post a reply to this message

So I was trying to model an elegantly curved shape as a sor {}, and I noticed
that it was turning out pretty clunky.

And so one thing that I would recommend be added to the documentation is the
fact that a big difference between the sor {} and the lathe {} is the type of
splines used.

Catmull-Rom is an interpolation spline, and so probably needs a large number of
very exact control points to accurately mimic a smooth curve.

Whereas the cubic polynomial splines in the lathe are approximation splines,
which give a much smoother, "organic" curve.

The challenge there, is that the spline only passes through the endpoints of a
spline segment, and so accurately modeling any given curve is more challenging,
because one has to guess or do a lot of calculations to determine the proper
positioning of the inner control points.

Also, if one wants to model a glass, vase, bottle, or some other hollow shape
that has a given wall thickness, then that's something that can be done directly
with the lathe, rather than having to use CSG to subtract away the inside of the
"solid" sor.

- BW

Post a reply to this message