Separate attribute format

[onox]

It seems that glTF's accessors more or less assumes using WebGL's vertexAttribPointer(). However, OpenGL 4.3 specifies the ARB_vertex_attrib_binding extension so that you just specify the format once and then switch the vertex and index buffers.

Right now, every primitives.attributes could use (in theory) a different vertex format. That means a loader either has to (wrongly) assume each primitive uses the same vertex format or otherwise do additional processing to verify that just one format is being used.

Wouldn't it be better to separate the attribute format? In WebGL this doesn't matter much; the values from the format can be combined with the (simplified) accessor when calling vertexAttribPointer(). But for OpenGL it could simplify things a bit. I don't know about Vulkan.

Basically you get something like this: (I just completely removed the accessors, but maybe it's better to keep simplified accessors (due to min/max/count))

"formatAttributes": {
    "attribute0": {
        "byteOffset": 12,
        "byteStride": 32,
        "componentType": 5126,
        "type": "VEC3"
    },
    "attribute1": ...
    "attribute2": ...
    "attribute3": {
        "byteOffset": 0,
        "byteStride": 4,
        "componentType": 5125,
        "type": "SCALAR"
    }
},
"vertexFormats": {
    "format0": {
        "attributes": {
            "POSITION": "attribute0",
            "NORMAL": "attribute1",
            "TEXCOORD_0": "attribute2"
        },
        "indices": "attribute3"
    }
},
"meshes": {
    "body.mesh.000": {
        "name": "body.mesh.000",
        "primitives": [
            {
                "format": "format0",
                "vertices": {
                    "POSITON": "body.mesh.000_buffer_view_0",
                    "NORMAL": "body.mesh.000_buffer_view_1",
                    "TEXCOORD_0": "body.mesh.000_buffer_view_2"
                }
                "indices": "body.mesh.000_buffer_view_3",
                "count": [152, 198]
                "material": "Material",
                "mode": 4
            }
        ]
    }
}

Any comments?

[lexaknyazev]

First thoughts.

These features are also present in OpenGL ES 3.1, so they could become available for WebGL someday.

Right now each buffer object represents an actual binary storage (usually one .bin file per one .gltf); bufferView - GL Buffer Object; and accessor matches vertexAttribPointer. Also, glTF accessors are used for reading uniform arrays (skinning data). min/max properties are required for bounding box estimation.

So, your idea is to set up all attributes for format0 with glVertexAttribFormat, bind them with, e.g., glVertexAttribBinding(attrib, binding), and then for each primitive check primitive.format and use glBindVertexBuffer(binding, buffer, ...)? Does it imply that each primitive must use different bufferView? Otherwise, we would need one more intermediate glTF object to store offset for glBindVertexBuffer. I also don't understand array type of primitive.count.

In theory, decoupling buffers and their data from attributes layout (i.e., binding them in mesh instead of accessor) can make glTF design closer to modern API usage, but I'm not sure how this aligns with glTF 2.0 leaning towards simplicity and API-neutrality.

[pjcozzi]

Good ideas here, but I would push this post 2.0 to control the scope and since we're not 100% set on this direction.

[onox]

Does it imply that each primitive must use different bufferView?

This would only be necessary if attributes are non-interleaved, right? So answer is: not necessarily.

I also don't understand array type of primitive.count.

They represent the number of vertices and number of indices.

Otherwise, we would need one more intermediate glTF object to store offset for glBindVertexBuffer.

This could be needed. I'm developing my own renderer and I'm using MDI for a .gltf model (for objects with 100 to a 1000 meshes). So offsets are calculated and stored in a command buffer. But I can understand that MDI is not an option for everyone.

[lexaknyazev]

#827 is the first step in this direction. I don't think anything beyond that could fit into 2.0 scope.
In the meantime, an extension could be developed with explicit restrictions and attribute format "hints" on top of existing objects. So application could look at those hints and skip unwanted processing.

[pjcozzi]

@onox feel free add your renderer to the list of glTF Tools by opening a pull request to edit this repo's CHANGES.md.

[onox]

Thank you for mentioning it. The glTF loader still needs lots of work, but when it gets into shape, I'll consider opening a PR.

[emackey]

Is this issue still needed?

[lexaknyazev]

Applications are able to go through all meshes and construct an optimal amount of attribute format descriptors for the used API. To standardize such functionality (if there's enough interest), a new extension would have to be designed.