On 9/30/25 20:41, Bald Eagle wrote:
>> We could then too use bounded_by{} to do much of what clipped_by{} can
>> do, but more efficiently.
> Why more efficiently?

Your question got me thinking - thanks. It's probably less often more 
efficient than I first thought.

The clipped_by{} process is something which runs after ray-surface 
intersections for the object being clipped are determined. Basically, it 
runs one or more shape inside tests for each surface intersection. Those 
found inside are kept, those not are ignored. The inside tests are not 
free to calculate - and they bypass the higher level generic bounding so 
the inside test often get run more than strictly necessary.

What had in mind was something like the sphere solid-not-solid example 
using a difference as a stand in for clipped_by{} where the disc was out 
of scope bounding wise. We'd use only the 'inverse' inside test - within 
the bounding box. Unlike that solid-not-solid example, the inside test 
cost close to nothing - higher compiler optimization levels should 
eliminate even the method / function call.

On letting your question bang around in my skull for a while I had the 
thought - well Bill P, you could just use the inverted disc as the 
clippped_by{} shape. In that case the inside test itself would be faster 
because it is always false. We'd still be losing out on the high level 
bounding by using clipped_by{}.

---

Related. What I'm starting to think a lot about, is trying out some 
no-surfaces-ever / inside-test-only 'non-shapes' as another class of 
objects we could use in CSG operations.

In POV-Ray proper we have the object{} pattern. (In yuqk the object{} 
pattern has been renamed bool_object{} and about a half dozen additional 
forms like dens_object, list_object{} patterns have been added.)

I 'think' there is nothing stopping us from using what are effectively 
scalar value fields (value patterns) as inside tests that can be bounded 
and used more or less 'directly' in CSG to select / ignore portions of 
surfaces. Those CSG surface results could then have spatial object 
modifiers applied, for example, in addition to specific texturing.

---

I saw your suggestion about creating some how to object documentation... 
I think clipka did something like this in a post for what is more or 
less obvious as necessary functions / methods by looking at something 
like disc.cpp. In support of any object is dedicated parsing code for 
the supporting SDL.

It's complicated beyond that rough outline. What you've been doing with 
trying to pull back the layers with the sor{} implementation is just 
what one has to do - pretty much shape by shape because they are all 
implemented somewhat differently.

Maybe, if I do get to trying on or more 'non-shapes' / 'insider'(s), I 
can keep a rough log of what I did to implement one. No promises.

Bill P.

Post a reply to this message