Difference between revisions of "Mesh library cleanup"

(Add link to 90nmg paper)
m
Line 1: Line 1:
 
BRL-CAD has an extensive n-manifold (NMG) polygonal mesh library presently embedded within LIBRT.  N-manifold is mostly a fancy way of saying it provides an arbitrary boundary representation structure.  This library is used for a wide range of tasks but is commonly interacted with during geometry export to polygonal formats (e.g., g-stl).  The library goes to extensive lengths to ensure that geometry is "correct" at every step along the way, that solidity is preserved, that topology is preserved, and more.  All of that work means that the library can be slow and over time has become even more "unrobust" to real geometry.  There are lots of O(n^2) and O(n^3) algorithms with dynamic memory allocations that make performance suboptimal.  The source code is the documentation.  It's one of the best at what it does, but far from good enough.
 
BRL-CAD has an extensive n-manifold (NMG) polygonal mesh library presently embedded within LIBRT.  N-manifold is mostly a fancy way of saying it provides an arbitrary boundary representation structure.  This library is used for a wide range of tasks but is commonly interacted with during geometry export to polygonal formats (e.g., g-stl).  The library goes to extensive lengths to ensure that geometry is "correct" at every step along the way, that solidity is preserved, that topology is preserved, and more.  All of that work means that the library can be slow and over time has become even more "unrobust" to real geometry.  There are lots of O(n^2) and O(n^3) algorithms with dynamic memory allocations that make performance suboptimal.  The source code is the documentation.  It's one of the best at what it does, but far from good enough.
  
This project entails basic source code cleanup, validation, and verification.  As the library code is embedded into LIBRT, the first step is to extricate it to it's own directory.  That will require some header reshuffling and maybe some work to formally split LIBNMG's API entirely from LIBRT.  With that complete, the next step is documentation cleanup pulling all of the source code comments into the nmg.h public header (or sub-header thereof) to become familiarized with the API.  Then begin testing the lowest-level functions to make sure they do exactly what they are supposed to do by creating API unit tests.  Test-driven development is a must here.
+
This project entails basic source code cleanup, validation, and verification.  As the library code is embedded into LIBRT, the first step is to extricate it to its own directory.  That will require some header reshuffling and maybe some work to formally split LIBNMG's API entirely from LIBRT.  With that complete, the next step is documentation cleanup pulling all of the source code comments into the nmg.h public header (or sub-header thereof) to become familiarized with the API.  Then begin testing the lowest-level functions to make sure they do exactly what they are supposed to do by creating API unit tests.  Test-driven development is a must here.
  
 
=References=
 
=References=

Revision as of 21:28, 26 March 2012

BRL-CAD has an extensive n-manifold (NMG) polygonal mesh library presently embedded within LIBRT. N-manifold is mostly a fancy way of saying it provides an arbitrary boundary representation structure. This library is used for a wide range of tasks but is commonly interacted with during geometry export to polygonal formats (e.g., g-stl). The library goes to extensive lengths to ensure that geometry is "correct" at every step along the way, that solidity is preserved, that topology is preserved, and more. All of that work means that the library can be slow and over time has become even more "unrobust" to real geometry. There are lots of O(n^2) and O(n^3) algorithms with dynamic memory allocations that make performance suboptimal. The source code is the documentation. It's one of the best at what it does, but far from good enough.

This project entails basic source code cleanup, validation, and verification. As the library code is embedded into LIBRT, the first step is to extricate it to its own directory. That will require some header reshuffling and maybe some work to formally split LIBNMG's API entirely from LIBRT. With that complete, the next step is documentation cleanup pulling all of the source code comments into the nmg.h public header (or sub-header thereof) to become familiarized with the API. Then begin testing the lowest-level functions to make sure they do exactly what they are supposed to do by creating API unit tests. Test-driven development is a must here.

References

Requirements

  • Ability to read and refactor complex C
  • Ability to write API unit tests