Bounding box for quantized models computed incorrectly?

[donmccurdy]

Description

In three.js r128 a fix was added to compute the correct bounding boxes for quantized models (mrdoob/three.js#21554). That fix is working in my viewer now (https://gltf-viewer.donmccurdy.com/) but for some reason the latest version of model-viewer still does not center models using quantized position attributes.

The effect of the incorrect bounding box is that the model is not visible at all.

Live Demo

export-v1.glb.zip

Compare:

• https://modelviewer.dev/editor/ (nothing shown)
• https://gltf-viewer.donmccurdy.com/ (correct)
• https://sandbox.babylonjs.com/ (correct)

Version

• model-viewer: v1.7.2

[ghost]

Yup, thanks for report looking into it

…

On Wed, Jun 2, 2021 at 8:38 AM Don McCurdy ***@***.***> wrote: Description In three.js r128 a fix was added to compute the correct bounding boxes for quantized models (mrdoob/three.js#21554 <mrdoob/three.js#21554>). That fix is working in my viewer now (https://gltf-viewer.donmccurdy.com/) but for some reason the latest version of model-viewer still does not center models using quantized position attributes. The effect of the incorrect bounding box is that the model is not visible at all. Live Demo export-v1.glb.zip <https://github.com/google/model-viewer/files/6585763/export-v1.glb.zip> Compare: - https://modelviewer.dev/editor/ (nothing shown) - https://gltf-viewer.donmccurdy.com/ (correct) - https://sandbox.babylonjs.com/ (correct) Version - model-viewer: v1.7.2 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2450>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZY3MUY5W3GZXQD3FHWXJ3TQZF7TANCNFSM4567ZTTQ> .

[donmccurdy]

I'm seeing a very similar issue with models using skinning:

Archive.zip

The archive has a .base.glb and .quantize-hi.glb version, the latter is quantized. The quantization transform is applied to the skinned mesh's inverse bind matrices, so the root cause here is probably mrdoob/three.js#14499 if you're using three.js' new Box3().setFromObject(...) ... if model-viewer uses some other method to compute the bounding box, it may be worth looking into including inverse bind matrices in that.

original	quantized

[elalish]

In fact we do use our own function: https://github.com/google/model-viewer/blob/master/packages/model-viewer/src/three-components/ModelUtils.ts#L60, so that we can also compute a bounding frustum. I've been meaning to contribute this back to three.js, but haven't gotten around to it. Do you have any thoughts on the right way to fix this?

[elalish]

@donmccurdy So, we recently fixed the issue with skinned meshes and their bind poses and your original model works just fine, but both of your CesiumMan models in your zip still fail. I don't really understand why: even without quantization, I'm getting bone transforms with huge weights (like 22) that send the vertices way off and I end up with a bounding box hundreds of meters on a side. I'm trying to upstream my bounding function (since three.js doesn't have a good way to calculate skinned mesh bounds at all right now), but I'd like to make sure I'm doing it right.

I'm also curious if the quantization scaling should be applied before or after the bone transforms? I can't check with these models, because they don't work even when the scale is 1.

[elalish]

@donmccurdy Upon further inspection, it appears your version of CesiumMan is an invalid glTF (since fixed in the repo), as it has bone weights of x: 44, y: 164, z: 34, w: 13, which certainly don't sum to 1: KhronosGroup/glTF#1352

Interestingly, it also doesn't fail the validator. On the other hand, it seems three.js normalizes the weights in its shaders, but not in its CPU code, hence the bug. Perhaps that should be fixed regardless?

[elalish]

This is mostly fixed and we have some similar open issues anyway.