Half-transparent materials sometimes render items in the wrong z-Order

[Bersaelor]

Description

When opening a material that has alpha = 0.9, the objects behind the material are sometimes visible 10% and sometimes seem to be sitting in front of the object. (Left temple is barely visible behind the front, right temple seems to be in front of the front plastic piece).

Example:

Live Demo

Try dragging the following model into any model-viewer example online:
https://render.looc.io/loocfun/domvetro/f34/1643214334091/f34-1643214334091.glb

Version

• model-viewer: v1.7.2

Browser Affected

• Chrome, version: xx.x.xxxx.xx
• Edge
• Firefox
• IE
• Safari

OS

• Android
• iOS
• Linux
• MacOS
• Windows

[elalish]

This is a classic case of bad render ordering of transparent materials. Usually it can be overcome by splitting the mesh into multiple pieces (to make them closer to convex). Are the earpieces separate meshes from the frame? That should fix it; if you've already done that, let us know, because that may be a more serious bug.

[Bersaelor]

@elalish thank you for your answer!

The linked object above is actually made of several meshes, it has a detailed node structure so we can open and close the temples/earpieces and change materials for the metal and plastic parts separately.

You can check it by downloading the linked *.glb and dragging it into https://sandbox.babylonjs.com where they have a nice object graph

[elalish]

@mrdoob This model is having some major transparency ordering problems even in the three.js editor. It looks like everything's been done right as best I can tell. Do you have any idea why it's not sorting properly? I know we've been messing around with transparency a bit lately and this looks like a regression.

[mrdoob]

I know we've been messing around with transparency a bit lately and this looks like a regression.

A regression is only when something used to render well before... 😛

It's because of mrdoob/three.js#18235 and you can see the same artifacts in babylon.js' viewer.

The way to solve this is by making sure the geometries have the origin at the center.

For the front part the origin is behind:

And for the side parts the origin is at the front:

1. Move the vertices of all the meshes so the origin is at the center of the geometry.

I understand the reason the origins are where they are is for animation purposes but you can achieve the same result by

2. Add the mesh as a child of an empty/group
3. Offset the child so the center is where you want
4. Animate the parent instead.

[mrdoob]

Maybe three.js could sort meshes by the bounding box/sphere center instead of the the origin of the 3d model, but I worry there may be cases the opposite of this one where the solution is to move the origin away from the center...

[Bersaelor]

Maybe three.js could sort meshes by the bounding box/sphere center instead of the the origin of the 3d model, but I worry there may be cases the opposite of this one where the solution is to move the origin away from the center...

Yeah, technically a client may set origins of meshes wherever they want.

I can write a script for our models that does your above steps to all our models.

Maybe the fact that modelviewer uses the origins of objects to determine zDepth-Order could be mentioned in the documentation somewhere?

[elalish]

Thanks @mrdoob, this is actually the first I realized this (I honestly thought this was a regression, thanks for the correction). I had assumed it was based on the bounding box. And yes @Bersaelor, some documentation along these lines is probably called for. I don't really have a good place for it right now; really we should have a whole artist tips page probably. It sounds like you have experience in this area; any interest in contributing?

[Bersaelor]

It's because of mrdoob/three.js#18235 and you can see the same artifacts in babylon.js' viewer.

Mhmm, I rechecked in babylon this morning and I can't see to get the same effects no matter which angle I hold the frames. Is it possible they applied a patch that works around this issue recently?

really we should have a whole artist tips page probably. It sounds like you have experience in this area; any interest in contributing?

Alas, I'm not really a 3D content creator, more developer and mostly busy writing our conversion tools and web/mobile/desktop visualization engines.

[mrdoob]

Mhmm, I rechecked in babylon this morning and I can't see to get the same effects no matter which angle I hold the frames. Is it possible they applied a patch that works around this issue recently?

Screen.Recording.2022-02-04.at.11.44.13.AM.mov

[mrdoob]

@donmccurdy Here's another one that I wonder if the GLTF WG has ever talked about...
Are we supposed to sort geometries by their origin? Or by the bounding volume center?

[donmccurdy]

I don't think the GLTF WG will specify that (by specifying, they would be inadvertently prohibiting future techniques like OIT ...) but in my opinion, sorting by the nearest point of the AABB or bounding sphere might be more robust?

^EDIT: Thinking of cases like transparent liquid in a transparent bottle, with the same origin for both.

[elalish]

I believe that's how Filament does it. However, I presume the reason three does not is the same reason I have to disable the bounding boxes entirely for animated models, which is that they are not updated as the animation progresses.

[mrdoob]

I have to disable the bounding boxes entirely for animated models, which is that they are not updated as the animation progresses.

Yes, I still don't know a fast way of updating these per frame.

[donmccurdy]

I don't think lack of per-frame bounding volumes should prevent our using them for sorting. The main problem with the current bounding volumes (as they affect animated models) is not that they aren't updated every frame, but that they don't account for the initial inverse bind matrices. The IBMs commonly have a 100x or 1/100x scale multiplier that affects things more dramatically than the animation itself. I seem to see that most often with models converted from FBX at some point in their authoring pipeline.

[Bersaelor]

@mrdoob sorry for so much confusion here, with regards to your video, I believe that is indeed not the effect I described earlier in this thread. The video you posted has the same (very minor) glitches visible when putting the origins of each mesh into their center of geometry.

Compare the original one with the latest update that has the origins in the centers of the meshes.

The first one looks like in the image at the very start of the thread, the little bit of overlap you showed in the video is much smaller and much more angle-constrained.
The updated model I linked now has all origins at the centers of meshes and still has the same minor glitches as babolyn.js shows for the original file.

So it looks like babylon.js is indeed already using the centers and not the origins, because on babylon both linked models look the same. In. model-viewer only the second one looks like in babylon.js.

[donmccurdy]

For consideration —

• WebGLRenderer: Sort on bounding sphere center, not origin mrdoob/three.js#25913

[elalish]

Awesome, thanks @donmccurdy! I look forward to pulling down that fix.