-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
interleave vertex attributes #21
Comments
Although the numbers I've seen are a few years out of date, for static data (which is the glTF case), interleaved vertices are slightly faster for GPUs to render than non-interleaved. I can also see it being better for progressive loading since attributes for a vertex are co-located, not distributed across buffers or widely different parts of the same buffer. For these reasons, I suggest that interleaving be the default for the converter, and that we probably don't even need an option to not interleave. |
As far as paging, interleaving does not help for indexed geometry, but would help for not indexed geometry |
I'm not sure what you mean by paging in this context. |
Streaming |
Interleaving can make streaming easier to manage because all the attributes for a vertex are next to each other - not in different locations in potentially different buffers. I believe you mean that we still need the index data to reference the vertex, which is true, but that can be requested in parallel, and as vertices that are referenced by indices become available, they can be rendered. Anyway, this is a great topic, but probably outside the scope of this issue. Just adding my vote for interleaving by default, which you seem to be OK with. |
Yes, sorry I was not explicit. In any case, I am fine with having interleaved indexed the default, but I |
I'm aware of the limit of 6, which is one reason that makes interleaving more attractive. For example, if attributes are stored across several buffer files, they might not all be able to be requested at the same time.
This can be discussed in #14, but the current thought is to require indices. |
I suggest post 1.0 if need be. This is a nice optimization, but is minor in most cases. |
Agreed. It is be possible to make the data interleaved as of now by just updating the converter, we will just not have an explicit way to expose that the data are actually interleaved in V1.0. Developers will have to infer it. |
So it is broadly useful, this beyonds in optimizations tools such as glTF-Toolkit and gltf-pipeline, not in COLLADA2GLTF. On the gltf-pipeline roadmap, CesiumGS/gltf-pipeline#1 |
…als_iridescence Update Iridescence copyright & contributors
No description provided.
The text was updated successfully, but these errors were encountered: