-
Notifications
You must be signed in to change notification settings - Fork 119
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
Variable-length lists are not supported #3
Comments
Hah! Yes, you found some dirty laundry. I think the most practical, real-world example is a file that -- as you mention -- has tris and quads. The bad news is that adding support for this would probably require a re-write of both the API and internal parsing function. |
I managed to implement this feature: if the list length is set to 0, the property is treated as a variable-length list, stored as a |
👍 yes please! |
I'm still working on this, I fixed some more issues. For example, we might want to read face data only, thus skipping vertex elements entirely, which was not supported apparently. |
I also can't find an API to at least read the number of elements in a list, e.g. 3 for triangles and 4 for quadrics. Or do I miss something? If I expect all faces to be triangles, but they are quadrics, my application using tinyply crashes :-( |
Hi @marnef unfortunately this API doesn't exist on the master branch yet, but you can check out the |
Hi,
First of all thanks for the library. While testing it, I encountered the following issue.
The common use cases involve fixed-length lists for properties (e.g. faces made of 3 vertices), but the PLY format also supports variable lengths for the lists of each element, for example:
(example taken from Paul Bourke's personal page)
Here faces are described as both triangles and quadrilaterals, thus taking either 3 or 4 values. Apparently, this use case is not supported by tinyply yet, since these properties are serialized into a single vector, without keeping track of how many values are assigned to each element. We could also imagine cases where these lists can take any value (0 included).
Thus, for such cases, we might need to store the data in
vector<vector<T>>
(orvector<T>
with an additional vector of offsets).The text was updated successfully, but these errors were encountered: