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

interleave vertex attributes #21

Closed
fabrobinet opened this issue Mar 20, 2013 · 10 comments
Closed

interleave vertex attributes #21

fabrobinet opened this issue Mar 20, 2013 · 10 comments
Labels

Comments

@fabrobinet
Copy link
Contributor

No description provided.

@pjcozzi
Copy link
Member

pjcozzi commented Mar 20, 2013

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.

@RemiArnaud
Copy link
Contributor

As far as paging, interleaving does not help for indexed geometry, but would help for not indexed geometry

@pjcozzi
Copy link
Member

pjcozzi commented Mar 20, 2013

I'm not sure what you mean by paging in this context.

@RemiArnaud
Copy link
Contributor

Streaming

@pjcozzi
Copy link
Member

pjcozzi commented Mar 20, 2013

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.

@RemiArnaud
Copy link
Contributor

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.

Yes, sorry I was not explicit.
I don't think your argument is valid though - regarding requesting the
indexes in parallel - as there is a limited (6 currently) available
parallel requests, and as the same argument could be made to any other

of non interleaved data.

In any case, I am fine with having interleaved indexed the default, but I
would like to also have non-interleaved non-indexed as an option.

@pjcozzi
Copy link
Member

pjcozzi commented Mar 20, 2013

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.

In any case, I am fine with having interleaved indexed the default, but I
would like to also have non-interleaved non-indexed as an option.

This can be discussed in #14, but the current thought is to require indices.

@pjcozzi
Copy link
Member

pjcozzi commented Oct 22, 2013

I suggest post 1.0 if need be. This is a nice optimization, but is minor in most cases.

@fabrobinet
Copy link
Contributor Author

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.

@pjcozzi
Copy link
Member

pjcozzi commented Dec 23, 2017

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

@pjcozzi pjcozzi closed this as completed Dec 23, 2017
emackey pushed a commit to emackey/glTF that referenced this issue Jun 23, 2022
…als_iridescence

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

No branches or pull requests

3 participants