Adds support for multiple materials in a mesh

[nicoabie]

• Addresses issue #86
• decouples creating a mesh from loading a gltf file. a file can have multiple meshes and before everything was done as if it was only one merging them.
• now there an api to load the materials corresponding to each mesh of the file and you pass those materials when creating the corresponding mesh

[Interrupt]

Thinking more about this, maybe it would be easier to refactor things to rename the current 'Mesh' struct to 'SubMesh' instead, and then make a new top level 'Mesh' object that is itself an ArrayList of SubMesh objects. It makes sense for each SubMesh to own the one material they are going to draw with anyway, since that seems like a 1:1 mapping.

Then the GLTF loading could pull each SubMesh + Material out of the file, and drawing the Mesh would be as easy as drawing each SubMesh individually with the same shared draw matrices.

[nicoabie]

Thinking more about this, maybe it would be easier to refactor things to rename the current 'Mesh' struct to 'SubMesh' instead, and then make a new top level 'Mesh' object that is itself an ArrayList of SubMesh objects. It makes sense for each SubMesh to own the one material they are going to draw with anyway, since that seems like a 1:1 mapping.

Then the GLTF loading could pull each SubMesh + Material out of the file, and drawing the Mesh would be as easy as drawing each SubMesh individually with the same shared draw matrices.

Yes, only thing to note here is that there is no concept of SubMesh in GLTF

But if you prefer SubMesh and Mesh instead of Mesh and Model it is fine by me.

[Interrupt]

Yeah, to me 'Mesh / SubMesh' is more clear than 'Mesh / Model' as it seems like people use Mesh and Model interchangeably, making it confusing to talk about.

[nicoabie]

Thinking more about this, maybe it would be easier to refactor things to rename the current 'Mesh' struct to 'SubMesh' instead, and then make a new top level 'Mesh' object that is itself an ArrayList of SubMesh objects. It makes sense for each SubMesh to own the one material they are going to draw with anyway, since that seems like a 1:1 mapping.

Then the GLTF loading could pull each SubMesh + Material out of the file, and drawing the Mesh would be as easy as drawing each SubMesh individually with the same shared draw matrices.

One thing I didn't notice when I read this is that the SubMesh deals with many materials, not only one. Other than that is all good.

"meshes":[
		{
			"name":"gp_2024_sf24evo_lod_c",
			"primitives":[
				{
					"attributes":{
						"POSITION":0,
						"NORMAL":1,
						"TEXCOORD_0":2
					},
					"indices":3,
					"material":0
				},
				{
					"attributes":{
						"POSITION":4,
						"NORMAL":5,
						"TEXCOORD_0":6
					},
					"indices":7,
					"material":1
				},
			]
		},
		{
                   ...
                 }
]
		

That is a partial example of a gltf file where the first mesh (for us the first SubMesh) has many materials through primitives

[Interrupt]

I've come around on this, I think keeping Mesh as-is could be fine, and then we could add a new Model like you suggested that is just a collection of Mesh instances to render.