Jun 16, 2010 at 6:12 AM

Hi there, I'm a new user - just downloaded this last week and I am absolutely loving it.  Since then I've been buried in the code base and loving every minute.

So I've been reworking some of my predicate code, but I'm not understanding the usage of AnimationStaticBoundsOffset.  It's an offset to the StaticBounds, right?  If not, then I'm really far off base.  Sor here's my situation...

Using Xna Dude, rescaled to 10%.  His StaticBounds Z coordinates min/max are -0.19/7.25.   This is perfect... it matches the model.  But then I want to fix the bounding box to match the Take 001 animation.  The AnimationStaticBoundsOffset Z (for animation index 0) is min/max -1.24/0.55.  Adding, subtracting or multiplying give wrong bounding box sizes.  What am I missing? 


Jun 16, 2010 at 8:50 PM
Edited Jun 16, 2010 at 8:52 PM

Hi. I'm glad you are enjoying xen

The animation bounds offsets are added to the min/max of the static bounds, weighted by animation. They are used to adjust the box to compensate for how the model is animated. Otherwise it's possible to have the model culled when it's actually visible (The Tiny model, for example, is offset by more than it's own height). For the most part, it is used internally by the animation system.

You add both values to the existing static bounds - ie, min+min, max+max. So if the values are -0.19/7.25 for the static bounds and -1.24/0.55 for the animation bounds, then that means the combined bound is -1.43/7.80, which is slightly bigger.

They are worked out by taking the bounding sphere on each bone, and stepping through each frame of the animation. So they aren't terribly accurate. It would obviously be impractical to fully transform the model for each frame.


As I say, it's taken care of internally for cull tests already. You can see it in Tutorial 28 if you add a cull test visualiser to the main render target:


Bounds with no animation playing (tight bounds around the actual vertex data)


Extended bounds when playing the animation, as you can see, it overestimates due to the large bone bounding spheres - but it'll still produce a correct answer.

Jun 17, 2010 at 12:52 AM

Thank you for the explanation.  That makes sense now.  I was expecting a tighter box like for the static data has.  When I got the extra large bounding box I thought that I was doing something wrong. 

I found that drawing the predicates was taking a lot more time than I would like when using hundreds of animations due to inefficiency in the XNA implementation, so I wanted to reduce the size of the bounding box.  Do you think that it would be feasible to have the content processor calculate each animation's static bounds from the vertex data?

Jun 17, 2010 at 10:11 AM
Edited Jun 17, 2010 at 10:12 AM

You do have to be very careful with occlusion queries. They are generally very heavy objects, so I doubt having more accurate bounds would give you a real advantage here.

While I don't know anything about your game, it may be that something CPU side is required - ie some kind of primitive occlusion testing based on some form of precalculated visibility.

Jun 19, 2010 at 11:43 PM

Just a follow up, if you are looking for the best possible bounds, another option is to use the bone local bounds - and calculate the bounding box at runtime from the animation data itself. (See tut 12 for a starting point)