-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong bounding volume computations for model #12108
Labels
Comments
6 tasks
I started drafting something locally to at least conveniently test this. It's in a rough shape, but I'll dump it here: It's a sandcastle that creates a glTF asset that contains
It creates these assets in-memory, and shows them, together with their bounding sphere. (I mean, their real bounding sphere - not the wrong one that is displayed with The sandcasle (work in progress): |
This was referenced Aug 7, 2024
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This code in
ModelSceneGraph.js
is trying to compute the model bounding volume (modelPositionMin/Max
) from the primitive (primitivePositionMin/Max
). This is done by transforming the min/max of the primitive with the node transforms, and computing the component-wise minimum and maximum from the transformed minimums/maximums.This will yield wrong results in most cases.
A 2D illustration:
The following is an archive that contains two glTF assets, and a Sandcastle for testing this:
Cesium Model Bounding Volume Issue 0001.zip
The glTF assets are visually equal, and similar to the 2D case above:
translated
asset, it is also attached to a node with a translation of -10 along xrotated
asset, it is also attached to a node with a rotation of 180° around the z-axisSo both assets look like this:
And gltf.report prints the proper bounding box for both of them.
The sandcastle loads both models, and prints their bounding sphere information:
The bounding sphere is wrong in the case of the 'rotated' second primitive.
Yeah... the bounding sphere that is shown via
debugShowBoundingVolume
is wrong in both cases ... I'm not sure where this is coming from - and/or whether it should be tracked as its own issue, or whether this issue sufficiently covers that ~"a few things are wrong here...".Possible solutions:
There are at least three possible ways of improving this:
1. Simple but probably bad
One could compute the model minimum/maximum with
This should fix it for the overly narrow test case here. But this could also have corner cases (no pun intended) with rotations about 45° and non-uniform scaling and such.
2. Still simple, and probably OK
One could compute the bounding box from the transformed corner points of the primitive bounding box. So for each primitive, its min/max (as taken from the
POSITIONS
accessor) are converted into an oriented bounding box. This oriented bounding box is transformed with the node transform. The (corners of) the transformed bounding box are used for computing the min/max for the whole model.3. Most precise
All vertex positions from the
POSITIONS
attribute are transformed with the node transform, and the bounding volume of the whole model is computed from these transformed vertex positions.This is likely prohibitively expensive for larger models (not to mention having to ~"keep stuff on the CPU" and whatnot).
All this is still not taking into account skinning, animations, morphing, or instancing. The latter is what I actually tried to address via #12105 , and where me wondering why I wasn't able to compute "the right" bounding volumes led me to this issue...
The text was updated successfully, but these errors were encountered: