Le_Forgeron schrieb:

>> If there any feasible fix for the difference/intersection ray/object
>> intersection performance problem? (I mean, aside from altering the scene
>> file...)
> 
> the "problem"b (as far as I know) is only due to the bounding box
> computation. If you can get a better bounding box, you would save a lot
> from real object computation.

No the problem is actually a much different one (see below).

> intersection of sphere at <0,0,-10>, radius 10.3
> with sphere at <0,0,10>, radius 10.3
> 
> the bounding box of each sphere is a box of 20.6 side.
> the bounding box of the intersection is 20.6 x 20.6 x ~40
> (that's a volume!)

If you actually try this, you'll find that POV-Ray will come up with a 
bounding box from <-10.3,-10.3,-0.30> to <-10.3,-10.3,-0.30>.

Intersection bounding boxes are computed by intersecting the individual 
boxes, not adding them.


The /real/ problem typically manifests as the "many-holes problem": 
Picture a 20x20 units slab, with 1 unit diameter holes drilled at 
distances of 2 units, cut out using cylinders and the "difference" 
statement. That's 10x10 = 100 holes. Internally, the construct is 
represented as an intersection of a box and inverse cylinders.

Now, whenever the construct is tested for an intersection, this involves 
  two steps:

(1) Compute /potential/ intersections with the compound object, by 
finding intersections with the primitives.

(2) Test which of the potential intersections is contained in /all/ 
other members.

Step 1 is not much of a big deal, as POV-Ray uses a quite smart bounding 
hierarchy there.

Step 2, however, breaks your neck - not because each test would be 
difficult; actually, POV-Ray can (and does) make use of bounding boxes 
here, too (if the point is outside the inverted cylinder's bounding box, 
it is definitely outside the cylinder and therefore inside its inverse, 
and further testing is only required when inside the bounding box). But 
when having to perform the test for 100 members, it's still bad enough.

What's missing there is probably some bounding hierarchy in CSG 
intersection objects. Or, alternatively, a completely different approach 
at intersection-type CSG objects that gets away without inside-tests, 
instead making use of intersection tests only (checking the order in 
which the light ray enters and leaves the members).

Post a reply to this message