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

Aging

Remember one problem with cloth simulation is that the cloth / garment (or whatever else) is originally assuming a rather stiff, unnatural shape. One solution may be to add lead frames to ensure there is enough time for cloth material to assume it’s rest position.

A much easier solution in practice is to bake a few frames, then apply the cloth modifier in the modifier stack. This will save the current vertex coordinates (so if you go to frame 10 and apply the modifier, you have a ’10 frames old’ version of your mesh).

This method isn’t absolutely accurate for a cyclic animation. Our ‘aged mesh’ doesn’t record initial velocities, so it’s probably more accurate to run/duplicate (sigh) 2 or 3 animation cycles. Still useful…

The Marilyn Effect

I continued experimenting with the dress (I know I should post a pic, just think of it as a light summer dress or night dress).

And I continued getting this funny/bizarre/undesirable effect where the dress is steadily rolling over itself and upwards, and this isn’t exactly what I’m looking for.

I tried pushing a fair bunch of parameters that should logically rid me of this effect, but I can just about mitigate it. Shall we start from the beginning then?

• Expected behavior: the dress settles down under the influence of gravity, covering the character’s body.
• Actual behavior: the dress rolls up while the character is walking (12 centimetres up after a complete walk cycle)

Proposed solutions:

Increase the definition of the mesh

I don’t know for sure how the simulation works. So I guess this is worth trying since my mesh is pretty low def, just to get a rough idea of how the definition of the mesh affects the simulation.

=> At subsurf level 1, I gain 2 cm although it’s difficult to evaluate because the ‘bottom sleeve’ isn’t straight if anything.
=> At level 2 I strictly get the same as without subsurf enabled.

I guess this is good news if anything. Means I should be able to work at low def and save time on testing.

Increase gravity

The dress doesn’t roll up by itself. This happens because the character is walking, so their legs are pushing the dress forward and up. I thought that, if I increased gravity, it may be more difficult for the dress to bounce up.

=> Increasing to 10 G (100), the collision detection fails and the dress simply slips down. Interesting.
=> At 2G, the result is much more interesting. In fact I didn’t see the ‘dress rolls up’ effect in this case. But the result looked pretty rough so I increased collision quality (2>3>4) …and after doing this I fall back in the initial situation.

Increase Cloth Friction (Cloth tab group > Collision > Friction)

Increased friction is meant to ‘kill motion’ when a collision occurs. So I increase friction (5 > 80 – the maximum).

This pretty much does the trick, but just using it in isolation may not be enough; note that there are similar parameters in the collider’s collision tab (). However tuning this doesn’t seem to affect the outcome.

But just increasing friction doesn’t help much with a silk preset. It only really worked after I replaced the silk preset by leather.

Increase the mass?

I restored the silk preset and replaced the default 0.150 (Kg?) by a staggering 10 kg. The effect is spectacular. The top  sleeves stretched a good 20 cm down, revealing most of the character’s upper body. The bottom sleeve also dropped down. This uses about 10 frames. During the walk cycle per se there is no ‘rolling up’.

Changing the mass of the cloth demonstrates limitations when trying to pre-calculate a ‘rest position’. Say we burn 10 frames. Now the dress top sleeves are stretched 20 cm down as I explained. Let’s apply the cloth modifier and restart the simulation. What happens then? You guessed, the top sleeves stretch another 20 cm down.

Back to leather…

I wasn’t fully convinced with my experiment with leather and friction. So I thought I’d try leather alone first, then add friction (80 – still maximum) and think things through.

In short, friction helped a little, not all that much. Without friction the dress seemed to be bouncing up and down, pretty much like very hard leather. With a lot of friction the overall effect would be better, filling more like wearing a clothe and less like wearing a piece of armory.

Some thoughts

There’s a couple of things I didn’t do, which may actually solve the problem independently from everything else:

1. Make the dress longer (well… I’ve actually done that)
2. Duplicate my walk cycle 2 to 4 times and run the simulation through.

Given the tests I carried out, it feels like we need to plan ahead, taking into account a dynamic relaxing process rather than trying to rely on pre-calculated aging. In plain english, I think if I made the dress longer, and let the animation run, a little more, it would stabilize and the dress would appear shorter, with more or less jiggling depending on selected material properties.

Since it’s a walk animation the feet of the actor are somehow linked to ‘ground dummies’. That shouldn’t make duplicating the walk cycle difficult, but somehow it does (at least for me). It’s a pity because Blender has unified views to deal with key frames involving concurrent objects (e.g. NLA editor) but these seem to fall just a little short of letting me ‘just copy everything’.

Cloth properties are unit-less. That doesn’t make individual properties terribly easy to understand.

I think it would be nice if we could specify in advance which parts of the clothe are stretched before running the simulation. Pinning feels like a kind of substitute, not necessarily a great one. Pinning makes it difficult / impossible to avoid combining the cloth with an armature, but then the kinematics of the armature tend to conflict with cloth behavior. Instead, I’d like to specify (e.g weight paint) that the top of the dress is stretched, while the bottom isn’t.

That’s it for now. Next time I’ll discuss exporting cloth animations.

A quick solution for equipment

The story so far

A few months back I wrote a simple export plugin for Blender. Unlike most export scripts, the plugin interprets blender files as asset libraries. The plugin supports basic material properties and animation.

When I wrote the export script, I didn’t want to spend time writing a bone animation module for the engine. Instead I decided to bake animation frames – bone deformations are applied from within blender, resulting in ‘mesh frames’.

While mesh frames are pretty heavy, there are advantages too:

• Interpolating between frames is much faster than applying bone deformations.
• Since the exporter generates frames by collapsing an object’s modifier stack, it is possible to export all kind of animations, not just bone animations.

Equipment

At that point, my setup didn’t provide a solution for equipment. So if I wanted an actor to hold an axe, or a sword, I had to clone the model and bake a separate animation. Needless to say such a system is hardly usable.

Equipping items consists in making them visible as part of a PC or NPC visual presentation, so an actor could hold a sword, a shield, or change dress (this requires more care).

The new setup is fairly simple:

1. Bones are added to the actor’s armature – so we can add a bone to represent a sword, a gun, a hat… anything.
2. The item we want to equip is placed at the correct location – so if it’s a sword, we just place it in the character’s hand.
3. The item is renamed accordingly, e.g. sword@elven, indicates that the sword should animate along with an actor named ‘elven’.
4. Parent the item to the armature (in the item’s modifier tab, I check ‘make real’ for the armature modifier, to ensure that this gets applied when the exporter collapses the modifier stack)

The notation item@actor is an arbitrary convention. Since actions are not bound to any particular actor, if we have…

• an action named elven.strike
• a piece of equipment named sword@elven

…then the exporter knows that elven.strike should be applied to sword@elven.

Animations are exported separately for various pieces of equipment. It’s a huge step forward compared to the previous system I used. When we want an actor to equip an item, all we have to do is load the matching ‘animated version’ of this item and synchronize animation playback.

This solution is still wasteful – but it wouldn’t be too hard to extend it to define equipment slots (so instead of exporting all animations over again for each item, we’d just have ‘dummies’ used to define transform matrices)

One Animation per File, really?

When I investigated Blender animation to create my exporter, I found about Blender actions. Blender actions provide a simple, easy way to define ‘several animations per actor’. More specifically, an action is a named sequence of key frames associated with an object (typically an armature, but also works with other object types). So at the moment I have ‘run’,'walk’,'hit’ actions etc… While actions are normally used in NLA (non linear animation – aka mixing part animations together, e.g. smile + run), they originally seemed well suited to building ‘animation libraries’ - All the exporter has to do is retrieve each action, bind it to the armature and export it.

Unfortunately, this approach breaks down when we combine several animated objects. For example, suppose you want to apply a floor constraint (e.g., as part of a walk animation), then…

1. Consider the armature for the actor we’re animating.
2. Define a ‘floor’ object
3. Define 2 empties (used to move the actor’s feet)
4. Apply the floor constraint to the empties using the ‘floor’ object as target
5. Add IK solver constraints to the feet of the actor’s armature, so the feet now follow the empties.
6. To animate, we move the empties, not just the bones.

How many objects are being animated here? Well, 3 really. We have the armature and the empties. To setup this animation correctly, then, we need to bind the following actions (assuming we associated the empties animations to actions) …

• The armature action (e.g. elven.walk)
• LeftFootEmpty action (elven.walk.leftFoot?)
• RightFootEmpty action (elven.walk.rightFoot?)

At this point, I drop the towel altogether. Although there are disadvantages to keeping one file per animation, we have to choose: unless an animation is simple (1 action <=> 1 animation <=> 1 object), it should be kept in a separate file.

I guess if it was to do all over again, I’d simply try to avoid complex rigs. In the meantime I changed my export script (never mind some of my engine code) so that animations are always kept in separate files. I now have, for each object:

• A model file. All models, whether animated or not, use the same format
• For each model, zero, one or several animation files.

I think the sample *.m3g files (and the methods used to load and display them) look neat. I also noticed that Blender has an exporter for *.m3g with support for textures, armatures and animation. Gerhard Völkl clearly put a lot of work in this exporter, topping 3000 lines of code in a single file (a couple dozen classes in there, it’s actually quite readable).

(note: on a PC you can find the source for blender py scripts under Documents and Settings\User\Application Data\Blender Foundation\Blender\.blender\scripts)

The linked page also provides samples files to help us understand how the exporter interprets blender files. There are two things I immediately want to know:

• How are animations exported? In Blender, bone animations are not directly connected to armatures. Export plugins typically use a kind of naming convention, and this one makes no exception, for example Talk#A1E10#2 is an action, where A1 refers the target armature, E10 means the animation ends at frame 10, and 2 appears to be the node ID (see below).
• How are node IDs selected? From sample M3G code, it’s fairly obvious that M3G files, for better and for worse, do not contain named entities. Unfortunately the blender M3G exporter uses a naming convention that requires the artist to insert IDs. Maybe this can be improved a little – for example, we could have a java source file with named constants remapping blender object names from arbitrary IDs.

The M3G exporter also allows direct export to java code (in other words, it can generate code which, when run, will produce a scenegraph).

Useful resources

• An informit M3G/JSR184 tutorial
• Wikipedia on JSR184
• A digest of the M3G file format

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.

My current export script for character animation requires a naming convention for binding a character to it’s armature.  Also, the script only exports the currently selected mesh.

In this article, I illustrate how to examine a Blender scene to discover assets; I also show how to find the armature modifier associated with an animated character.

In outline, this is how to structure a script to export an asset library:

• Iterate all objects in the scene
• Retain only Mesh objects.
• For each mesh object, check whether this object uses an armature; if so, assume the object is a kind of actor or character.
• Export mesh objects as appropriate (You can learn how to do this from previous articles on this blog)

Interactive session

Let’s try the following:

s=Blender.Scene.GetCurrent()
s.objects
for x in s.objects:
	x.type

(After typing ‘x.type’ in the interactive console, press enter twice to effect the loop)

This will print the type of each object in the order they are stored in the scene. We only want to export Mesh objects. Pick any Mesh object using an armature. (in my case, index 1 in the object list).

object=s.objects[1]
for x in object.modifiers:
	if(x.type==Modifier.Types.ARMATURE):
		x

This will print something like:

[Modifier "Armature", Type "Armature"]

That’s all we need to identify actors and props in a Blender Scene.