Hey everyone,
I am trying to compute the full bounding box of a mesh animated by bones.
This will be used in blender importer because if the animation exceeds the initial bounding box of the model then some parts of it (or sometimes the full model) tend to disappear if the bounding volume is not in the view.
Is there a class that can compute the vertices of return a vertex buffer of vertices deformed by the currently set animation frame ?
You mean other than letting the animation actually change them like it normally does? Is there a reason that doesn’t work?
Actually animations doesn’t refresh the bounds
Neither in software of hardware mode
Usually the recommended way is to make an “inplace” animation and move the object with setLocalTranslation()
I think he wants to calculate the bounds for a particular frame which is why he asked about vertices.
Exactly. I need the verts of the deformed mesh.
I hope to compute the bounding box that will enclose the model’s animations.
This way I hope that the model will not disappear.
Ok I’m not sure it’s the best idea. Because you are going to compute the “max” bounding box for the model. IMO it can lead to very weird things depending on what the artist does in its model. Most of the time it will end up in unculled model when it should.
Also if we want to address that issue, we should compute the real bounding box on each frame of the animation. Of course it’s gonna add some overhead on the cpu side…Maybe make it optional so you could switch it up when needed.
@Momoko_Fan what do you think?
Sorry if I am completely out in the woods here. Can this be done with setting the CullHint?
@nehon
The bounding box will be computed during blender file import and not in the runtime, so I think the additional computations will not be a problem.
On the other hand, if the artist creates a model that moves it will almost always exceed its static bounding box. So the model will very often disappear while it shouldn’t - IMHO not very good solution.
I come accross it very often that is why I decided to see into the problem.
@tonihele
I could of course set the animated model’s CullHint to Never - so it won’t disappear. But this is even more inefficient than computing the max bounding box. Because with the box - it will disappear eventually when out of the view.
Actually a middle ground solution could be to compute the exact bounding box for each frame and store it along with the animation. We’d have to add the actual world pos of the model to the center of the bounding box to have the world bounds.This way we’re sure that the bounding box is accurate and we won’t have culling weirdnesses.
An axis aligned bounding box is a vector3f and 3 floats. Not that much more information to store.
Also if this is done it should be something more internal, not only related to the blender loader.
I’d like to hear the opinion of the other core dev about this.
Calculating the bounds is the easy part - the data to do that is already there. You turn on software skinning and then manually call Mesh.updateBound() to get an updated bound. You run it once per keyframe by combining the keyframe times from all of the animation tracks, then you take the max() of all the bounds to get the bound for that animation + mesh pair.
The issue is what to do with the data once you have it. You cannot put it inside the animation object since the bounds vary by mesh, not by animation. The same animation applied to another model will have different bounds. That means you need to somehow store a animation object → bounds mapping inside the mesh somehow. This data mapping should be shared between all instances of the model. You cannot use animation name because you may have two animations with the same name but a different animation.
You also have issues such as animation blending or interpolation, you don’t want to interpolate those bounds so you probably just take the max() of the two.
Basically the challenge is determining a format for the data and storing it, not computing it.
As his original plan… to just calculate the max bounds and use that… I think is a nice and easy compromise. Yes, sometimes the object will not be culled even if it’s slightly off the screen… but apparently up until now we’ve been fine with culling it even when it was on screen so I think it’s a better compromise, personally.
One bounding box to rule them all.
Yeah but basically in some case it could end up in the same result as setting the model to never cull.
I’m afraid it will make people make the model move a lot from their origin within the animation data (like let’s say a forward jump), making a very big bounding box
This brings up an old discussion we had with @normen years ago. Should we update the localTransforms according to the transforms of the root bone.
For me those issues are very related, and doing the later would allow to compute the bounds relatively to the root bone origin and would minimize a lot the “scene wide bounding box” issue.
Well, it would have to be a pretty giant bounding box for it not to be culled if it was 10 meters behind you…
I agree the root translation node issue needs to be dealt with. Maybe that also gives model creators the tool so that walk speed can be properly determined where feet don’t slide on the floor. 