Jump to content
  • Advertisement
Sign in to follow this  
poigwym

need a algorithm to update skin mesh global AABB

This topic is 800 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

Hellow !!!!

I 'm writing animation system for games..... and I know a wrong AABB for skin mesh will cause Frustum culling mistake, because AABB must 

bigger than actual mesh size.

It's impossible to calculate global position of vertices of skined mesh using the bone matrices and then use the vertices to calculate the global AABB .Is there someone   know any effective algorithm  to get a approximate result  ?

By the way,  the animation system is run inside the scene graph(model, joint, mesh are made as nodes), and the  update  AABB  function will be called after global transform matrix  has been updated .

However I don't actually use the global transform to render the skin mesh,  the formula of computing the BoneFinalMat

is initially be : BoneFinalMat = inverseBindMat * BoneToRoot * RootToMeshNode.  and somebody(not me) should pass the global transform    matrix  of mesh node to shader.   But I slim down the formula to BoneFinalMat = inverseBindMat * BoneToRoot,  so I just pass a Identity matrix as the world matrix to shader.  

Maybe I need a algorithm to compute the global AABB of skin mesh that  would have nothing to do with the global transform of mesh node.

Edited by poigwym

Share this post


Link to post
Share on other sites
Advertisement

Usually the artists also define a worst-case AABB which gets exported with the model. This AABB would fully contain the model in every possible pose. You really don't want to update the AABB at runtime.

Share this post


Link to post
Share on other sites

A more accurate but still fast method is to have a bounding capsule for each skeleton bone, and per frame calculate bounding box from all capsules.

Fast if the CPU already knows bone transforms, nearly as good as doing per vertex and worth for near / expensive characters.

Share this post


Link to post
Share on other sites

Dirk's suggestion is probably the most common solution and JoeJ's would be effective.  But, if you have need of tighter bounds the manner I've always used is to simply compute the bounds into the animation itself at point of export.  It's the same cost as computing an extra joint and you can get accurate bounds.  If you are doing blending, you simply take the max bounds of all running animations.  It is not quite as performant as a single unified bounds but it is better than the capsule method since you have no traversal involved, but it is not as tight when using blended animations.

 

At this point, the suggestions should solve whatever you are looking for.  The benefits/detriments are:

 

Unified bounds:  No computation overhead.  Sloppy so often animating even if not in view.

Capsules: Relatively tight bounds.  Requires a hierarchical traversal, can cause cache issues if you have lots of characters.

Animation driven: Perfect for single animation, not as tight as capsules when blending animations, but tighter than unified.  Cost is the same as an additional bone in the skeleton and costs no traversal.

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!