Bounds should be automatically computed for animated model

[hybridherbst]

Description

This is kind of a follow-up to #907. The model in this report has a very large bound when animated and much smaller on the first frame, and thus clips out of camera far plane (besides very clearly showing an abandoned shadow on the floor, which #513 will hopefully fix).

Adjusting camera orbit does not work since it seems to be clamped to a maximum (can't zoom out further than initial bounds) - note setting the camera orbit distance higher does not change the view in the example.

Live Demo

https://glitch.com/edit/#!/sleet-kookaburra - first model, the shark.

Browser Affected

all

OS

all

Versions

latest

[elalish]

@soraryu I believe this is fixed by #915, so please take another look at either master or 0.8 when that is released (very soon). If it still repros, let us know here and I'll take a look.

[hybridherbst]

Works better in terms of bounds (I updated the above link with latest master), however it seems there's no more camera smoothing and shadow is broken.
Please see #513 (comment)

[elalish]

@soraryu Thanks for the feedback! If #935 doesn't fix the remaining issue, please let us know. As for the original issue, of the animated model leaving its bounds, yes that's a thing, unfortunately. There's relatively little I can do about it, as it's too expensive to update the bounds every frame during animation, so it's possible for the shadow to leave its shadow plane and for the model to leave the clipping volume. The best I can recommend is putting a little bit of invisible geometry into the scene (maybe a transparent texture or something) that can represent the static bounds you want to contain the animation. I'm also talking to the glTF group about making an extension to improve this.

[hybridherbst]

Yup, I agree it's not simple and the new behaviour (with actually configurable bounds) is already much better / allows this type of models to work.

Any ideas about the shadow? Is that only visible in the area below the first-frame-bounds?

[elalish]

@soraryu Yes, we made it arbitrarily 3x larger than the resting bounds for animated models, but obviously this only works sometimes. We could look at this issue as a feature request to override the automatic model bounds computation. Would it be adequate to specify an attribute with say, a height and radius of a framing cylinder for your scene? Then we can ensure the shadow and culling planes are the right size (and skip some computation).

[hybridherbst]

OK, did some more tests around that.
If you look at https://glitch.com/edit/#!/sleet-kookaburra again, there's now a couple more versions:

1. With visible corner points
   This loses shadow completely somehow.

2. With disabled corner points
   This has the shadow centered again (on a small square near the starting point). I think it's the correct behaviour that disabled objects don't influence the bounds calculation.

3. With corner points scaled to zero
   This shows a (very faint, very pixelated) shadow below the shark.

I think if it's properly documented (3) is an appropriate solution for this type of larger-than-original-bounds animation, which I can see is not the "usual" usecase. I still think ideally there would be an option to calculate AABB bounds from animated transforms - guess that also depends on who your target audience for model-viewer is (like, is it a "drop any model and it works" viewer?)

[cdata]

@soraryu it seems like the challenge of computing the bounds from the animation is that you essentially have to play through the animation ahead of time. I'm not saying we can't do this, but depending on the animation and the complexity of the model this may not yield the best UX.

We have speculated about possibly playing through the animation over a coarse interval so that we only check a handful of frames regardless of animation length. But, this isn't guaranteed to give us a satisfying result, and you may still want to manually specify the bounds.