blackencino
commented
12 years ago So - I had some thoughts about these comments.
I don't think compilation speed should be a governing factor in our design. If we can achieve ideal performance with static polymorphism and template-heavy code, we should do so.
Secondly - with a half-edge or quad-edge or similar 'poly mesh editing' structure, the whole point of it is to be dynamically manipulable on a per-element level in constant time. These structures are necessarily allocated per-element and manipulated via pointers. Once the mesh has been "finished editing" or is finished being constructed, of course it makes sense to bake the half-edge or quad-edge into a vectorized representation - which is what I imagine the Hbr->Nsd transition entails - but otherwise, isn't manipulability and easy traversal the main goal of a mesh representation like that in Hbr?
Please pardon my abstract understanding of the code, I am just responding to Jerome's comments.
Chris
On Thu, Jun 28, 2012 at 10:12 AM, Manuel Kraemer < reply@reply.github.com
wrote:
Some suggestions from jcgagnon :
First, seems that all the code is in header files because you templated the precision of the vertex position; I think that makes things heavier for the compiler, and if the positions were stored in some generic attribute conatiner (like in Alembic), and were accessed through some interface instead of being embedded directly in the mesh structure, just like other attributes (UVs, normals, etc), it could help make the code cleaner. The position attribute could itself be templated by its precision, but a generic interface to access to it would avoid to template all the mesh and algorithms based on that. That generic interface could include calls such as processing some linear combination of attributes. And, position-related algorithms could be templated based on precision, but at least it would be localized.
Another thing is the choice, in hbr, to use pointers and instanciated classes (mesh, edge, vertex) directly as the stored structure. Although that might make things look more user-friendly, it makes everything take more memory and have more memory fragmentation. In particular, can no longer reallocate memory blocs and need to use that bloc allocator so your pointers remain valid (in which I would use more than 64 elements per blocs, which seems to be your default). To me, that is a bit like if std::vectors were implemented by storing an array of <iterator, data> pairs; it's a lot of redundancy that doesn't need to be always in memory. Instead, personally I prefer to store data in compact data structures, and instead use temporary iterators (or accessors) to add, when needed, the user friendly wrappers on top of it. For instance, the vertex data would be pure data, but the stack-allocated vertex accessor (or iterator) would wrap both the vertex index and the mesh pointer, and give all the required facilities (get adjacent faces, children faces, vertices, etc). And, using indices instead of pointers make the structure realloc-friendly, which is good since keeping the data in contiguous, big arrays avoids memory fragmentation, which is often biggest performance bottleneck when in polygon mesh data structures.
Reply to this email directly or view it on GitHub: https://github.com/PixarAnimationStudios/OpenSubdiv/issues/33
I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.
manuelk
gelder
jcgagnon
Some suggestions from jcgagnon :
First, seems that all the code is in header files because you templated the precision of the vertex position; I think that makes things heavier for the compiler, and if the positions were stored in some generic attribute conatiner (like in Alembic), and were accessed through some interface instead of being embedded directly in the mesh structure, just like other attributes (UVs, normals, etc), it could help make the code cleaner. The position attribute could itself be templated by its precision, but a generic interface to access to it would avoid to template all the mesh and algorithms based on that. That generic interface could include calls such as processing some linear combination of attributes. And, position-related algorithms could be templated based on precision, but at least it would be localized.
Another thing is the choice, in hbr, to use pointers and instanciated classes (mesh, edge, vertex) directly as the stored structure. Although that might make things look more user-friendly, it makes everything take more memory and have more memory fragmentation. In particular, can no longer reallocate memory blocs and need to use that bloc allocator so your pointers remain valid (in which I would use more than 64 elements per blocs, which seems to be your default). To me, that is a bit like if std::vectors were implemented by storing an array of <iterator, data> pairs; it's a lot of redundancy that doesn't need to be always in memory. Instead, personally I prefer to store data in compact data structures, and instead use temporary iterators (or accessors) to add, when needed, the user friendly wrappers on top of it. For instance, the vertex data would be pure data, but the stack-allocated vertex accessor (or iterator) would wrap both the vertex index and the mesh pointer, and give all the required facilities (get adjacent faces, children faces, vertices, etc). And, using indices instead of pointers make the structure realloc-friendly, which is good since keeping the data in contiguous, big arrays avoids memory fragmentation, which is often biggest performance bottleneck when in polygon mesh data structures.