>> The other options that came to mind were to either go the negative route 
>> where you'd have an EXCLUDE option for output formats you don't want (e.g., 
>> EXCLUDE="nmg brep+csg", EXCLUDE=bot, etc) or let EVALUATE merely specify 
>> primitive types (e.g., EVALUATE="bot brep") and have a second option toggle 
>> retention of the CSG hierarchy (e.g., HIERARCHY=1).  The latter would 
>> probably imply needing to add that support for the bot and nmg types at the 
>> same time (so it's consistently all or nothing).


> I agree with using an EXCLUDE option together with a HIERARCHY option. If 
> neither of them are set, all conversions are evaluated. But the support for 
> bot and nmg is needed.


As there are only evaluated nmg and bot conversions and unevaluated brep 
conversions available, I'd like to add the EXCLUDE option only.

>> rt_comb_brep() should be consistent with the other routines and generate a 
>> brep version of that comb, so that's something for later after 
>> surface-surface intersections are working.  The brep command could certainly 
>> walk a hierarchy, though, and produce a new hierarchy of breps (similar to 
>> clone command, perhaps calling it underneath).  Alternatively, you could do 
>> all that work inside the conversion.sh script manually converting all 
>> primitives to the various requested EVALUATE formats.

> OK, I will add the feature to deal with comb to the brep command, which is 
> considered to be implemented later.


How to deal with the likely duplication of brep primitives? For example, if 
comb A.r contains 1.s and 2.s, if we convert A.r, 1.s and 2.s together, should 
we generated two brep for 1.s and 2.s (one for the comb, and one for 
themselves)?


Cheers!
Wu
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Reply via email to