On 9/25/21 6:18 PM, Samuel B. wrote:
> I did consider doing some 'manual' bounding for the tori (boxes sized to
> encompass only the clipped objects), but I'm not sure how much it would actually
> help since there would still be plenty of empty space where no ray could ever
> make an intersection.
> 
>> Someday need to play with something for arcs based upon 'carefully'
>> placed blobs -
> Are you talking about using blobs as the bounding objects, to take advantage of
> their bounding performance vs. the toruses' bounding performance?
> 
>> or maybe some kind of tori slice and dice into a union
>> for performance. My expectation is we can do better than that internal
>> Test_Thick_Cylinder() test bounding wise.
> Slicing and dicing tori for smaller bounding objects? Sound complex...
> 
> One thing I've noticed about slicing objects (using clipped_by, open geometry,
> etc.) and putting them into a union, is that weird artifacts can appear when
> rendering them. Especially if transparency in involved.

I did take a quick try manually bounding and rendering with -ur to 
prevent the manual bounding from being stripped (this a long while now 
the default). As you thought it didn't really help.

With the tori as blobs thinking of something like Bruno Cabasson's 
elliptic_torus.pov from back in 2005/6 - less the elliptic part. 
Something to create tori from blobs. Hmm, guess that could be tried to a 
first order by setting the major and minor elliptical axis to the major 
axis for each torus. There is in this approach a parse time vs render 
time trade off. There the minor axis is << the major one the parse times 
will start to become significant.

Yes, the slicing would need a merge over a union if there was any 
transparency and then when might not gain much in performance. I only 
ever tried the slicing approaches with isosurfaces and there too didn't 
often win. I don't know, an idea.

Aside: Never looked at it much, but in many places code wise the 
bounding and clipping mechanism is set up to support multiple shapes in 
a c++ vector... So guessing someone was thinking in the direction of 
more complex bounding at some point, but it's code not 'exploited' in 
that way as far as I know. Well, impossible currently to use it as the 
implementation is not complete. Not all shapes look to step through all 
the items in the vectors while looking to bound or clip intersections, 
for example. And yes, I think there is some performance overhead for 
having this mechanism partly there when all we seem to use is simpler 
single 'objects' while clipping or bounding (those can themselves be 
complex). Clipping also uses inside tests which for some of our shapes 
and for complex csg can be quite slow. Anyhow...

Bill P.

Post a reply to this message