Tom, There is a completely new technique under development (involving NURBS), but the general approach utilized by g-xxx.c and friends is still the main method in use. The old technique is basically walk down to the primitives, tessellate them, and then perform boolean mesh operations all the way up to the region level.
The (nmg) boolean mesh evaluator attempts to maintain topological consistency particularly with respect to preserving solidity, preventing the introduction of cracks, removing degenerate/invalid geometry, and otherwise only allowing tessellation that is "reasonably faithful" to the implicit geometry as best can be approximated. That eagerness to not allow non-solid geometry and a lack of robustness due to lacking numerical precision results in the notorious tessellation export failures. That said, there are several tricks even for the old technique that come to mind (and are often put to practice) that vary on a case-by- case basis: 1) push down your regions. If you have a region of non-overlapping grouped combinations, make each subcombination its own region. The further you can push down the regions without introducing overlaps, the better. It's less work for the boolean evaluator and increases the probability that it'll succeed. 2) eliminate regions (aka tessellate at the primitive level). if you're not actually utilizing CSG operations other than to group and organize, you can just tessellate primitives individually for the purpose of export conversion. 3) change the tessellation tolerances. this is a trick our pro/e export plugin uses that results in nearly 100% successful tessellated imports. when a tessellation fails, the tessellation tolerance is refined (increased) and tried again. even on the existing exporters, except for cases of bad input geometry, tessellation export failures can often be provoked to succeed by retrying the failed regions individually with different tolerance values. Your 100% fail-to-convert .g file sounds like a great attachment for a bug report: https://sourceforge.net/tracker/? func=add&group_id=105292&atid=640802 Forewarned, though -- the problem I've seen with regards to fastgen conversions is almost always a case of degenerate geometry .. targets that aren't solid, that have holes, dangling faces, topological inversions, and worse. If it's garbage in, there's only so much we can do to repair it before manual adjustments are required. Cheers! Sean On Jun 2, 2009, at 7:08 PM, Tom Browder wrote: > I'm still using the conventional facetization techniques demo'd by > John Anderson in g-xxx.c and friends. > > And I wonder if there any new tricks in the csg -> bots bag these > days. > > If anyone needs some .g conversion testing of some ugly regions > (usually from fastgen -> brlcad conversions), I can provide a 100% > fail-to-convert .g file. > > Regards, > > -Tom > > Tom Browder > Niceville, Florida > USA > > ---------------------------------------------------------------------- > -------- > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the > latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
