Am 29.08.2015 um 23:15 schrieb Jérôme M. Berger:

>> #declare the_tiling =
>> union{
>>     #for(i, 0, 99)
>>         #for(j, 0, 99)
>>             intersection{
>>                 object{
>>                 one_piece
>>                 translate <i*0.4, j*0.4, 0>
>>                 }
>>                 cylinder{
>>                 <20,20,0>,<20,20,1>,19
>>                 }
> Try to add these lines here:
>     bounded_by { box { min_extent (one_piece)+<i*0.4, j*0.4, 0>,
>                        max_extent (one_piece)+<i*0.4, j*0.4, 0> } }
>>                 cutaway_textures
>>             }
>>         #end
>>     #end
>> }

Why fix a perfectly good and fast-rendering scene? It's the other
variant that takes ages to render.

Besides, the intersection code /already/ makes sure that the bounding
box isn't larger than what you suggest to specify manually; the bounding
box for the intersection of a given set of objects defaults to the
intersection of their bounding boxes.


Render performance goes down the drain when you have a large shape
defined as an intersection which either (A) is comprised of many large
and/or infinite shapes with a lot of overlap, or (B) contains at least
one large union of many small shapes with very little overlap all
crammed together without much of a hierarchy.

The reason is that while union CSGs only require ray-object intersection
tests with the individual member primitives, which is done quickly using
the scene's global bounding hierarchy, intersection CSGs also start out
by finding a ray-object intersection with any of its members via global
bounding, but then need to do an /inside test/ to check whether the
ray-object intersection point just found is actually inside /all/ of the
intersection's other members (and if that member happens to be a union,
that in turns means checking whether the intersection point is in /any/
of that union's members).

Another problematic case is (C) the difference of one large shape and a
lot of small shapes (such as holes cut out of a large part); as a matter
of fact, this is a special case of (A) in disguise, because internally a
difference is represented as an intersection of the first object and the
inverse of the other objects; and the inverse of a finite shape is an
infinite shape.

In case of (B), a bounding hierarchy could help speed up the inside
testing, and in case of (C) that would also help provided we'd bound the
"hole" in the infinite objects; however, currently no such local
bounding hierarchy is implemented in CSG objects.

It should, however, be possible to manually construct such a bounding
hierarchy: In case (B), you could bundle nearby union members into a
sub-union; in case (C), instead of a difference of the primary object
and many individual cutouts you could use a difference of the primary
object and a single union of cutouts, which again you could group
hierarchically into sub-unions.

Post a reply to this message