3 ms·
No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information get
by gmueckl 8y ago
No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.
- fulafel 8y agoAh, we may be talking past each other then. So I reiterate my point from upthread: > Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.
- gmueckl 8y agoThia is true only if you have the foresight to write custom allocators. Unless you limit possible mesh topologies, you must deal with many tiny arrays for each vertex, edge and face and their lengths are not uniform.
- fulafel 8y agoYes, depending on what you mean by custom allocator... but this is the same in C++ too, right? To store custom vertex / face attributes, you can use a variety of sparse techniques to save memory from sitting unused in attribute arrays. Basically you want an interface of get_attribute(type, vertex_id). This sparse matrix, trie, or whatever can be backed by int or float array storage instead of many many tiny malloc'd/gc'd objets.
- gmueckl 8y agoYes, these backing constructs essentially become special case memory managers for the problem domain. You may call then by different names, but the essential behaviour is the same.