On Dec 13, 2011, at 11:44 AM, Daniel Roßberg wrote: > I promised to write down some thoughts about the NMG primitive I got > during writing a C++ interface class for it. Well, here they are:
I've had this gold nugget tucked away for a while, but it's particularly relevant now as I had several NMG-relevant discussions at the mentor summit. Plus, I have a lot of time to think about it and reply during my flight... We have a GCI patch that breaks nmg back out into a separate library. Anyone care to view/apply it, make sure the build isn't busted, make sure NMG references throughout the code/docs are correct, etc? > Before, I avoided the NMG primitive e.g. I used BOTs instead. This > was mainly caused by its complex internal structure (the functions I > wrote to do a simple copy have 720 lines) and a confusing set of > manipulating functions. On the other hand it’s a good completion of > the primitives because of sub-dimensional elements (points, lines and > surfaces) and NURBS support. It should be possible to get the ogives > I’m missing(?) I fully agree on how daunting, confusing, and useful it is. As a stand-alone library, if/after we decouple it from librt, I suggest we look at reducing the scope of most of those functions as private implementation detail. We use very few of them in practice outside of libnmg. > The nmg_~ functions aren’t intuitive. There may be a need for > separating topology and geometry. However, I consider a simplified > interface with (for example) intuitive Euler operators desirable. We "sort of" have a separation of geometry and topology now. The _p use pointers are topologic references and the rest is "actual geometry"... I know not strictly true, but pretty darn close. The importance of Euler operators and their terminology must be learned, but I agree that the NMG-specific terminology adds another layer of unintuitive complexity. > If the NMG is considered to obey Euler operators then the > sub-dimensional elements are part of its nature. This would make it > to a real non-manifold in contrast to an n-manifold of pure solids (as > I understood the meaning of the two terms). Is there any value to us (as a solid modeling system) to support non-manifold geometry? While mathematically interesting to me, the modeling value is quite dubious for all but "plate mode NMG", which we obviously don't currently support. > Therefore, shouldn’t we consider to > - remove the model and nmgregion structs and make shell the basic > internal structure for the NMG primitive, I love this idea actually for a number of reasons. It will probably eliminate 100+ functions that are merely the model or region iterator. It certainly simplifies the scope considerably helping to make the library more approachable by other developers. The only problem will be that we expose model and nmgregion in numerous librt functions, and "shell" is a terrible name by itself. I'd propose shell become the 'model' terminology-wise. > - fully support intuitive Euler operators and AFAIK, it does this now. Maybe a few cases missing, but there certainly are the majority iirc. Cheers! Sean ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
