Understanding the structure of mesh buffers and their data

I am trying to understand how “mesh buffers” work under the hood, and had a few concerns regarding reading & using them.

I have been told that the mesh buffer (Mesh.getBuffer(VertexBuffer.Type)) is a collection of associated arrays, where each component array represents a different attribute for a different vertex in the mesh. So for instance, if the Mesh is super-simple and has only 3 vertices in it, and if my understanding of mesh buffers is correct, then I would expect this Mesh instance’s mesh buffer to exhibit the following characteristics:

  • It would contain lots of different types of component arrays (each representing different attributes, Position, Color, Normals, etc.); and
  • Each of these component arrays would contain 3 entries in them, one for each vertex in the mesh

By “entries”, I don’t mean array elements, rather, collections of elements where each collection represents all the data necessary to represent the info for a particular vertex’s attribute. So (1) let me start by asking that if any of this is incorrect, please begin by correcting me!!!

Assumung I’m correct, then I’m particularly interested in two of these component arrays, Position and Color.

The Javadoc description for Position states:

Position of the vertex (3 floats)

And the Javadoc description for Color states:

Color and Alpha (4 floats)

So for the Position component array, I’m assuming that each entry consists of 3 floats, and that each float represents a respective Cartesian axis value (x, y or z). And for Color I’m assuming each entry consists of 4 floats, where each float represents a red, blue, green or alpha value (RGBA). If this is correct, and if my previous understanding of mesh buffers (above) is correct, then using our super-simple 3-vertex mesh example, I would expect the Position and Color component arrays to look like the following:

  • Position array:
    • Size = 3 vertices * 3 floats/vertex = 9 (float) elements
    • Elements 0 - 2 represent (x,y,z) values for Vertex #1
    • Elements 3 - 5 represent (x,y,z) values for Vertex #2
    • Elements 6 - 8 represent (x,y,z) values for Vertex #3
    • Hence, if I did a mesh.getBuffer(VertexBuffer.Type.Position).getData(), I’d get a FloatBuffer containing 9 floats in it, structured exactly as I have described above
  • Color array:
    • Size = 3 vertices * 4 floats/vertex = 12 (float) elements
    • Elements 0 - 3 represent RGBA values for Vertex #1
    • Elements 4 - 7 represent RGBA values for Vertex #2
    • Elements 8 - 11 represent RGBA values for Vertex #3
    • Hence, if I did a mesh.getBuffer(VertexBuffer.Type.Color).getData(), I’d get a FloatBuffer containing 12 floats in it, structured exactly as I have described above

(2) Can someone please (kindly) confirm/correct my understanding of the structure of these Position and Color component arrays here? And if I’m completely wrong, maybe nudge me in the right direction? Thanks in advance enormously!

1 Like

Yea, that is correct.

You can also look at the code in JME to see how meshes are made. They don’t use the color buffer but they do use other buffers and the knowledge is basically interchangeable.

Perhaps adding a little confusion to the mix: “Color buffer entries are 4 floats” is only by convention. You can define fewer elements if you like as long as your shader is expecting fewer. For JME’s built in shaders, colors are four elements (ie: vec4).

You can also look at some of the BufferUtils methods to see what they do. Like:

The source code should be one click away in the SDK.

If you haven’t looked at the tutorial yet then it’s worth reading:

Else, the source code is sometimes the best way to find ideas about usage.

Thanks both @tukez and @pspeed!

Also consider that this structure very closely follows how you use vertex buffer objects in opengl. So if you have some some opengl experience it is very intuitive.

Yeah, exactly. And I forget that sometimes when wondering why people struggle so much. :slight_smile:

It was easy as pie for me to grasp because I already knew OpenGL. If you come without that then yeah, I can see how it might be a bit daunting at first. (Partly because I think people expect it’s more complicated than it is.)

1 Like

Color buffers don’t have to be 4 floats actually… Models are imported with 4 byte colors since it is more compact and usually you don’t lose any information.