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

Provide custom memory for vertices #45

Open
HiImJulien opened this issue Aug 20, 2020 · 3 comments
Open

Provide custom memory for vertices #45

HiImJulien opened this issue Aug 20, 2020 · 3 comments

Comments

@HiImJulien
Copy link

Hey there!

Given a class mesh, which (pre-)allocates it's own memory for storing up to n vertices. I cannot modify this class.
Can I instruct TinyPly to use the preallocate memory instead of it allocating its own memory and having to copy the vertices?

@ddiakopoulos
Copy link
Owner

Can you explain you use-case a little bit more? It's the first time someone has requested this feature so I'm curious to know more. It's challenging namely because it's unclear (as an application developer) how much memory you need to preallocate and then what happens if the library needs to allocate more. Lots of things to consider :)

@HiImJulien
Copy link
Author

The use case is pretty simple: Avoid unnecessary allocations and copies for big sets of data.

The storage size for per-element properties can be calculated pretty easily, thus preallocation can occur after the header was parsed. For lists, I agree, that's a real pain in the back, requiring you to iterate through each row and reading the element count.

@fwilliams
Copy link

I'm also interested in this feature. I'm using tinply as a loader in a python library which returns NumPy arrays. I'm often using this loader for massive meshes which take up a lot of memory. I would like to have tinyply load directly into the buffer allocated for the NumPy array rather than make a copy.

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

3 participants