Bones

For games, exporting bone transforms is often more efficient than exporting animation curves.

Most animation data is modeled using Actions; however, data related to the current pose (for an Object using an Armature) is exposed via Object :

x = D.objects['armature']

bone = x.pose.bones['root']

bone.matrix # transform
bone.location # just the location.

(‘D’ is a shortcut for bpy.data).

Actions

In Blender 2.63, retrieve actions using:

anAction = D.actions[name]

Action.fcurves contains animation data per channel. The grouping of fcurves (in the blender UI) is cosmetic.

• FCurve.data_path refers the data being animated using a given animation curve. This could be something like ‘pose.bones["neck"].scale’. Several curves may use the same name (e.g. scale has 3 components so there may be 3 curves with the same data-path)
• FCurve.keyframe_points refers keyframes for a given curve. The main property of a Keyframe is co, which includes the time offset co.x (the frame) and property value co.y

References (Blender API docs)

• bpy.types.Object
• bpy.types.Pose
• bpy.types.PoseBone
• bpy.types.Action
• bpy.types.FCurve
• bpy.types.Keyframe

Python

# get a reference to the 1st marker in action 0
m = bpy.data.actions[0].pose_markers[0]
m.name # marker name
m.frame # frame for this marker 

References

• Action
• TimeLineMarker

Antistar 3D: Rising will be distributed as a universal app taking advantage of all device’s capabilities:

• Basic rendering optimized to run smoothly on iTouch
• Antialiasing (iPhone 3GS)
• Retina Display (x1.5 iTouch definition 3D view)
• 1004×768 full-screen on iPad

Visit the product homepage for a quick description.

I’m going away for a short week break. Chances that I submit before leaving are… …marginally small.
This is a picture from Hairlock’s first stage. Can you spot the teddy bear at the back?

Changing the artwork did introduce a few bugs. And I haven’t done much about sound yet.

Hairlock is an action/adventure game compatible with iTouch and iPhone devices. Hairlock will be available on the app store in July 2010.

After spending 3 evenings trying to fix my camera management, I was a little disappointed to discover that my camera positioning rules still conflict, causing inelegant jumps in places.

Guess i’ll just have to simplify a little for now. I need to get my fighting system working. Nothing really complex yet. Here’s where I stand:

• I introduced per frame character bounds for collision detection. OK, say we have a character jumping forward or extending a kick. The character’s location vector doesn’t change. What changes is how the character occupies space. With per frame character bounds, we’re not getting really specific, but we avoid unacceptable approximations.
• I arrange the PC to orient themselves towards a potential target (and disable hitting when there’s no NPC around). I’m doing this because we’re projecting space on a 2D screen and using an on-screen joypad. I feel it would be difficult for most players to aim at a target efficiently, and it’s not quite the point of my game.

Meanwhile, this stuff doesn’t really resolve how fighting should work in my game… let’s take a few examples to clarify.

RPG style fighting

There are many slightly different ways RPGs resolve fighting. I’ll be ignoring turn based games as this is a bit far off for me. Here’s an idealization of how this works:

• PC can engage combat or escape.
• When fighting, PC cannot avoid hits (NPC can miss, but that’s related to stats)
• NPC cannot avoid hits
• Timing is not important.
• PC can use potions during combat
• Minimally, PC needs to engage combat. In some games you can die because NPCs engage you, but you don’t engage them. In realtime fighting RPGs, the player must push a button for every hit.
• Typically, PC wins because their stats are better.
• PC needs to rest after fighting in order to recover health points. This is somewhat of a late addition, but it’s getting quite popular. Depending on the game, HPs are slowly increasing all the time, or potions only can restore HP, or the PC needs to be still, or the PC needs to sleep at an inn.

In RPG style fighting, the intensity of the fight is linked with three parameters:

• Experience. Two well matched opponents makes for a more ‘interesting’ match.
• Exhaustion. Even minor NPCs can outmatch a bold PC that went too quick, too far. In other words if an area has many NPCs, the PC doesn’t have time to recover and fighting becomes more risky.
• Chance. Most RPGs include an element of chance (esp. critical hits) making fighting more interesting, because even a lower level PC or NPC can get lucky and win an otherwise losing match.

Action style fighting (no shooting)

My understanding of that is even fuzzier; roughly speaking, there seems to be three dimensions to consider:

• Reflexes. The fastest opponent tends to win the fight. Games that rely more on this also rely on the player getting faster over time, as they get more used to the controls. This dimension is likely biased towards the player in many games, because the PC is faster to execute moves than NPCs
• Range. Often the player’s range is wider than NPCs. This allows a careful player to neutralize opponents before they are in range.
• Moves. In fighting games, the outcome of a contest seems to be determined on a case basis, depending on moves executed simultaneously/near simultaneously by both opponents. Example: A does a high kick, B does a low kick => B wins. A does a high kick, B does a punch => B loses.

What’s ‘light action’ like?

This is what I want to try in a first approximation:

• If the PC doesn’t have a weapon good enough, the weapon is, strictly, ineffective.
• If the PC is hitting the NPC, only the NPC loses points (and, likely, dies in one stroke)
• If the NPC is hitting the PC, but the PC isn’t hitting them, the PC loses a point.
• The PC has 3 points.
• The PC can recover their points after a cooling period.

To be continued?

Today I’ve carried out a telling experiment while creating my first half-decent kick animation (ever):

• The three step animation recipe doesn’t seem to work so well for a player action – at least it doesn’t feel right. Let’s not throw gold into a well. What I think is happening is that, when hitting a button, a player’s physical action includes preparation and impulse, so the expected behavior (at least for arcade style animation) is to complete the action. At least my animation looks better this way – after I’ve cut the first half, keeping no anticipation and  starting right in the middle of the action phase.
• My engine has been running to its limit, making balancing pointless in most cases. I’ve noticed that because I tested my animation in Blender first, and it felt smooth at 15FPS, but felt jumpy on the phone even though it was meant to balance around 15. This brings two interesting notes:
  • Around 9-11 FPS, a game needn’t feel jumpy on a small screen, or I would have noticed earlier. Surely 15 to 30 look increasingly smooth, but balancing graphics against FPS is a genuine alternative. Even though I choose 15 as a reference, a colleague more used to targeting 60FPS on desktop platforms shrugged it off, pointing out that camera motion didn’t feel jumpy. However…
  • For my kick animation (and likely other action oriented play) getting my work to look good requires 15 to 20 FPS, and I’d much rather balance at around 18.

This doesn’t tell the whole story. To a fair extent its a matter of style. I also remember an animation teacher pointing out that ‘unlike 2D, 3D action dies out as soon as motion stops’. Extrapolating a little, I’d say that, the more an object looks real, the more it requires smooth, convincingly realistic animation. Bit of a worry for me because my technology and craft are kind of half baked, with the modeling side miles ahead the animation.

Graze not, or not just yet…

Right. I removed my pretty grass for now, I know I can chunk it and display much less at once (and I will) but for now several factors point towards simplification:

• I’m worried about the cost of artwork. This may not be fair because I did spend a lot of time writing modules for my engine while getting on with the artwork.
• I’m losing illusions regarding game-space. I don’t like game space to be too simple and square, but there are ergonomics and gameplay issues involved. If the terrain is simple and easy to understand, players will tackle the terrain. If the player is complex, some players will head on while others would really rather just ‘point and touch’ and expect an invisible copilot to path-find where they want to go.
• If I need to balance around 17FPS, something else has to go, at least until I optimize a little more.
• I feel the need to focus on gameplay versus art. If you remember the boxed product game era, you will probably recall how pretty a game box typically looked compared to the actual product. Well we can think of it as a lie factor, or (generously) as a transposition. While players surely don’t play the box, having fun with the game didn’t necessarily involve high end graphics. Anyway, I feel the revival/long death of 16 bit style gaming may somehow associate simple graphics with cool gameplay.

Enough ramblings. what I really mean is, I probably need to shift the balance a little – less artwork, more gameplay and more speed. But for now…

I’m fixing a couple of frame stepping related bugs.

Note: looking back at my posts, I’m not sure if it’s fair to incriminate artwork when trying to analyze how long this thing is taking. Clearly I’ve been working mostly on the engine and UI for the past 2 weeks or so. Building the engine takes time. If the engine is reused, that’s an investment, otherwise, call it pure waste.
More coding ahoy, see below :)

Working notes for combat

I’m having a go at checking in more detail if I can get a little action to really happen in my game, and I’m not too happy. Here’s the general idea:

• Characters have actions
• Some actions can affect other characters.
• Actions are ranged in various ways (maybe too many ways)
• Actions can be narrowed using an angle. If the opponent is not facing the target within this angle, no result occurs.

I dunno – I maybe tired or I may be getting lazy. I’m trying this out with rats jumping at the PC, and I see bugs, but I also wonder, why do I really need to define all this stuff? Wouldn’t it be tons easier to refine my boundary testing a little?

Yeah… I guess. And likely much less error prone. Here is what I would  consider:

1. Bounds need to be evaluated per frame, and take orientation into account.
2. Bounds can be spherical. Likely that’s faster and easier.
3. Evaluating bounds using materials can be very useful. This way we can avoid larger than life approximations when simulating, say, sword fight.
4. Speed is a simple element to consider. Speed is more significant than impact frames. Let’s take a quick example. The rats jump one meter ahead and the impact frame is 25. At around 20 frames per second, that’s a little slower than one meter per second, giving us (for something I can relate to) 3.6 km / hour. That matches pretty well with my original idea: a rat isn’t a projectile, it jumps to bite (I dare hope real rats don’t jump neck high).
   The kick animation is much faster,  covering 1.5 meter in just 3 frames. That makes 6 x 1.5 = 9 meters per second, more like 30 km/hour. Unsurprisingly that’s about the speed limit in villages in France. Granted it’s possible to get really hurt at that speed, the more likely compromise there is that you can see a car coming at that speed, not at 120. A foot is a decent projectile.

It’s not about simulating, more about making life easier – not just defining impact frames takes time (open blender, scroll through animations, copy parameters…) it also makes stuff inherently fragile.

Like copying object coordinates instead of loading them; but that’s another story.

In Blender, Actions contain information about ‘reusable animations’ that can be combined to generate complex animated scenes. Actions can also be used to create catalogues of animations associated with game assets.

I might have suggested before that a 3D artist may prefer to keep several avatar models in the same blender file. Keeping models in separate files makes it (not impossible yet) more difficult to share geometry and materials between models. For the designer, ‘sharing’ may not be a very high level concept, more something like ‘copy, paste and modify’. Nice, fast and simple.

Blender actions are created while posing armatures. Unfortunately, there is not a clear way to retain the connection between an action and the armature first used to generate this action. Here’s a little experiment that illustrates this:

1. Create an armature A with a bone named ‘Bone’. Create an action X for this armature.
2. Create an armature B with a bone named ‘Bone’ (same name). Make action X current in B.
2. Observe the result.

Essentially, Blender Actions are lists of keyframes ‘per channel’; a channel is just a name; the name binds bone names. Any armature can use any action, and this will be ‘effective’ as long as the names match.
That may be powerful. Not great when we want to export per character keyframes for each action.

At this point, we may consider loading a config file listing actions for each actor, or design a little script letting us retain the original armature <> action binding when creating new actions (I think that can be done and integrated nicely with Blender). But I won’t illustrate any of the above this time. I just fallback to a naming convention for my actions, something like:

myActor.jump
myActor.nod

Since all actions are dumped in the same list, this also allows quickly locating per character actions in the Blender interface.

Let’s not learn all about Python Strings

Instead, try this:

z='funbot.jump'
p=z.split('.')
p[0] # prints 'funbot'
p[1] # prints 'jump'

Now we can match each action to a character ‘owning’ this action. You can learn more about actions and *stuff* in previous articles on this blog.

In Blender, an Action is a sequence of key frames representing a character gesture (walking, jumping, slashing, falling, etc…). Actions are used as building blocks in Blender’s non linear animation (NLA) editor. We can use actions to create ‘animation catalogues’. An export script using actions might be used to batch export all animations for one or several characters, so we can update our game assets whenever we need, which simplifies and enhances flow.

Interactive Scripting Session

For this session, I have created a little robot – ‘funbot’ and an armature for it.
I then create two actions and detach them from the funbot. To take advantage of actions, we need to make each action current, i.e. for every action we attach the action to the armature and export all frames or key frames (either the armature frames/keyframes or the deformed mesh) before moving to the next action. Time for scripting:

#retrieve the action dictionary
actions=Blender.Armature.NLA.GetActions()

#get an action named 'nod' (as defined by your animator)
action=actions.get("nod")

#the following prints '[Action "nod"]'
armature=Object.Get("FunBotArmature")

#this makes the action current for the armature,
#so we can playback the action and record it.
action.setActive(armature)

#even if you call this, the window won't update, but the underlying
#model does, which is what we need for export.
scene=Blender.Scene.GetCurrent()
scene.update(1)

The above script does nearly everything we need related to actions – giving access to all defined actions within a blender file, it retrieves an action by name, applies it to the correct armature and updates the scene; at this point we’re nearly ready to iterate action frames and export the model and/or armature to a file (see my interactive session on exporting meshes deformed using an armature)

Just one more thing we need is knowing the number of frames in the animation. We can actually get better than just the number of frames – instead, we can get the list of keyframes, in ascending order:

#get the list of keyframes
keys=action.getFrameNumbers()
#print all keyframe indices, like ' [1,11,24,36,] '
list(keys)
#print the length of the animation
keys[len(keys)-1]

Using this, we can choose to either export only keyframes (use less memory), or all frames in the animation (OK for really simple animations and models).

This article may be useful to both wannabe Blender animators and game developers wishing to export animations from Blender (better know what we’re trying to export). To follow, it would be nice if you know a little (a fair bit?) about how blender works and how to pose armatures. This is explained quite well in the Blender Noob to Pro wikibook.

I had to work out this stuff myself, not because nobody knows about it but because apparently it’s hard to explain (or according to some, not really worth it, although frankly, I doubt…).

So this could be interesting to other intermediate level Blender users that know enough about bones animation in blender that they’re puzzled, baffled and about to give up :)

I expect this article may be inaccurate in some places. But overall I tried to explain something that seems fairly confusing to me, and tried to make sure that if you’re confused as well, reading and trying things out patiently will get you out of the ditch.

And finally, before we start – although the Blender interface is somehow obscure when it comes to bones and other things, I think it’s worth learning, because it’s fast and productive, which is why I love Blender.

In a nutshell

• Blender actions are sequences of poses typically associated with an armature. A walk cycle can be an action, a kick or a punch can be an action. Bowing can be an action.
• Actions are reusable. You can use the same action several times in your animation.
• An armature is a bunch of bones. Bones are like magnets used to move the geometry that makes up a model.
• A pose is a way to arrange the bones that make up an armature – a pose is a kind of ‘key frame’.
• NLA (non linear animation) is a process that consists in blending actions together. For example you can combine a waving action with a walking action. That’s obviously easier if we key frame leg bones and arm bones separately (armatures, however, are not limited to human shape).
• Blender has an integrated NLA editor. this is a bit like Final Cut Pro, but for continuous animation, e.g a character doing varied things like walking, kicking, jumping…
• A strip, is just a name for an action added to the NLA editor. A strip is attached to an armature and an action, and has a starting point in time. So the strip ‘makes the armature move’, and along with it a 3D model also attached to the armature. So several strips can refer the same action and several strips can be used to animate a character over time by picking previously created actions.

Outline for Character animation using bones.

As far as I have understood and tested, bone animation in blender works in two steps – creating actions, and using actions in your animation. Bone animation is somehow confusing, because the system does not let you create actions ‘on a separate timeline’. Actions can be stored on a separate timeline, but all the editing done happens on the main timeline. Another way to say this is that you can’t edit a library item as such. Blender definitely has a kind of library for assets, but we rarely get to see it, if ever.

If you hate theory, you might want to skip the next sections (not recommended though) and just ‘work it out’ using the test setup (see below)

Creating an action the first time(!).

1. You create an armature. An armature is ‘just bones sticking together’. It is not rendered on the screen.
2. You attach a model to this armature. The model becomes a child of the armature.
3. You start creating poses for the first action that you wish to define. When you create the first pose, two important, easy to miss things happen:
   1. An action is created. An action is a sequence of poses.
   2. The created action is attached to the armature.
4. You name the action that you have created.
5. You detach the action from the armature. You typically do this because you want to create a ‘library’ of actions that you can reuse throughout your animation (or export to a game if it’s what you’re after. At this point, as far as I know, there is not a single window in the blender interface that can tell you that this action exists.

Using an action

1. You add a strip to your armature. Adding a strip is a way to tell blender that we want the armature (and beyond, the model(s) attached to it) to perform an action at a given time. Maybe unfortunately, whenever you create a strip this causes the underlying action to be re-attached to the armature.

Creating an action the second time.

The second time you want to create an action for the same armature, assuming you are already using a strip referring an action you previously created, you may find that you can create key frames (poses) but when browsing the animation your key frames are ignored.

In this case, what works:

1. Create the action explicitly.
2. Generate a strip for this action
3. Create poses for this action
4. When you are done, you can both delete the strip and detach the action.

As far as I could work out, what happens is:

• When you have no strip defined, you can create as many actions as you want and everything renders to the main time line.
• As soon as you have defined at least one strip, actions are never rendered unless they are attached to strips.

Test Setup

By default, blender only shows three ‘editors’ (each in a separate frame). To see what’s going on, you need to create several more frames and toggle them to varied editors. Each frame has a button in the bottom left corner (or sometimes top left) that lets you choose a different editor. To work things out, you need 5 editors open, which is OK on say, a small widescreen monitor:

• Outliner – this shows you the structure of your scene as a tree.
• 3D view (showing on startup by default)
• The NLA editor – this is the Final Cut Pro – like thingy that lets you do the overall layout of your animation.
• The buttons window (showing by default)
• The action view – this lets you create new actions and select an action to edit it. A tricky bit is that sometimes it lets you try to edit something that won’t show on the screen – when you are using strips, you can only edit an action that’s currently attached to a strip.

Then you can try things like:

• Creating an armature. press [space] > add > armature in the 3D view
• Posing an armature. Look at the bottom of the 3D view and click the button that says [object mode]. You can change that to pose mode. You can also click the smiley icon in the outliner, next to the name of your armature.
• Inserting key frames while posing using the [i] key and [arrow-left], [arrow-right] to browse the timeline (move back and forth in time).
• Observing that when you insert the first key frame while posing, a new action is created, and the keyframes show in the action editor as well as in the NLA editor. The action itself also appears as a child of the armature in the outliner. Also, a default name for this action appears in the action editor and you can edit the name. At this point, even though no strip is defined in the NLA, your action can play back on the main timeline.
• Observing that pressing the [x] key in the action editor hides the current action (it doesn’t delete it, it just ‘detaches it’ from your scene, keeping it somewhere in memory).
• Observing that, in the NLA editor, you can choose strip > add action strip, and that will let you select the action that you previously detached to combine it with the new strip. Also the action will become current in the action editor. You can detach the action again (press [x] in the action editor) and the strip will still cause the action to playback.
• Observing that, if you already have a strip in the NLA editor, just detaching the current action, if any, and trying to set new key-frames for posing will be ineffective.
• Observing that actions can be created from the action editor. If you have an armature selected and no current action there’s an ‘up arrow down arrow’ button that gives this option once clicked. It also lets you make any existing action (including actions incompatible with the current armature) current for your current armature at any time – sometimes allowing you to make an action current and apparently editable, but without any effect on your animation (not until you attach to the armature a strip using that action.

OK, next time, I’ll be back on my turf, and look into ways that can be used to export animations from Blender and getting them into a game :)