glTF renders incorrectly, but correct in McCurdy viewer

[tsgouros]

Can anyone help me debug a glTF file? It looks ok in Don McCurdy's glTF viewer at https://gltf-viewer.donmccurdy.com/ (though it's pretty different from how it looks in Blender) but most of its pieces are missing when I use aframe to look at it: https://sgouros.com/scorpii/index1.html.

Two of the meshes are visible, but something has happened to the other dozen meshes. I'm not sure if this is a support question or a complaint about the glTF display feature of aframe, so I've posted it here as well as at SO: https://stackoverflow.com/questions/59852899/gltf-file-renders-incorrectly-in-aframe

The model is at https://sgouros.com/scorpii/data/scorpii3.glb, but it looks like this in the McCurdy viewer:

Displayed like this:

    <a-scene id="mainScene"
             background="color: #666666"
             renderer="antialias: true;
                       colorManagement: false;
                       logarithmicDepthBuffer: true;"
             environment>
      <a-assets timeout="20000">
        <a-asset-item id="uscorpii"
                      src="data/uscorpii2.glb"
                      crossorigin="anonymous">
        </a-asset-item>
   ...
     <a-entity gltf-model="#uscorpii"
                scale="1 1 1"
                position="0 0 -15"
                animation="property: object3D.rotation.y;
                           to: 360; loop: true;
                           easing: linear; dur: 136000">
  

• A-Frame Version: 1.0.3
• Platform / Device: Firefox, Chrome
• Reproducible Code Snippet or URL: See links above

[tsgouros]

Result looks like this in aframe:

Thank you. I'm afraid I really don't know what to try at this point, but it seems very mysterious that this doesn't just work.

[arpu]

what is if you set the colorManagement to true?

[tsgouros]

Just changed it. No apparent difference. I admit that I don't know what that option does. (I had been having trouble getting colors to match from my work in Blender and found that suggestion in another thread here. Now the colors seem to match but lots of the model is missing.)

[dmarcos]

@donmccurdy anything top of mind?

[donmccurdy]

This model requires depthWrite=false on any transparent materials. A quick patch would be:

model.traverse((o) => {
  if (o.isMesh) o.material.depthWrite = !o.material.transparent;
});

I've implemented that in my viewer, and proposed a fix for threejs (mrdoob/three.js#18235) but the threejs version has not been merged yet. This could be done in a custom component, in the meantime.

[tsgouros]

Thank you. That sounds like it's possibly within my ken. Can I ask, though, what it is about the model that requires this? Did I do something crazy in Blender that I should not have done? I can always go back and fix it. Maybe.

[tsgouros]

@donmccurdy I have other models with transparent materials that display without trouble. Do you know what I did wrong when preparing this one?

[donmccurdy]

The model is difficult to render correctly in realtime engines, and somewhat up to "luck" as a result, because it contains transparent objects nested inside of other transparent objects. A single layer (i.e. an opaque object inside a transparent one) is usually OK, but layered transparency is more difficult. Even Blender shows some artifacts (black triangles) when you switch into Eevee rendering mode, for me.

The fix suggested above — setting depthWrite=false for transparent materials — is unfortunately not something you can do to the model itself, it requires configuration after the file is loaded. I'm proposing that should be the default in threejs, because most transparent models benefit from it, but there are certain cases in transparency where you would not want the setting, too.

[tsgouros]

Ok, I get it. Many thanks.

[dmarcos]

@donmccurdy Thanks for clarifying. Much appreciated as always.