Sorting problem in mupltipart transparent object

[matios13]

Description

We have created a 3d model of glasses for one of our client, and it's not rendering properly in model-viewer. We have created 2 different colours that you can find in a live demo.

Problems:

Model nr 1. - Red - build from multiple transparent and multiple non-transparent parts.

As you can see it looks like glasses temple is in front of lenses.

Model nr 2. - Red - build from one transparent and one non-transparent parts. We have done it by combining all parts from model nr 1.

The front is better, but from site, it looks odd

Model nr 3. - Blue - multiple parts.

Seems like it works better for that colour but glasses temple colour is not blending properly with blue lenses, you can see how it should look like on right lense in model 4.

Model nr 4. - Blue - multiple parts. - moved one temple .

Here you can see that on the right-hand size temple is slightly darker I have achieved that by moving the temple slightly back, not it seems to blend properly on front but not on that site and only at some camera angles:

depthWrite?

I have also played with depthWrite and it seems that model 2 rendered properly with depthwrite=true for transparent objects. That line https://github.com/google/model-viewer/blob/806d708ddd73530fadfbf64675306eae5c0a2e4e/packages/model-viewer/src/three-components/gltf-instance/ModelViewerGLTFInstance.ts#L193 Obviously, that's not the solution.

Live Demo

https://hrgo-conference.s3.eu-west-2.amazonaws.com/demo/folder/Problem.html

Version

• model-viewer: v1.2.1

Browser Affected

• [x] Chrome
• [x] Edge
• [x] Firefox
• [x] IE
• [x] Safari

OS

• [x] Android
• [x] iOS
• [x] Linux
• [x] MacOS
• [x] Windows

[elalish]

Let me start by saying, transparency is currently a bit of a hack in glTF anyway (there is a transmission extension just getting ratified, but it'll take a little time to get proper support). However, I believe the problem you're having is different. Most renderers, including ours, rely on sorting to get transparency to work properly and fast. We can do it correctly for convex objects, but there will inevitably be errors with concave objects. You can work around this by splitting your transparent mesh into multiple objects that are each relatively close to being convex. You'll also want to split your transparent and opaque objects into separate meshes that have BLEND and OPAQUE alpha blend modes respectively. Hopefully splitting the earpieces from the frames will be enough.

[matios13]

Thanks for response @elalish unfortunately in model 1 and 3 we have 3d model split into multiple objects:

• frames
• lenses
• earpieces
• metal parts And it looks even worst than model 2. We have also have split opaque and transparent objects into two meshes in all of those 3 models

[elalish]

Okay, I see the problems a little clear now; thank you for the very nice demo site. To me #3 looks the best; I can't see the blending error you're talking about. #1 is clearly terrible; what is the difference between #1 and #3 besides color? The problem with #2 makes sense given what I said above.

[matios13]

Hi @elalish hmm we moved temples a little bit (millimeter or something like that). It works ok but if you have black lenses it stops being perfect. Our solution for now was to create 3d model as only two meshes first for transparent , second for opaque (excample #2) and then we have modified model-viewer code: https://github.com/google/model-viewer/blob/806d708ddd73530fadfbf64675306eae5c0a2e4e/packages/model-viewer/src/three-components/gltf-instance/ModelViewerGLTFInstance.ts#L193 so depthWrite for transparent objects is not false but driven by additional argument.

[elalish]

Thanks, I know there was a long debate about this internally in three.js. I'll keep an eye on it and see if there's anything we can do to get better default behavior. Good workaround meanwhile.

[manuvlad]

Hey. I'm having a similar issue. If you look at the render from substance, everything looks fine. So, I exported using the gLTF preset in substance. But when I load the glb file on the viewer, the metal part that is occluded from the temple tips and nose nods shows 100% black. Temple tips, nose nods, and lenses ... each one of them has its own mesh. In substance, I created a PBR metal roughness shader, with an instance shader that I set up as a PBR metal roughness with alpha blend. So, the project has 2 textures sets (one PBR metal roughness to the metal frame, and other PBR metal roughness with alpha blend to the opacity mesh). Can anyone has any clue about how can I solve this?

substance render: https://imgur.com/cSUTRCD

viewer realtime render: https://imgur.com/X1gAyqf

Thank you.

[elalish]

@manuvlad I'm actually pretty impressed with how good that looks given the difficulties of transparency. Agreed the black bits look wrong; have you tried in any other realtime renderers? For instance, is it the same in https://gltf-viewer.donmccurdy.com/? You might also try the Babylon sandbox and the scene-viewer preview: https://arvr.google.com/scene-viewer-preview

These are all different renderers, so if we're the odd one out, then it's our bug. If they're consistent, then it's likely a glTF export bug in Substance.

[manuvlad]

Yeah... same error on both viewers:

Babylon: https://imgur.com/lkmHwDY

gLTF Viewer: https://imgur.com/knfYYiz

[manuvlad]

As you can see it looks like glasses temple is in front of lenses.

@matios13 I had a similar problem that was solved by separating the opaque shader from the transparent one in substance painter. I created 2 texture sets, one for the opaque material and the for the transparent one. The second one a switched from PBR metal roughness to PBR metal roughness with alpha blend.

[manuvlad]

@elalish Do you think that would make any difference if I export to 3DS Max (physical material) and use the babylon plug-in to export to glp?

[elalish]

@manuvlad I honestly have no idea. Certainly worth a shot. All these exporters are relatively new and need lots of bugs filed against them before they'll really get reliable.

[manuvlad]

Okay... thank you... I'll give it a try

[manuvlad]

I solved the problem. It was the AO map. Always the AO. I had tried to delete the AO from the substance painter project, I put an ALL Black AO Map. What solved the problem though was to use an All White AO map.

https://imgur.com/VMubQjK

[elalish]

Ah yes, we've seen this before! Please give this feedback to substance; an all black AO map is never physically realistic, so they certainly shouldn't default it that way, and should probably put up a warning before export.

[manuvlad]

In the end, I was just trying everything :) Thanks, man. I'll do that.