What are the disadvantages of using indexed faces with bufferGeometry?
I understand that the indexed nature allows you to share vertices between faces, which makes the code look cleaner, but doesn’t this constrain things in other ways? What are the cons to using indices? I’m asking because I’m planning to migrate to using buffergeometry and need to understand whether to use indices or not.
You can use both variants as needed. In my BeginnerExample (step 2) the flower is not indexed. Here also only some points of the triangles are identical. In paperplane I used indices.
My addon Addon. Produces almost infinite many time-varying geometries with functions I had created first with the old geometry, and after a hint both as indexed and non-indexed geometry . Only with the non-indexed geometry the explode mode is possible.
So it depends on what you want to do and which variant is more suitable.
another example Magic Box
@prominent
Hi!
See, how vertexColors on an indexed geometry (left) differs from a non-indexed one (right)
Example: https://jsfiddle.net/prisoner849/6gL4ayoz/
Picture:
Thanks @hofk and @prisoner849 … Looks like with non-indexed geometry you get a bit more control, but you are forced to keep the attributes parallel to each other, right? So it’s a bit more strict in that regard. I assume normals and uvs are similar to colors, @prisoner849 ?
When coming from the old Geometry, it is easier to start with indexed BufferGeometry first. For special things you can use non-indexed BufferGeometry later.
See three.js examples
Use the button below.
I noticed in @prisoner849 example, that he had to use .toNonIndexed() for the non indexed version…
So I’m assuming Three.js defaults to indexed versions for all their geometry? @hofk
I guess it would make sense to stick to the default way while I migrate to buffergeometry.
Thanks.
Finding examples of the use of indices is not a problem, but the documentation doesn’t explicitly state that they index everything by default.
