Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profile performances of arbitrary attributes #11

Open
eliemichel opened this issue Jul 11, 2021 · 2 comments
Open

Profile performances of arbitrary attributes #11

eliemichel opened this issue Jul 11, 2021 · 2 comments

Comments

@eliemichel
Copy link
Owner

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.

@MechWarrior99
Copy link
Contributor

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?

@eliemichel
Copy link
Owner Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants