From: Christopher Sean Morrison <brlcad@ma...> - 2008-08-28 18:20:04
On Thursday, August 28, 2008, at 12:02PM, "Gwyn, Douglas (Civ, ARL/CISD)" <gwyn@...> wrote:
>> Here, the modeler subtracts the engine_assembly from the left_body.r
>> region in order to (presumably/usually) remove an overlap between the
>> engine and the body. Instead of figuring out exactly what regions
>> are involved in the overlap, the modeler took the easy route out and
>> just subtracted the entire region. This is generally very bad
>> practice (usually due to performance), but it happens and it's still
>> considered "valid".
>It appears that somewhere along the way, BRL-CAD has been made to
>implement only the old GIFT structures rather than the more general
>combinatorial geometry that was meant to replace them. Far from
>being "bad practice", the user really ought to be able to subtract
>*any* object geometry from any other in the course of modeling,
>without having to perform any additional work himself. Also, what
>happens when you subtract a region that itself contains a (nested)
>subtraction? The software really ought to "optimize" the tree
>structure to produce a canonical form, if it requires such a form
BRL-CAD does implement generalized boolean logic on the hierarchy -- that hasn't changed. It's usually 'bad' but IS still considered completely 'valid'. We don't warn or otherwise even complain for that very same reason that you point out. The performance issue could very well (sometimes) be automatically resolved through optimizations, null object detection, tree simplification, and a variety of other measures.
It's no more "bad yet still valid" than it is using a half-space to perform cutaways when the modeler could have used an arb8 instead. It'll certainly work and is entirely valid, but it's considered bad practice solely for implementation/performance/semantic reasons.
Whis is completely different from the "bad and invalid" situation where you maybe try to union two different regions or add an existing region to another region (creates an overlap or undefined material configuration).
Subtracting regions with nested subtractions is not a problem in the least and should even be optimized accordingly to not evaluate that portion of the hierarchy if a larger overlapping segment of the ray was already culled. That said, that same optimization causes really obscure numeric instability on some fairly complicated cases, but most of the time we enjoy a nice performance boost. There was a GSoC suggested project to look into fixing that problem (and implementing other CSG optimizations like you've suggested), so maybe next year someone will pick it up.