Triangles culled based on viewport situation

What is happening After compressing a .glb-file with gltf-transform meshopt and loading it into my Unity-project, some of the faces are culled unless I look at them from a very steep angle. I am specifically not looking at a flipped normal issue here, as I am not moving to the front or behind the triangles in question when they disappear or reappear respectively.

For a life example please refer to the attached GIF:

To Reproduce Steps to reproduce the behavior:

1. download the file CUBE-1.0.8.1.glb from Google Drive
2. Compress them via the command line interface using `gltfpack -i CUBE-1.0.8.1.glb -o CUBE-1.0.8.1.gltfpack.glb
3. Load the resulting file into Unity at runtime via gltfast package, specifically GltfAsset.cs
4. See error

Expected behavior I expected to see the compressed model with slight loss of positional information.

Versions:

• UnityVersion: [2020.3.21f1]
• gltfastVersion: [4.4.5]

Additional context I couldn’t verify the problem in the babylonjs.sandbox (file is shown as expected), when trying to confirm via Gestaltor the file couldn’t be loaded due to unsupported filename extension. Other .glb files of varying compressions were loaded just fine, so I assume the problem doesn’t lie in the Gltfast-package. I am using multiple materials on the same mesh and the culling seems to occur along the submesh-borders. I verified the normal orientation before the export, but as of right now I cannot

[donmccurdy]

#414 will be fixed on next release, and it looks like the glTFast author has fixed the remaining issue. I’ll close this out, but let me know if there’s anything I’ve missed!

[donmccurdy]

#(a) produces an error (“n.pattern.test is not a function”) when used on its own

Hm I haven’t been able to reproduce that with the earlier GLB – this is a recent version of gltf-transform? And using the CLI, or a script? I tried running (a) myself, and got the output below – could you check if this still has problems in glTFast? The model is quantized (the first step of meshopt compression) but not otherwise compressed.

https://drive.google.com/file/d/1NXNXJsYN-dEwgtlBboGOo5BM1Hrv9cJo/view?usp=sharing

Also they continue to throw the Normalized-Positions-Exception

Ok, thanks – the output of a/b/c does pass the official validator (quick test: gltf-transform validate input.glb) for me. The validator can’t read vertex data using meshopt compression, so that doesn’t tell us the whole story, but I think it’s likely the files are valid other than the issue in #414, which affects only ©.