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'