BufferGeometry design questions

I have a couple of questions regarding the design and goals of BufferGeometry.

  1. It is well known that a BufferGeometry can be reused by multiple Object3D of the same kind. For instance, a BufferGeometry can be shared by two Mesh.

But can a BufferGeometry be reused by the two objects of different kinds, say a Mesh and a Line? And if so, does it require an indexed geometry with drawcalls?

  1. Can a BufferAttribute be reused in multiple BufferGeometry. For instance, is it legal to create a bunch geometries sharing a single position buffer, but each having its own color buffer?

If the BufferAttribute wrapper can’t be shared, can the typed array .array be shared?

  1. Are per-element attributes going to be supported in BufferGeometry? For instance, color-per-face. Of course, the color-per-face array would need to be unroll into a per-vertex temporary array during the createBuffer or updateBuffer phase of the renderer anytime an update is needed.

Author: Fantashit

1 thought on “BufferGeometry design questions

    1. But can a BufferGeometry be reused by the two objects of different kinds, say a Mesh and a Line? And if so, does it require an indexed geometry with drawcalls?

    No(ish) I found the draws are not happy when you cross the types (e.g. gl.LINES and gl.TRIANGLES) against the same buffer, and the drawcall actually returns an error about binding issues – however I didn’t scientifically confirm this was the reason; sometime you get weird errors 🙂 but see 2b) which is a quick work around.

    1. Can a BufferAttribute be reused in multiple BufferGeometry. For instance, is it legal to create a bunch geometries sharing a single position buffer, but each having its own color buffer?

    Yes, easily and the shared data will be uploaded to gpu once and shared between all the objects.

    If the BufferAttribute wrapper can’t be shared, can the typed array .array be shared?

    Yes, is more “when” rather than “can’t” due to different draw types, though this will double load the data to gpu.

    There are also the more exotic options of:

    InterleavedBufferAttribute where multiple BufferAttribute share the same .array via InterleavedBuffer so that vertex data can be positioned in proximity:

    Which allows you to achieve some of the best practices for mobile:

    Interleaved Buffers

    You can mix InterleavedBufferAttribute with regular BufferAttribute or DynamicBufferAttribute when your use cases for the buffers is different, for example one of them gets updated but the other is fixed. (see best practices link above):

    68747470733a2f2f646576656c6f7065722e6170706c652e636f6d2f6c6962726172792f696f732f646f63756d656e746174696f6e2f334444726177696e672f436f6e6365707475616c2f4f70656e474c45535f50726f6772616d6d696e6747756964652f4172742f7573

    1. Are per-element attributes going to be supported in BufferGeometry?

    Don’t know answer to this; but related to complete the BufferAttribute picture there is also InstancedBufferAttribute to use with InstancedBufferGeometry; which allows you repeat the mesh, but with different per mesh attributes.

    Some examples of the exotic types are:

    Buffergeometry Instancing
    Buffergeometry Instancing – Billboards
    Buffergeometry Instancing – Dynamic updates
    Buffergeometry Instancing – Interleaved + Dynamic Updates

    1. Can we get rid of array safely after it made it to gpu?

    Yes if you are not going to update it and are not worried what will happen on context loss; but you should also probably be using DynamicBufferAttribute rather than BufferAttribute if you are updating as it preps the gpu with hints that this will happen better.

    HTH and maybe @mrdoob can provide more info on 3) as it sounds like the haunting MeshFaceMaterial shadow…

Comments are closed.