use mesh primitive for submesh use

[ousttrue]

I think it is better to use mesh primitives for submesh. submesh assumes the following call, for example:

// pseudocode
setVBOandIBO (mesh);
var offset = 0;
foreach (var submesh: submeshes)
{
    setMaterial (submesh.material);
    gl.drawElements (sbumesh.mode, submesh.count, mesh.indicesType, offset);
    offset + = submesh.count;
}

submesh is a range of indices (offset, count), with material as a specific parameter.

Relatedly, in many apps, Blender and Unity, MorphTarget is per mesh, not per submesh. It is more convenient if targets are on mesh.

In order to use the mesh primitive for submesh, Suggest moving primitive.indices, primitive.attributes, primitive.targets to mesh. Also add offset and count to the primitive. Also, change node.mesh to node.meshes.

#1278

[ousttrue]

Alternatively, I thought that adding primitive.submeshes could be changed for backward compatibility. Each submesh has indexOffset, indexCount and material.

[donmccurdy]

Related: https://github.com/KhronosGroup/glTF/issues/1090

I'm inclined to agree that more parallelism among primitives of a single mesh would be a good thing, and we should consider this in future spec versions. But we can't make that change to the 2.0 spec, and I don't think that publishing an extension adding these restrictions would achieve much.

[GuoLei1990]

I strongly agree with this point of view. I find glTF's primitive design a bit strange. Although it seems very flexible, it brings several negative effects and almost no positive value:

1. Vertex Buffer is not compact. If the engine's "SubMesh" follows this design, each "SubMesh" Vertex Buffer will require CPU -> GPU. If the primitive adopts the "offset and count" design, it only needs to be uploaded once. After researching, I found that three and babylon had to be split into multiple Mesh. It seems that the current design is not popular, and the engine had to do some Hack conversions.

2. In addition, if the engine's "SubMesh" follows this design, the API will be cumbersome. If different attributes are really needed, I think it should be directly split into different Mesh. This design does not have unique necessity. Obviously "offset and count" is of greater design value. In fact, the glTF exported by DCC is basically the same as the attributes of different Primitives under Mesh. But as an engine implementer, you are often worried about potential inconsistencies.