Skeleton representation

Started by
3 comments, last by 3DModelerMan 9 years, 10 months ago

I'm working on a skeletal animation and skinning system for my engine and I'm trying to decide what the best way to store the skeleton would be. I already have a hierarchical game object system that can be set to play an animation clip by attaching a component to it. I plan on having attachment support for my skeletal animation (attaching guns, swords, etc as children of a specific bone). Would it be a bad idea to use the existing hierarchical object system as my skeleton? I would just load each bone as a child object, and that would allow me to attach any sort of component I wanted to each bone later, or add child objects to them. Would there be any problems with this approach, other than the fact that the bone hierarchy would need to be traversed at the beginning of each frame to generate a new set of matrices for use by the vertex shader in skinning?

Advertisement

Would there be any problems with this approach, other than the fact that the bone hierarchy would need to be traversed at the beginning of each frame to generate a new set of matrices for use by the vertex shader in skinning?

Assuming you're talking about an animated object, you don't mention how you would render it without updating the matrices each frame. The common method of rendering a hierarchical animated skinned object calculates the animation matrices each frame in any case. Adding a couple of extra calculations per frame shouldn't be a burden. However, in such a case, if you add-remove attachments dynamically (at run-time), that complicates things quite a bit, depending on your implementation. Commonly, for efficiency, the animated mesh (without attachments) is a single vertex/index buffer. If you have a separate mesh for each arm, each leg, etc., your method should work, but would be rather inefficient.

More commonly, attachments are separate meshes (separate vertex/index buffers) and are rendered separately, as desired. You can set a flag for each attachment to indicate whether it should be rendered or not.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Okay, so it's basically the same thing as a normal system performance wise then. I don't think the attachments would need to cause an update at runtime if they didn't affect the transform for current frame would they? Or are you talking about how the bone indices are assigned to the matrix array?

Okay, so it's basically the same thing as a normal system performance wise then. I don't think the attachments would need to cause an update at runtime if they didn't affect the transform for current frame would they? Or are you talking about how the bone indices are assigned to the matrix array?

If rendering an attachment doesn't require a change in the frame transforms array, you're correct - no problem. Without details of your implementation, I had to generalize.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Okay. Thanks for the help.

This topic is closed to new replies.

Advertisement