POV-Ray : Newsgroups : povray.pov4.discussion.general : Potential v4.0 bounding & clipping fixes / changes. (yuqk R20 v0.6.14.0) : Potential v4.0 bounding & clipping fixes / changes. (yuqk R20 v0.6.14.0) Server Time
16 Oct 2025 12:37:51 EDT (-0400)
  Potential v4.0 bounding & clipping fixes / changes. (yuqk R20 v0.6.14.0)  
From: William F Pokorny
Date: 13 Oct 2025 21:37:41
Message: <68eda965@news.povray.org>
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'
bndby_clpby_not_coincident.png

Preview of image 'bndby_clpby_coincident.png'
bndby_clpby_coincident.png


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.