You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should profile the amount of new memory allocation when manipulating arbitrary attributes, and organize the API in a way that hints the user into using the most efficient approach. For instance:
v1.attributes["uv"] = new FloatAttributeValue(0.0f, 0.0f);
is less efficient than
var uv = v1.attributes["uv"].asFloat();
uv.data[0] = 0.0f;
uv.data[1] = 0.0f;
but the latter is a bit annoying to write.
The text was updated successfully, but these errors were encountered:
So I was going to add some QoL to the attribute API to encourage better (and easier) usage, but I realized that it is kind of limited and clunky as is. For example doesn't support other types like bool, or string.
So I was thinking refactoring it, but I saw in a comment in AttributeType you mention using data buffers. Are you able to elaborate on what you had in mind?
Storing vertex attribute values on a per-vertex basis fragments the memory and does a lot of repeated allocations when adding a new attribute. It would be much more efficient to allocate an array with all values for an attribute written consecutively (making the vertex list a struct of arrays rather than an array of structs), but this makes the addition/deletion of vertices trickier so I am not decided yet about the best design. (ofc it goes the same for edge, loop and face attributes).
We should profile the amount of new memory allocation when manipulating arbitrary attributes, and organize the API in a way that hints the user into using the most efficient approach. For instance:
is less efficient than
but the latter is a bit annoying to write.
The text was updated successfully, but these errors were encountered: