Jump to content
  • Advertisement
Sign in to follow this  

3D Animation

This topic is 4703 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 know this is another cheesy question, but I have to ask it. What is a good 3D animation format for a fighting type of game like Mortal Kombat? First, I chose MD3 because I figured they are pretty easy to load into Direct3D. Then, I changed my mine because of the whole physics thing. And MD3 is key framed and hence, not a whole lot of physics can be applied to them in realistic situations. For example, getting punched in the gut of kicked in the head. I know MD3s use several little models for parts of the complete model, but still. Second, I thought skinned meshes would work best. Because I can linear interpolate between the frames easier (I guess) and the physics can be applied easier via applies to bone. Also, the animation would run more smoothly and be able to adapt to the changes in the environment. For example, interpolate between standing to sitting & blocking. So I’m trying to figure out what would be the best format in my situation. Later, I will probably derive my own that conforms nicely to the engine. But I need something to get me started so that I have a base to expand on. What would you suggest? I get all kinds of things from Google, but I want someone’s personally advice with experience in the subject before I go off on my own.

Share this post

Link to post
Share on other sites
Any file format you chose is going to have keyframed animation, since that's how most modeling packages allow an animator to control a character. The simple truth is that if you need the character to respond to a physical environment, then you'll need to switch back and forth between a keyframed animation controller and a physics controller, and interpolate the motion to make it look smooth. I made a post in another thread here a few days ago on the subject.

Share this post

Link to post
Share on other sites
Thanks for the information, but what I’m really looking for is a basic framework for that type of animation. The physics framework I would have to implement mostly by my self, the animation framework I may have to as well. Unless I can find a good framework that supports bone/joint (a.k.a. skinned meshes) type of animation.

I understand that all (or mostly) 3D formats are key framed. But, some make use of joints and bones that are usually used to predict at runtime how a specific part of a model should animate. In much the same way as vertex blending, except it’s not really that hardware dependant. I’m sure you know what I’m talking about.

You have clarified the topic of how each system (controller) should take over at a desired point in time based of the client’s (player) state. An interactive control, as I call it, is used to accept user input and guide the model in it’s animation from those triggers, i.e. client presses a key, etc.. A physics controller that implements simple rag doll type physics takes over when the client dies. It’s more or less a trade off in owner ship of the client’s state.

To make this more realistic, I would like this trade off to happen frequently; not just in dead or dieing state. For example, the physics controller should take over when a player is hit for a specific part of time. The problem I’m seeing here is that if the client is in a specific state, such as block-attack, the physics controller would alter the state so that the client’s state resembles impact of the attack. The two don’t mix too well. One obvious solution is to remember the client’s previous state, that way the logic would still be the same except the animation would only be different.

I’ve also considered using hierarchical FMS for this now. The parent controller would be the interactive controller that accepts user input. The physics controller would be more like a sub routine (in concept) that is called on special occasions. It would only effect the animation, not the logic. The parent controller would always have ownership of the client’s state, calling the physics controller when needed, but detaching from it when needed also. For example, (from the above example) the client’s state would remain in "show impact" mode until the user interacts. Then the physics control would be disengaged.

This pretty much leaves the client player as an object that can be affected in many different ways using a basic interface. The input (parent) controller and physics are the two forces directly affecting it. Sound easy enough right?

What I’m looking for through, is a 3D model format that supports the bones or joints.

Share this post

Link to post
Share on other sites
These are the current client states I have thus far. Hurt and dead states are physics affected states. All others are input affected. I will add additional states that handle action recording for combos and other special effects. But for the most part, those are it.

typedef enum _CLIENTSTATE {
S_IDLE = 0,

The main controller uses DirectInput8 to retrieve the input from what ever*. The physics controller is allowed to modify the client when needed. It's job is to try and interpolate between physical damage states and match them up as best as it can with the parent's state. It's pretty much filling in the holes and attempting to make things look more realistic.

I took an idea from a compiler book and used a transition diagram for the FSM. The main states (starting points) are those the client can invoke, the several children states are those the controller invokes then needed.

Share this post

Link to post
Share on other sites
As a matter of fact I believe that MD5 does what you want. It stores and animates skeletal joint data in addition to vertices and meshes.

[Edited by - Zipster on November 5, 2005 8:24:20 PM]

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!