Please make it simple for me.

I have done a fair bit of research on animation, but after I do a lot of research I like to sort it out and break it down into very simple and basic parts that can be understood so well that they can be assembled to achieve solutions to complicated tasks without the need of instruction.

So, an animation is a series of drawings that, when played in quick succession, give the impression of motion, right? And I am not patient enough to be an old-school Disney animator (drawing each frame by hand), so I love interpolation.

I know about Pose-to-Pose and Straight-ahead animation, and the advantages of both in certain situations.

I know about the 12 principles of animation (though I have yet to find a perfect tutorial for demonstrating them, but I will).

One thing I have noticed recently, is that animations have several states. Take a ball for instance. Its initial state might be in the air. Its final state might be on the ground. And then there are transitions that happen between these two states where its state is constantly changing. The key is figuring out how the state is changing. And when it comes to bouncing balls, it is easy to find out how it is changing.

(Hmm, this is giving me all sorts of new ideas about how to approach animation.)

But in the case of a human animation, things can get complicated. I have realized that I am still a victim of the orientation issue.

If I were running a puppet show, the orientation issue wouldn't be a problem, but when animating a transition from a standing position to a somersault, the orientation issue is more prevalent.

So, long ago I thought of something I called a Tendency System. I am not concerned with what an object can do, but more concerned with what an object tends to do.

It is a "Do this, unless that" system. But this could still yield the puppet show effect (rag-doll effect).

So, say my animation code works like this(Lua):

walking = false

if walking then
playAnimation(animationID)
end

So I am checking a state, and then playing an animation based on that state. I would have a "transitioning" variable too which checks if the final state has not yet been reached.

But again the question becomes for me, "How is the object transitioning?"

Of course, this is determined by the animation. But say I wanted the transitioning to be determined by the code. Say I want the animation to perhaps be autonomous (I know, going off on the deep end here.)

I figure there has to be some golden principle to motion that is the Eureka for autonomous animation.

My tendency systems gives some pretty interesting results. For instance, when a ball rolls off of a table, it tends to fall at a rate of -9.81m/s^2 unless its mass is over or under a certain number and it's air resistance is above or below another number. (I guess this area is getting a bit fuzzy too).

So I gather that when doing an animation I should be concerned not only with what is moving, but how it is moving, and when it is moving, and where it is moving, and if it is even moving at all. And maybe this is why I am stumped, because there is so much to consider already, how much more when all of these things are dynamically changing.

So here are a few questions:

1) How do you you deal with the orientation issue?

2) Pose-to Pose or Straight-ahead? When? Why?

3) How would you approach an autonomous animation system? Resources?

4) Give it up? Interesting?

Edit:

Found a great tutorial on animation!

http://www.blendernation.com/2014/05/17/non-blender-principles-of-animation/

Hi. I think you might be overthinking this.

First, yes. An animation is a series of still images. Your game must be 3D if you aren't drawing the frames (that's the route I'm going anyway, because I don't really want to redraw the same animation from 8 different angles!). Either way, same difference!

This is a self-explanatory demonstration of the 12 principles I found a while ago (Each number literally demonstrates what it represents):

You just have to find what works for you--and often that just means you try different things until you like the result. Do you watch anime? Everybody's got a unique spin on drawing and animating things. Use those resources you found as a guide, but not as the law that mandates thou must do it this way or that.

Pose to pose, straight ahead, squash and stretch...those are suggestions and you can view them as a reference. If you aren't sure about a particular motion, you can always look it up. I googled "walk animation" and this is what I got:

What do you mean by orientation issue, though? If you need the motion to model that somersault after, you could find a video of someone somersaulting and use it as a reference. Is it a coding question? If so, posting your question in the graphics programming forum might help. Sorry for the long post and good luck!

What do you mean by orientation issue, though?

Take the forearm for instance. During any type of motion, the orientation of the forearm goes through many angles on several axes. What I want to eventually avoid is having to use video as reference for a specific motion. I know that every bone of the body has constraints and limits. So eventually I would like to create a system where I can have a character grab an object realistically (without animation) based on a set of rules that define the constraints and limits of the bones to guide the arm on HOW to grab an object.

But right now I want to just get some pointers on game animation itself (not the programming side, yet).

When looking at a reference video, it is not always clear how the bones are oriented (rotation), especially if the performer has on clothes. Even with walk animations, there is a lot of rotation going on as well (not just bending as the illustration above illustrates).

Thank you for the post.

I've read your post but I'm not sure if I understand what you want to implement.

Basically you can show and animate people with 2 things: frames and 3d models. If you animate with frames then you have to draw every frame anyway so there's no automation. If you animate using 3d models, you can assign "weights" to vertices/poligons that move with e.g. an arm and give a realistic stretching effect (like a shirt gets stretched when you raise your arm). So it doesn't matter how you move the arm of your model, the parts in question will realistically react to that movement. Once the weights are set then those will work with all kinds of animation (like punching even though you originally intended to only use an armraise-motion).

If you want to go with frames then basically you're asking for a system that creates frames/draws pixels on frames according to a certain ruleset. This would be a very complicated process and I doubt that it would give satisfying results. The next best thing is creating frames from a 3d model.

I suggest observing several animations, paying attention to details then practice with whatever method you prefer.

Hello.

1) How do you you deal with the orientation issue?
2) Pose-to Pose or Straight-ahead? When? Why?
3) How would you approach an autonomous animation system? Resources?
4) Give it up? Interesting?

1) Use IK solvers. Most animation suites have support for that (3DS Max, Maya, Blender etc.).

2) Note that these are just methods employed for drawing poses. Either method has its use, so while making an animated sequence you can rely on both for specific parts:

- Straight-ahead is better employed when you're concerned about the fluidity and realism of a continuous sequence of frames. You draw progressive poses, advancing frame by frame.

- Pose-to-pose is better employed when you need to be specific about what you want the character to do. You use it to synchronize visual action with the soundtrack (dialogue, spot effects, musical cues) since in animation production the soundtrack is prepared before the graphics (even if it's a temporary, "scratch" version just to mark the timings), synchronize action with other actions (two characters visually interacting), to control with precision how a character acts (to make sure he doesn't go beyond a certain physical point, etc.). You draw key poses at specific points in the timeline, and then go back and fill in between the key poses with intermediary poses.
But if you're serious in your study you should rely on animation theory literature, which would explain deeper.

3) It depends on what you consider an "autonomous animation system." In the context of video games, animations are usually controlled by a finite state-machine for each actor.
Each actor has several states that they may go through (swimming, running, walking, shooting etc.). These states involve more than just changing the current animation - maybe the state uses a different movement speed than the default for moving the actor (walking vs. running), maybe the state broadcasts an event requiring that the engine creates new objects in the world (when shooting projectiles etc.).
When the actor is under a certain state, it's the programming of that state that controls the actor and makes him perform certain animation sequences depending on their interaction with the world and the player.
If you search for "game state machine" you will find a lot of material. You should also make a thread in the Game Programming forums if you're interested.

4) Give up what? In any case, animation is essential in making your game look alive and engaging. Even the most primitive text game has animation: a blinking cursor.

A rudimentary example of an object-oriented state machine for a game actor.

[spoiler]
Each game frame\tick\update, the engine goes through all of the active actors in the game and invokes their update method:

For a:Actor = EachIn AllActors

	If a.isActive() Then a.onUpdate()

Next

The 'onUpdate' method of the actor invokes the 'onUpdate' method of whatever current state the actor is in:

Type Actor

	[...]

	Field currentState:State // Stores the current state that the actor is behaving with.


	Method onUpdate()

		Local newState:State = currentState.onUpdate() // Run the update logic of the current state.
		
		If newState <> currentState Then changeState( newState ) // Detect a change in states.

	End Method


	Method changeState( newState:State )

		currentState.onEnd()	// Call the old state finish method.
		newState.onStart()	// Call the new state start method.

		currentState = newState	// Store the new state as the current.

	End Method

End Type

You have a general interface for what a state object should be. Then your actual game states inherit\implement this interface and fill it with custom logic.
The 'onUpdate' method of a state is responsible for always returning a valid state instance. This means that it can return itself (so the actor continues with this state on the next frame), or it can return some other state (which means the actor will transition to a different state).

Type RunState Extends State

	myActor:Actor     // Reference to the actor so the state can control it.
	gameEngine:Engine // Reference to the game engine so the state can query information about the game context.

	[...] // Any additional custom members etc.

	Method onStart()

		// You're not required to have any logic in the 'onStart' or 'onEnd' methods 
		// of a state, but some states can have a real use for this, like starting
		// animations, broadcasting an event to the rest of the game etc.

	End Method


	Method onUpdate:State()

		// You have the state logic in here.

		// Maybe you check for which keys are pressed.

		If gameEngine.input.GetKey( "KEY_JUMP" ) Then

			Return gameEngine.states( "PLAYER_JUMP" ) // Return a different state, causing a change.

		EndIf

		Return self // Return itself if the method reaches this point.

	End Method


	Method onEnd()

		// Any additional logic to be executed when this state ends.		

	End Method

End Type

[/spoiler]

Thank you all very much. I will look into everything mentioned, i forgot about IK solvers.

Question:

I use the BEPUIK Blender build, is this the IK solvers thing?

It definitely is a solver, since you are only moving a single point at a time and the rest is "dragged along" with it - the other parts of the chain are being oriented procedurally by the solver.

That BEPUik appears to work on a multi-chain structure, and has feedback (or double-solving, if I'm not mistaken), which allows one chain to influence another.
It seems to be quite sophisticated.

Okay, thanks very much! Yeah, this bepuik version is awesome, it's,just that I have to figure out how to work with it better(it's pretty easy, but I want better control.)

I just downloaded the new version for 2.7 which should fix most of the orientation issues I was having.

Just want to update one last time with my latest findings (for anyone who may read this post later having the same questions).

My workflow for animation is much smoother now:

1)I start with as few frames as possible (one frame per Key Pose). So if an action has 5 key poses, I use 5 frames.
2)I also set my interpolation mode to constant. This way the animation blending does not distract me from focusing on the poses.
3)Once I have the key frames down, I scale the frames up (not too far) to make room for the in-between poses). Still using constant interpolation.
4)Next I put in any additional poses according to the 12 principles of animation.
5)Now I change the interpolation mode to Linear, and work on the timing of the poses with the Dope Sheet. I just grab a frame and move it until the animation looks right.
6)And lastly I change the mode to Bezier, and work on the curves to make sure the ease-in and ease-outs are good. I also scale the pose up to fit the time I wanted to work within. I am still working out step 6 though.