Jump to content
  • Advertisement
Sign in to follow this  
KaiserJohan

Recomputing AABBs for animated actors

This topic is 1087 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm using assimp and it's convention of dealing with nodes and meshes. Basically each model has a node, which can have any number of children and so on, and each node may or may not have a mesh.

 

I go through the node and mesh hierarchy and compute AABB around the entire model and for each node aswell for fine-grained culling. These AABBs are used for view frustum culling later. This works fine when the models are static and not animated as I could just compute it once and forget it.

 

Now when doing animations where some rotation/translation is applied to some or all nodes in the model the whole AABB is invalidated. The only solution I see is to recalculate the entire AABB structure each frame which seems very expensive - say in a model with 100 nodes, which is not uncommon, apply rotation/translation to each node just to recalculate the AABB. 

 

It sounds helluva expensive to do this every frame. Is there anything I am missing? How is this usually handled in other games and engines?

 

 

Share this post


Link to post
Share on other sites
Advertisement
Precomputing the bounds of each bone, and then applying the bone transforms to that data to get per-frame animated bounds, is pretty standard AFAIK.

I recently shipped a game that dynamically computed the precise post-animation AABB's per frame from scratch, which requires applying the bone transforms to all 10k+ vertices per model (on the CPU)... With a few dozen characters on screen, that's around a quarter million vertices per frame :O

As with any large batch processing problem:
* pay attention to data layouts and access patterns.
* use SIMD if you can.
* parallelise it by giving a subset of the data to each CPU core.

Share this post


Link to post
Share on other sites
Precomputing the bounds of each bone, and then applying the bone transforms to that data to get per-frame animated bounds, is pretty standard AFAIK.

It's the common method but a lot of engine also support (or only support) fixed AABB to avoid to compute that each time for each animated actors because it cost a lot.

Animation is one of the heaviest thing in a real time application, one little optimisation here gives lot of win of performance.

Edited by Alundra

Share this post


Link to post
Share on other sites

Precomputing the bounds of each bone, and then applying the bone transforms to that data to get per-frame animated bounds, is pretty standard AFAIK.

I recently shipped a game that dynamically computed the precise post-animation AABB's per frame from scratch, which requires applying the bone transforms to all 10k+ vertices per model (on the CPU)... With a few dozen characters on screen, that's around a quarter million vertices per frame ohmy.png

As with any large batch processing problem:
* pay attention to data layouts and access patterns.
* use SIMD if you can.
* parallelise it by giving a subset of the data to each CPU core.

 

Can you give some details why you needed such precise AABB's?

Share this post


Link to post
Share on other sites

 

Precomputing the bounds of each bone, and then applying the bone transforms to that data to get per-frame animated bounds, is pretty standard AFAIK.

It's the common method but a lot of engine also support (or only support) fixed AABB to avoid to compute that each time for each animated actors because it cost a lot.

Animation is one of the heaviest thing in a real time application, one little optimisation here gives lot of win of performance.

 

 

So you use the fixed/"bind"-pose AABB for frustum culling? Won't that cause pop-in say if the animation stretches a characters arm but your AABB is for the bind pose where the arm is close to the body?

 

Also applying a rotaton/translation matrix to an AABB... returns a valid AABB? Or does it put it in some other space?

Edited by KaiserJohan

Share this post


Link to post
Share on other sites

Can you give some details why you needed such precise AABB's?

We didn't need them, but we were already sofware skinning so it made sense to gather that extra data for very little extra work :)

Share this post


Link to post
Share on other sites

@Hodgman Why were you software skinning? Shouldn't it be done on the hardware (gpu shader skinning) for realtime applications?

Edited by Pilpel

Share this post


Link to post
Share on other sites

Maybe it could be sufficient for your project to calculate the max AABB once by "playing through" all animations, and then store that AABB? Wouldn't be precise culling, but definitely faster :D

Share this post


Link to post
Share on other sites
So you use the fixed/"bind"-pose AABB for frustum culling? Won't that cause pop-in say if the animation stretches a characters arm but your AABB is for the bind pose where the arm is close to the body?

You set a fixed AABB big enough to handle all situations, it's not needed to be precise.

Also applying a rotaton/translation matrix to an AABB... returns a valid AABB? Or does it put it in some other space?

You transform the 8 corners of the AABB using the world space matrix then you find the new min/max based on these 8 corners.

If you want to avoid this transform calcule you can also set a fixed AABB big enough to handle all rotations.

Maybe it could be sufficient for your project to calculate the max AABB once by "playing through" all animations, and then store that AABB? Wouldn't be precise culling, but definitely faster

It's an option to generate the AABB automatically.

Edited by Alundra

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!