Modifiers And Ngons
Note: As always, I do not suggest testing the bmesh branch as yet, since it is fairly unstable at the moment
I’ve been working a lot on the modifier system (and the massive amount of code that drives it and much of the rest of the mesh system). I’ve successfully gotten through the bulk of the major changes; modifiers now have the ability to process ngons, though at the moment most don’t. I did manage to get subsurf to work with them, though interpolation currently doesn’t work (so UVs, vertex colors, etc won’t work properly with it).
The modifier system was one of the last big refactor hurdles; and while I still have a lot of work to do getting what I have stabilized, once I’ve tracked down most of the bugs I’ll be free to start concentrating on getting mesh editing to actually work again.
There will be some caveats, in the short term. Constructive modifiers (other then subsurf) will not handle ngons, instead they will work directly with the triangulated mesh data (which means if you apply them, you’ll get a horrible mess). Some can be easily rewritten in bmesh; for others, I need to see if a simpler, faster solution is possible (one of the advantages of the array modifier, for example, is that it’s fast and doesn’t take much RAM, both of which may not be true if it were simply recoded to use bmesh).
At this time, I’d appreciate it if people could give comments on the things they really hate about the old mesh modeling tools. That way I can hopefully get a better mental picture of key mistakes not to repeat (which would save me precious time having to fix them later).
Mesh data now represents faces in two distinct layers: MFaces (which is limited to triangles/quads, and is the original structure used to store faces) and MPolys. MPolys are the “real” faces, while MFaces store the triangulated form of the mesh.
DerivedMesh now makes this distinction; I’ve renamed all the interfaces for MFaces, to make it clear they operate on “TessFaces” now. For example, ->getNumFaces became ->getNumTessFaces. I then added in interfaces for MPoly, using an iterator approach for simplicity of implementation.
The iterator interface is completely different then how the rest of derivedmesh works; most of DerivedMesh assumes a fixed size per geometric element (e.g. vert/edge/face), while MPolys are actually a combination of the MPoly struct, and an array which defines the face boundary. Because of this, I felt it would be unnecessarily awkward to carbon-copy the original MFace interfaces, which generally work by duplicating specific arrays in the mesh for easy access.
If people are interested, I can post the relevant new data structures. They’re not particularly complex; Mesh and the M*** structures are for storing object-mode data, so they’re designed to be simple and fairly light on RAM. Oh, and as always, donations are nice. 🙂
Entry filed under: Uncategorized.