Hans Goudey
22ba85b510
Some of the BMesh primitive operators have a lot of overhead due to the fact that they use other operators like extrusion, removing doubles, and rotation, to build each shape rather than filling arrays directly. Implementing the primitives directly with the Mesh data structure is much more efficient, since it's simple to fill the result data based on the known inputs. It also allows also skip the conversion from BMesh to Mesh after the calculations. Speed matters more for procedural operations than for the existing operators accessible from the add menu, since they will be executed every evaluation rather than once before a destructive workflow. | Shape | Before (ms) | After (ms) | Speedup (x times faster) | | -------- | -------------| ------------| -------------------------| | Cylinder | 1.1676 | 0.31327 | 3.72 | | Cone | 4.5890 | 0.17762 | 25.8 | | Sphere | 64213.3 | 13.595 | 4720 | The downside of this change is that there will be two implementations for these three primitives, in these nodes and in `bmo_primitive.c`. One option would be re-implementing the BMesh primitives in terms of this code, but that would require `BMesh` to depend on `Mesh`, which is currently avoided. On the other hand, it will be easier to add new features to these nodes like different fill types for the top and the bottom of a cylinder, rings for a cylinder, and tagging the output with boolean attributes. Another factor to consider is that the add mesh object operator could be implemented with these nodes, just providing more benefit for a faster implementation. As a future cleanup, there is room to share code that generates the "rings" topology between different nodes that generate meshes. Differential Revision: https://developer.blender.org/D10730