Editor: Selection box should reflect current animation state

[WREQI]

The parameterized model created by blender, the bounding box calculated by the box after the import is the largest, and does not surround the actual model size
Breaker_NM1630S.glb.zip

[donmccurdy]

Could you share a model so that we can reproduce this?

You can drag .ZIP files into GitHub comments.

[WREQI]

I uploaded this model, sorry, I accidentally closed the comment, thank you

[Mugen87]

It seems the bigger AABB is related to: #17940

R111:

R110:

So in some sense, it's the expected behavior.

[WREQI]

This is a parametric model. The bounding box obtained after the model deformation is still incorrect.Tested with version 110

[zeux]

Note that in r110, morph targets weren’t included into the bounding box calculation at all in expandByObject, so the result could be too small.

r111 computes the conservative maximum that takes into account all targets with assumed boundary weights of +-1. The result could be too large if the required weight ranges are smaller.

Neither r110 nor r111 has a way to compute a precise bounding box using currently assigned morph weights.

[donmccurdy]

Our definitions of "incorrect" and "too small" here depend on some assumptions of what the bounding box is being used for... for culling and raycasting, a conservative maximum accounting for skinning and morph targets is a good thing. For UI manipulation in the editor, a snapshot of the objects bounds now is probably what users expect.

I think the changes in #17940 are right, and a conservative geometry.boundingBox is best for internal usage like culling and raycasting. Perhaps this should be considered a feature request for the Editor, to use a tighter bounding box for the UI?

Alternatively, I could imagine having an API that lets users access an approximate bounding box for an object given the current frame without iterating over all vertices for that frame, based on cached min/max values on BufferAttribute properties and some special handling for Skeletons. But that's not the API we have currently, and I don't know how many applications would practically need that.

[zeux]

Just to clarify that #17940 is not at fault; before that change the bounding box was computed irrespective of morph targets,

What is causing this is that in this model, the morph targets are used for major changes to the model's size; the bounding box is computed assuming worst case parameters L & W & H (1), but of course if you set them to their initial values (0), the object is much smaller.

L&W&H = 0:

Before #17940, the bounding box was always equal to the extents of this object, even if L/W/H were larger.

L&W&H = 1:

After #17940, the bounding box is now always equal to the extents of this object, even if L/W/H are smaller.

So I believe that now the behavior in three.js is actually as intended, and returning the bounding box that can be used for culling. The previous behavior seems strictly worse.

The only way to achieve "intuitive" behavior for editor here is to implement a feature that computes a precise bounding box that takes into account all morph targets (and probably skinning transformation?).

[donmccurdy]

Not suggesting any problem with #17940, but I think the OP was expecting a bounding box that ignored the presence of morph targets entirely... The three.js Editor doesn't support direct manipulation of morph targets, although you can play/pause animations that could affect them.

[zeux]

I guess, although since GLTF files can specify arbitrary starting values for morph weights, ignoring morph targets seems wrong even for the existing editor.

[donmccurdy]

The Editor is using BoxHelper, rather than displaying geometry.boundingBox directly. I think it would be appropriate for BoxHelper to use the current frame's bounding box rather than the more conservative box used in the renderer — it already has an .update() method that we expect users to call when the content changes.

[WREQI]

I guess, although since GLTF files can specify arbitrary starting values for morph weights, ignoring morph targets seems wrong even for the existing editor.

Not only the bounding box is correct, but also the center coordinates of some objects are incorrectly obtained after deformation.The central bid of the child object obtained by updateMatrixWorld(true),getWorldPosition has not changed

[donmccurdy]

@WREQI The box you see is accounting for all possible deformations of the morph targets on the mesh. So the box may look much larger than the shape you see on screen, and the center may be off. I've updated the issue's title to clarify this.