ASSIMP skinned mesh with DX9 problem

Started by
11 comments, last by kalle_h 10 years, 1 month ago

Thanks for your feedback.

You are right that optimizing it right now is definitly not a good thing to do.

I will implement animation blending as the next feature in my skinned mesh class and will also abstract the mesh from the skeleton and bones by creating seperate structs/classes for them.

I already have a fairly good definition of how I want my animation system to work but maybe your article will help me :)

Advertisement

I will implement animation blending as the next feature in my skinned mesh class

Just a suggestion, depending on how you implement your skinned mesh class, you may want to consider making an animation controller as a completely separate class. That is, if your skinned mesh class is closely tied with file importing (which it shouldn't be, but that's another story), a separate animation controller can be used with any appropriate skinned mesh. All the animation controller cares about is calculating animation stuff and storing the results somewhere. Rather than having the animation controller get tied in with bone transforms and offsets, etc., just have the animation controller calculate all the animation transforms and store it according to a provided bonename-versus-index array or other simple interface. I have one animation controller that takes an array of pairs <bone-name, pointer>. After it calculates an anim transform, it looks up the key-frame-name in the array and stores the transform in the address provided (which happens to be with the node with the same name in the hierarchy.) That array is static, needs to be filled only once, and lasts the lifetime of the controller. Then the skinned mesh class, which knows all about what's needed to get the shader setup, takes the anim transforms (which magically appear in the correct place after the animation controller is told to "advance the time") and handles the remainder of the process.

That approach separates the skinned mesh from having to deal with multiple animation sets, which sets are active, how they're being mixed, what time that sequence is in which animation, etc. On the other hand, the animation controller doesn't need to deal with transposing or finding nodes in the hierarchy, or anything about offsets, etc. I.e., keep all the pose position info in one place, and all the animated position stuff in another, and relate them only though the node-name.

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.

Even thought you usually don't want to optimize before its needed you always should clean and simplify all code before starting to add more features. This step is usually most beneficial for actual learning because you need really understand something to make it pretty and simple.

There is fast and simple technique to calculate global skeleton without recursion. http://molecularmusings.wordpress.com/2013/02/22/adventures-in-data-oriented-design-part-2-hierarchical-data/

This topic is closed to new replies.

Advertisement