On Aug 17, 2014, at 10:45 AM, Daniel Roßberg wrote: > Now, as the NMG primitive reorganization project reaches its end I'm a > little bit at a loss. Zhao did a great job in reducing the complexity > of the primitive to the level where it will be really used and moving > the functions into a separate library and put a lot of effort into it.
Good job Zhao! :) > The creation of a libnmg required to create a libnurb too. NURBs are > used by the bspline and nmg primitives and to avoid a cyclic > dependency between librt and libnmg they had to be moved inty an own > library. However, libnmg still uses data structures defined in > raytrace.h necessary for the ray-tracing code in libnmg. raytrace.h > is included in some of the libnmg source files but not in the nmg.h > interface declaring header file. Furthermore the vlist code had to be > moved from librt to libnmg. Would the cyclic dependency exist if we eliminated all of the old bspline code? That is, we could intently remove the ability to store non-polygonal geometries in the same NMG container. I'd like to do an audit of the algorithms before that is done, but it is certainly an option now that the brep entities are far superior in almost every way. If there are other merits of maintaining support for multiple representation forms in that same container, we should take them into consideration as well. > The bad news is that the Boolean operations code doesn't work as > before. Many problems were fixed but at least one left. It looks > like in the old code (in the trunk) a clean up was made which e.g. > removed duplicate points before the Boolean operation of two shells > was performed. With the new code (in the nmgreorg branch) it is > possible that the two shell structures have identical points, edges, > etc. because they don't share these underlying sets of geometric > information any more. I think a macroscopic perspective is needed. I have some scripts that inspect the NMG evaluation quality that was used a couple years ago when improvements to NMG were ongoing. I'd like to see how the branch currently fares against trunk and the historic graphed data we have. It it's close, it might just be good enough to merge. I can probably do this testing most easily since I already have the scripts set up. Zhao let me know which commit revision to test on the branch (please make sure it at least compiles on Linux with that revision). Cheers! Sean ------------------------------------------------------------------------------ _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
