|
|
| Page 1 of 2 |
|
|
 Posted: Sun, 5th Feb 2012 22:21 Post subject: Investigating the animation system |
|
 |
What features should our animation system have? Post your ideas and findings here.
Regarding the basic bone structure:
* Each animated char should have at least a root node.
* Each node can have one or multiple child nodes.
* Each node features the following attributes:
** A 3DPoint defining the position relative to the parent nodes hinge (values between 0 and 1, null for the root element, 3D because we can store this way the z-drawing order of the nodes) [node.posRelParHinge]
** A 2DPoint defining the point around which the node rotates (basically it's hinge, again values between 0 and 1) [node.hinge]
** A 2DPoint defining the action point(basically where other entities, like for example bullets, smoke etc. would emit from, again values only between 0 and 1) [node.action]
** 3 float defining the current rotation value, the minimum rotation value and the maximum rotation value (to limit movement of hinges... This could also be a 3D Point) [node.rotation, node.minRotation, node.maxRotation or just node.rotation as 3DPoint]
The size of the nodes should come from the sprites they are based on. For this we still need to write a sprite/tile based animation system.
I'll write more on my thoughts regarding the animation system later on 
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34200
|
| Posted: Sun, 5th Feb 2012 22:27 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:23; edited 2 times in total
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34200
|
| Posted: Sun, 5th Feb 2012 22:31 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:23; edited 1 time in total
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 22:34 Post subject: |
|
|
| garus wrote: | | About the export formats of C4D or others. Do they output in some simple text files or more complex stuff? |
Don't know about c4d, but I think XMLs could do it for other programs.
Anyway, I think we're getting a bit ahead of ourselves, but no problem with that. Once I'm done testing, I will post more.
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 22:54 Post subject: |
|
|
| garus wrote: | | I agree with all the above. One other thing I was thinking about is: transitions between states. For example when a character is running and we want it to stop. We can't just reset the movement animation. Needs some kind of smooth transition from one state to another (legs returning to "stance" position etc.) |
Ofc, that should be something that should be solved by the animation system. What I posted up until now, is just the very basic bone structure. How should we approach animation?
Let's say we have a class
[BoneChar]
I'd say we should load one set of [BoneStructure] into it. BoneStructure should contain all the stuff I posted in my first post. (btw we could also add stuff like node.damage, node.maxDamage and so on depending on the need)
The BoneStructure will be the ground structure of the char with a predefined stance.
Also we'll add [BoneAnimation] to BoneChar which will be a reference to a list of BoneAnimations that we have. The BoneAnimation will be the current played animation.
A BoneAnimation will store a list of BoneFrames and for example the duration of the animation (world.time % boneAnimation.duration should return the current time in our animation for example).
A BoneFrame should not need more than just two floats and one integer for each node, that store it's rotational value [boneFrame[node].rotation] at a given time [boneFrame[node].time] and the sprite Offset [boneFrame[node].spriteOffset] (more on the offset later on). If we have the time in our animation we could then look for the last BoneFrame in this particular BoneAnimation and the next BoneFrame in the BoneAnimation and interpolate the rotational value... this'd result in a linear interpolation ofc this type of calculation will happen somewhere else, so we can also think about different approaches, except linear transition
... if our animation software on the other hand would produce 60fps animations then we don't need the time value in our BoneFrame and we wouldn't need animation interpolation...
Regarding the sprite offSet:
Each boneChar should also have a [Spritesheet] that stores all graphics for this bonechar. (google spritesheet and you'll know what this looks like).
The spritesheet should have a (indexed!) list of sprites with values for size of the sprite, source of the sprite and so on.
Now so that the correct sprite is at the correct position in our animation, we have the spriteOffset.
We can say that at time 1 the first node should use the first sprite of our spriteSheet. And at time 2 the first node should have the second sprite of our spriteSheet and so on. This can be used for example to load different sprites when needed (for example player getting wounded, or just for the blinking of the eyes, or animation of the hand).
Having it all indexed should make it very easy to use the same boneAnimation for two totally different looking chars.
BoneChar A and BoneChar B could both load the same BoneStructure and BoneAnimation, but just need a different SpriteSheet. This way we could create for example ONE walking animation and use it on multiple different enemy and player models, that could also be different in matters like size, as all positional values are stored in a relative 0-1 range |
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 22:55 Post subject: |
|
|
| Radicalus wrote: | | garus wrote: | I agree with all the above. One other thing I was thinking about is: transitions between states. For example when a character is running and we want it to stop. We can't just reset the movement animation. Needs some kind of smooth transition from one state to another (legs returning to "stance" position etc.)
Also animation divided into at least two sections: upper body and lower body. So we can run (legs move) and gun at the same time (aiming with guns or something). Much like in Max Payne (only easier  ). |
The transition should in essence not be a problem, it's doable. Since keyframe animation works with interpolation, once the walk button is no longer pressed, the next keyframe should be a complete halt (instead of the next keyframe from the run animation) in X amount of time, until that time the engine interpolates the animation steps. |
Ah, good idea. So we will just store instances of our figures and in our world we'll have representations, where the current animation is just another blob of rotation information that is blended over time, and not between specific frames of a specific animation |
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 22:57 Post subject: |
|
|
Eh, please consider all of my posts in here as pure brain farts. People like bearish should have more knowledge about this stuff
*btw, pedro the bear had a working animation system based on this thoughts, minus the bonestructure though, but the animation class was similar, as i had to deal with timing, spritesheets and so on. The video I posted showed so little of what I actually did in there  *
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 22:58 Post subject: |
|
|
In XNA, the default update function, that updates game logic (including animations) runs at 60. note, that drawing the game world isn't locked to the update.
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:01 Post subject: |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:14 Post subject: |
|
|
| PumpAction wrote: | | Radicalus wrote: | | garus wrote: | I agree with all the above. One other thing I was thinking about is: transitions between states. For example when a character is running and we want it to stop. We can't just reset the movement animation. Needs some kind of smooth transition from one state to another (legs returning to "stance" position etc.)
Also animation divided into at least two sections: upper body and lower body. So we can run (legs move) and gun at the same time (aiming with guns or something). Much like in Max Payne (only easier ). |
The transition should in essence not be a problem, it's doable. Since keyframe animation works with interpolation, once the walk button is no longer pressed, the next keyframe should be a complete halt (instead of the next keyframe from the run animation) in X amount of time, until that time the engine interpolates the animation steps. |
Ah, good idea. So we will just store instances of our figures and in our world we'll have representations, where the current animation is just another blob of rotation information that is blended over time, and not between specific frames of a specific animation |
So, let me take two cases, to explain, what I mean.
We have timeframe X in seconds and animation keyframes A and B. The keyframes contain all data, but for this example, I'll just assume the difference in A and B is just an angle of a bone.
Now, A is the present keyframe, B is the always next keyframe, our engine interpolates the steps in the animation between A and B. In our example, this is just an angle of a bone, and we know, that in XNA the logic updates every 60 seconds. So we just take the difference of the angles between B and A, divide it by (60*X), and add the amount to the object angle each logic update. What we have is a lean animation.
Now, if we don't want it to be lean, but we want it to ease in at the beginning and end before reaching a keyframe - that's more complex, but you get the basic idea.
So here comes the interesting part: B depends on the input state of the game. For example, if we are pressing right, then B is the next keyframe of the run animation, if we stopped pressing right, then B is the idle animation's first keyframe.
This way, what garus says is avoided.
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:25 Post subject: |
|
|
OK, here is a VERY basic animation that I created in Cinema4D, together with the possible useful exports:
Cinema4D Setup:
Download: http://www.mediafire.com/?opkfdlv8hj76sz5
Archive contains:
+ The original animation in C4D (R13) and the basic texturesheet.
+ Exported into DirectX .X format
+ Exported into XML
+ Exported into .fbx
+ Exported into .fbx with prebaked frames
+ Exported into .fbx as text
Feel free to join me in analyzing, which one might be the most useful.
If you have autodesk maya or 3DStudio max, please feel free to import this and export the stuff with them, so that we can spot differences and get sure on which software to use
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34200
|
| Posted: Sun, 5th Feb 2012 23:25 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:23; edited 2 times in total
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34200
|
| Posted: Sun, 5th Feb 2012 23:31 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:23; edited 1 time in total
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:33 Post subject: |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:33 Post subject: |
|
|
| Radicalus wrote: | | Now, A is the present keyframe, B is the always next keyframe, our engine interpolates the steps in the animation between A and B. In our example, this is just an angle of a bone, and we know, that in XNA the logic updates every 60 seconds. So we just take the difference of the angles between B and A, divide it by (60*X), and add the amount to the object angle each logic update. What we have is a lean animation. |
Yeah, inside my pile of brainfart, I was talking about the exact same thing
| Quote: | | If we have the time in our animation we could then look for the last BoneFrame in this particular BoneAnimation and the next BoneFrame in the BoneAnimation and interpolate the rotational value... this'd result in a linear interpolation ofc this type of calculation will happen somewhere else, so we can also think about different approaches, except linear transition |
--
| Radicalus wrote: | Now, if we don't want it to be lean, but we want it to ease in at the beginning and end before reaching a keyframe - that's more complex, but you get the basic idea.
So here comes the interesting part: B depends on the input state of the game. For example, if we are pressing right, then B is the next keyframe of the run animation, if we stopped pressing right, then B is the idle animation's first keyframe.
This way, what garus says is avoided |
So what you are talking now in this process is, that we load animations seperately from our chars, and we just assing the animation temporary to our char and just store the current frame and the next one.
Thus we'll say the following:
Player is walking to the left. Grab animation for walking to the left, take the first frame, and use it as the next frame in our current player animation.
Player suddenly decides to walk right. Grab right walk animation, take first frame, set it in the next frame of our current player animation.
In the mean time, the game will always lineary interpolate between the current and next frame.
...
If we extend this by two more frames, we could do some easing and so on Ofc not ALL animations would want easing, but there are work arounds. (If you are interested in more detail regarding this, look up on how to get sharp corners in an object that has a hypernurb modifier. The hypernurb in c4d smothes polygons. If you still want sharp edges in there, you just place more polygons next to each other. This will result in sharp edges when desired and done properly. The same could be used for animations ).
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:37 Post subject: |
|
|
|
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34200
|
| Posted: Sun, 5th Feb 2012 23:38 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:23; edited 2 times in total
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:38 Post subject: |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:42 Post subject: |
|
|
Yeah, give us the sourcecode of on whatever you are working right now 
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:43 Post subject: |
|
|
| PumpAction wrote: | | Radicalus wrote: | | Now, A is the present keyframe, B is the always next keyframe, our engine interpolates the steps in the animation between A and B. In our example, this is just an angle of a bone, and we know, that in XNA the logic updates every 60 seconds. So we just take the difference of the angles between B and A, divide it by (60*X), and add the amount to the object angle each logic update. What we have is a lean animation. |
Yeah, inside my pile of brainfart, I was talking about the exact same thing
| Quote: | | If we have the time in our animation we could then look for the last BoneFrame in this particular BoneAnimation and the next BoneFrame in the BoneAnimation and interpolate the rotational value... this'd result in a linear interpolation ofc this type of calculation will happen somewhere else, so we can also think about different approaches, except linear transition |
--
| Radicalus wrote: | Now, if we don't want it to be lean, but we want it to ease in at the beginning and end before reaching a keyframe - that's more complex, but you get the basic idea.
So here comes the interesting part: B depends on the input state of the game. For example, if we are pressing right, then B is the next keyframe of the run animation, if we stopped pressing right, then B is the idle animation's first keyframe.
This way, what garus says is avoided |
So what you are talking now in this process is, that we load animations seperately from our chars, and we just assing the animation temporary to our char and just store the current frame and the next one.
Thus we'll say the following:
Player is walking to the left. Grab animation for walking to the left, take the first frame, and use it as the next frame in our current player animation.
Player suddenly decides to walk right. Grab right walk animation, take first frame, set it in the next frame of our current player animation.
In the mean time, the game will always lineary interpolate between the current and next frame.
...
If we extend this by two more frames, we could do some easing and so on Ofc not ALL animations would want easing, but there are work arounds. (If you are interested in more detail regarding this, look up on how to get sharp corners in an object that has a hypernurb modifier. The hypernurb in c4d smothes polygons. If you still want sharp edges in there, you just place more polygons next to each other. This will result in sharp edges when desired and done properly. The same could be used for animations ). |
Sorry for not catching the part, where you said the same thing. Anyway, yes, I think we should load bone structures and animations separately, and let the engine dynamically set keyframes (from the animations we loaded) based on game state.
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:48 Post subject: |
|
|
Well sounds as we are all on the same line of thought
Pff, you can't beat logic. Look at what happened to the game mechanic thread, just because taste is involved 
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:48 Post subject: |
|
|
Also: good resource for XNA animation: http://demina.codeplex.com/
Download and check out the sample code.
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 5th Feb 2012 23:50 Post subject: |
|
|
Well to be honest, our animation system is SO simple, that we could built our own animation creating tool. This should be fairly easy and share the essential classes with our game...
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34200
|
| Posted: Sun, 5th Feb 2012 23:51 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:23; edited 1 time in total
|
|
| Back to top |
|
|
| Page 1 of 2 |
All times are GMT + 1 Hour |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB 2.0.8 © 2001, 2002 phpBB Group
|
|
 |
|
We're learning. I never did games, or animation, and they never taught it at uni, so 
