Unity compatible per-material render order support

[0b5vr]

Already discussed a bit on #14415

We already have renderOrder for meshes and groups,
but not for materials, which is supported by Unity (as renderQueue).
It would help sorting rendering order of multi-material meshes in certain condition.

I have no idea how much the idea makes good impact for us but I need this at least (🙄),
Since I have to display Unity-compatible stuff (I mean, VRM) on https://hub.vroid.com ...

demo below
https://codepen.io/FMS-Cat/pen/pYBwzw

[Mugen87]

If I understand your pen correctly, you can only achieve your intended visual result right now if you split up the geometry into two, create two meshes, apply different materials and then use Object3D.renderOrder, correct?

[0b5vr]

Yes, and that's why I said I don't know how the idea help us.
I don't think merging two or more meshes into one geometry makes us happy in this situation.

Plus, we currently don't have scene description format that describes rendering order of submeshes or materials
(other than VRM, which is unpolished and still wip).

I think the change doesn't cause large impact on both codebase and performance though,
and might help some niche cases (like us 🙄).

[0b5vr]

Actual our case in VRoid Hub can be seen on the slide below (Japanese 🙇):

https://speakerdeck.com/fms_cat/webshi-jie-tejun-false3dmoterunisheng-wochui-kiip-mufang-fa?slide=42

We currently are addressing the issue by replacing the WebGLRenderLists for our own one.

[donmccurdy]

It would help sorting rendering order of multi-material meshes in certain condition.

Note that in upcoming r103, GLTFLoader will no longer create multi-material meshes. If it's still a dependency of VRMLoader that may affect this issue.

[0b5vr]

in upcoming r103, GLTFLoader will no longer create multi-material meshes

#15889

What, I didn't know that!

The PR sounds like we should avoid to use the multi-material meshes...?

[donmccurdy]

All glTF files that worked before should still work— each primitive (or material) in a glTF mesh will now become a separate threejs Mesh when loaded.

[0b5vr]

Yes I acknowledged that, and then I no longer need the feature request anymore 😅

Separating into meshes affects to performance though (at bone update section),
so I might rather use previous merging method anyway.

Plus, since VRM have renderQueue information for materials
then if we can have renderOrder property for materials it still would be more clean and cool.

[Mugen87]

Just to clarify: Material.renderOrder is useful for sorting the render order of render items derived from a multi material mesh. If you just have meshes with one material, you could put the information from your render queue directly to Mesh.renderOrder, right?

[WestLangley]

Just to clarify: Material.renderOrder is useful for sorting the render order of render items derived from a multi material mesh.

Maybe instead of hardwiring in the renderer:

groupOrder = object.renderOrder;

Maybe we should do this:

addGroup: function ( start, count, materialIndex, groupOrder ) {

	this.groups.push( {

		start: start,
		count: count,
		materialIndex: materialIndex !== undefined ? materialIndex : 0,
		groupOrder: groupOrder !== undefined ? groupOrder : 0

	} );

},

It's the object that needs to be sorted, not the material.

[Mugen87]

I think it's important not to mix THREE.Group and BufferGeometry.groups. The first code snippet from projectObject() is for the case you assign a render order to an instance of THREE.Group. This enables nested sorting in the scene graph via Object3D.renderOrder. BufferGeometry.groups is only relevant for multi material objects. The derived render items can't be sorted right now via Object3D.renderOrder and I guess that is @fms-cat problem. I would not change the semantics of groupOrder but rather introduce Material.renderOrder.

[WestLangley]

OK.

But still, objects can share materials. Material.renderOrder does not make sense to me. We render and sort renderable objects, not materials.