In the last week plus I've implemented what I think is likely better 
bounded_by{} and clipped_by{} implementations when manually bounding / 
clipping.

It's been the case, since at least v3.7, that both bounded_by{} and 
clipped_by{} accept multiple shapes / objects. For example, we can code:

     #declare Iso00 = isosurface {...}
     #declare Obj00 = object {
         Iso00
         bounded_by { sphere { <+0.3,+0.0,+0.0>, 0.25 }
                      sphere { <-0.3,+0.0,+0.0>, 0.25 }
                      sphere { <+0.0,+0.3,+0.0>, 0.25 }
                      sphere { <+0.0,-0.3,+0.0>, 0.25 }
                      sphere { <+0.0,+0.0,+0.3>, 0.25 }
                      sphere { <+0.0,+0.0,-0.3>, 0.25 }
         }
     }

// ----------- or

     #declare Iso00 = isosurface {...}
     #declare Obj00 = object {
         Iso00
         bounded_by { sphere { <+0.3,+0.0,+0.0>, 0.25 } }
         bounded_by { sphere { <-0.3,+0.0,+0.0>, 0.25 } }
         bounded_by { sphere { <+0.0,+0.3,+0.0>, 0.25 } }
         bounded_by { sphere { <+0.0,-0.3,+0.0>, 0.25 } }
         bounded_by { sphere { <+0.0,+0.0,+0.3>, 0.25 } }
         bounded_by { sphere { <+0.0,+0.0,-0.3>, 0.25 } }
         // Multiple bounded_by{} blocks parse more slowly than above.
     }

I don't believe there is any documentation for this functionality and I 
don't recall any, intentional, use of multiple shapes in code I've seen. 
A reason is likely that today multiple shape implementations effectively 
do an intersection of inside regions and that limits the usefulness - as 
do other bounding issues in v3.7/v3.8 fixed in the yuqk fork.

What I'm doing for the next release of yuqk (R20) is adding an optional 
'mode' keyword to both bounded_by{} and clipped_by{} which must appear 
before the first shape / object.

For bounded_by{} the modes are:

     0 : intersection. (Traditional behavior)
         ray hits or inside all shapes (POV-Ray v3.7+ default)

     1 : union / any.
         ray hits or inside at least one of the shapes

For clipped_by{} the modes are:

     0 : intersection. (Traditional behavior)
         ray->surface intersection inside all shapes
         (POV-Ray v3.7+ default)

     1 : intersection inverse.
         ray->surface intersection outside (0)

     2 : any.
         ray->surface intersection inside at least one shape

     3 : any inverse.
         ray->surface intersection outside all shapes

The thought with 'mode 1' of bounded_by{} is that by using multiple 
shapes we can sometimes more accurately bound expensive shapes 
(isosurface{}s, parameteric{}s, sphere_sweep{}s, etc.) with multiple 
simple / fast shapes. In play using multiple sphere{}s to manually bound 
cone{}s/cylinder{}s, this idea works(*), but always at a loss in 
performance (10-25%) when the target shapes/objects are completely bounded.

(*) - The target shape's solvers run much less and the sphere's code 
more, but it looks like where the target is simple, (or the shape itself 
has good internal bounding), multiple bounding is likely not a 
performance win for the entire shape.

Attaching a couple images and the scene used to generate them. In both 
images, starting in the upper left and moving clockwise are: union{}, 
merge{}, intersection{} and difference{} results from the two 
bounded_by{} and clipped_by{} spheres. One showing results with 
coincident surfaces and the second where one result is expanded slightly 
to eliminate the coincident result.

I find all the results interesting and potentially useful, but we'll 
see. I'm new too, to what we might be able to do with the extended features.

Bill P.


Aside:
------
In working on these updates I've run across more checking of the 
PATCH_OBJECT type. Reasonably sure I'm going to change patch-like 
objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change 
will make for no functional changes beyond parser checks not allowing 
patch-like objects in certain operations where they should probably 
never have been allowed - like manual bounding.

Post a reply to this message

Attachments:
Download 'test00.pov.txt' (4 KB) Download 'bndby_clpby_not_coincident.png' (146 KB) Download 'bndby_clpby_coincident.png' (184 KB)

Preview of image 'bndby_clpby_not_coincident.png'

Preview of image 'bndby_clpby_coincident.png'

On 10/13/25 21:37, William F Pokorny wrote:
> For clipped_by{} the modes are:

Attached a couple images showing modes 2 and 3 of clipped_by{}.

The core SDL looking like:

#declare OO = object {
     sphere { 0, 0.5
         texture          { pigment {Green} normal { micro 0.5 } }
         interior_texture { pigment {Red}   normal { micro 0.5 } }
     }
     bounded_by { mode 1
                  sphere { <+0.3,+0.0,+0.0>, 0.25 }
                  sphere { <-0.3,+0.0,+0.0>, 0.25 }
                  sphere { <+0.0,+0.3,+0.0>, 0.25 }
                  sphere { <+0.0,-0.3,+0.0>, 0.25 }
                  sphere { <+0.0,+0.0,+0.3>, 0.25 }
                  sphere { <+0.0,+0.0,-0.3>, 0.25 }
     }
     clipped_by { mode 3
                  sphere { <+0.3,+0.0,+0.0>, 0.25 }
                  sphere { <-0.3,+0.0,+0.0>, 0.25 }
                  sphere { <+0.0,+0.3,+0.0>, 0.25 }
                  sphere { <+0.0,-0.3,+0.0>, 0.25 }
                  sphere { <+0.0,+0.0,+0.3>, 0.25 }
                  sphere { <+0.0,+0.0,-0.3>, 0.25 }
     }
     // Or: clipped_by { mode 3 bounded_by }
}

Bill P.

Post a reply to this message

Attachments:
Download 'bndby_1_clpby_3.png' (61 KB) Download 'bndby_1_clpby_2.png' (52 KB)

Preview of image 'bndby_1_clpby_3.png'

Preview of image 'bndby_1_clpby_2.png'

On 10/13/25 21:37, William F Pokorny wrote:
> Aside:
> ------
> In working on these updates I've run across more checking of the 
> PATCH_OBJECT type. Reasonably sure I'm going to change patch-like 
> objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change 
> will make for no functional changes beyond parser checks not allowing 
> patch-like objects in certain operations where they should probably 
> never have been allowed - like manual bounding.

I've adopted this change for R20 of yuqk.

---

I'm also attaching an image and the test scene I used to produce the sub 
images in it. Demonstrating a few ideas previously mentioned.

1) Creating a inside region (no-surfaces) object{} using clipped_by{} 
and going on to use that region to create 'cap surface shapes' and 'side 
surface shapes' all in SDL. Upper left.

2) The union of both surface shapes in (1) can be used over a slower 
merge{} where clean dual surface intersections are necessary for 
features like media (lower left).

3) As mentioned previously: The clipped_by{} object modifier uses shape 
inside test(s). The inside test for isosurface shapes is fast - and very 
well defined (upper right).

4) Using (3), demonstrating the creation of fragmented surfaces using a 
mod() like function in the isosurface{} used in as the clipped_by{} 
object against the target Int00 side surfaces shape (lower right).

Bill P.

Post a reply to this message

Attachments:
Download 'clpbyplay.pov.txt' (3 KB) Download 'clpbyplay.png' (312 KB)

Preview of image 'clpbyplay.png'

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

> > In working on these updates I've run across more checking of the
> > PATCH_OBJECT type. Reasonably sure I'm going to change patch-like
> > objects now BASIC_OBJECT types to PATCH_OBJECT. My bet is this change
> > will make for no functional changes beyond parser checks not allowing
> > patch-like objects in certain operations where they should probably
> > never have been allowed - like manual bounding.

I do understand this.

However, let me just throw this out there for very long-term consideration.

After porting code from software packages like Mathematica, I find it
interesting the degree of flexibility their expressions have.

If there is a way that we can at the very least keep an eye on this potential, I
suggest that we do so.  Perhaps this may only be in code "stubs" or comments.

If something like a disc {} has an inside that POV-Ray can use under the hood,
then the user ought to have access to this as well.  And I would point out that
this may suggest changing the entire way that we approach defining and rendering
the shape.

Consider that I have a disc{}, and want to make future use of it in a way that
is not directly related to _rendering_ the disc.  I may want to do something
like illuminate the space above it with media.  It would be useful to be able to
bound the space above it.

Presumably the disc has an "inside" that is the cylindrical region below it in
the half-plane.  I ought to be able to easily make use of that.  And limit it
with a distance along that normal axis.  As well as the space above it
(trivially done with scale -Normal).  But then also have the disc {inverse} work
as well.


Maybe I want to align a thing with the disc.
Or limit something to with its radius.
or cut a hole in the ceiling above it.
or project it onto an axis or a plane.

It would be nice to be able to "expand" that disc into a cylinder {} of some
sort.  Or a line segment of its projection.
We can either do that with the native shape, or we can add tools to make this
data available in some other form.   I have suggested that we have a point{}
"shape", and being able to union {} those into a line segment would a useful
thing as well.  Because at present we have no way to (easily) apply translate,
rotate, and scale to such constructs.

We have the things - which are imperfectly and incompletely implemented,
but what I'd argue that we need are the tools to better make use of them in a
simple, nimble manner that doesn't require new, average, or even experienced
users to take a course in linear algebra, calculus, or spend 3 hours trying to
to come up with the proper search terms and find valid, relevant, comprehensible
results so that they can accomplish a conceptually simple geometric task.

So, I take no issue with simplification - as a first step towards straightening
out the code base.  However I'm a strong proponent of developing things in such
a manner that they can be expanded upon and used for more than the simplest and
most limited of purposes.

- BW

If we adopt the cylinder shape that I speculate about in the other thread, then
perhaps the end caps can define the entire shape.
We would have two surface normals and two radii, and so would be able to have
cylinders, cones, and not trigger a degenerate cylinder error.

As always, much to think about.

Post a reply to this message