Skip to content

Archive

Tag: Character

When the motion of game actors is driven by a physics engine, we need a reliable method to control their motion. A governor uses negative feedback to adjust forces given a target velocity.

Principle

When a body of mass M is at rest, applying a force F will result in a speed S = F / m.

This formula can be used to write a simple governor – given the current velocity V0 and a target velocity V1, we have:

F = ( V1 – V0 ) * M

Units:

  • F – force applied (Newtons)
  • V1, V0 – velocity (meters per second)
  • M – mass (kilograms)

Given the above we can write a very simple function that will calculate the force F required to update the velocity of an actor at every frame.

It may be working better than you’d expect – notably, given motion conservation, even a trivial governor (based on the above principle) will quickly achieve target velocity.

Scaling the output

The above formula can be modified by introducing a scale parameter:

F = ( V1 – V0 ) * M * S

The scale parameter may have uses – for example you can use it to increase the governor’s output when friction/air resistance become significant.

Note that scaling the output in this way may break time invariance – the simulation will behave somewhat differently depending on the size of time steps.

Implementation notes

Impulses vs continuous forces

A simple way to implement the above consists in delivering the governor’s output as impulses. An impulse is a discrete force applied to a physical body. A priori it may appear that continuous forces would be a better choice. However, depending on the way continuous forces are implemented by the physics engine, an impulse governor may be preferable:

  • When applying a continuous force, the force is usually given in newtons per second. Therefore additional calculations are needed to precisely determine the total force delivered by the governor.
  • With impulses applied at every frame, the ‘stop and start’ effect that one should expect is not visible.
Beware that using impulses doesn’t mean that we can fully ignore the size of time steps (see ‘scaling the output’, above).
Ground units
When driving the motion of ground units, there are many situations where the slope of the terrain isn’t known a priori. So the primary input to the governor is a velocity vector parallel to the horizontal plane.
However, applying horizontal forces to a ground unit may cause artifacts.
Why should we expect artifacts? The governor adjusts velocity towards a specified target – so if the terrain has a slope, velocity includes a vertical component. Unless this vertical component is included into the target velocity, the governor will ‘resist’ climbing and falling.
For a ground unit, it is meaningful to disable the governor’s output when a ground unit is airborne.

Issues

Sharp changes in orientation

In some games, sharp changes in orientation are not a problem, especially when the actor need to be responsive (e.g. controlled by the player). For large actors and some other games however, sharp changes in orientation look ugly. A low value for S ( ~0.1 or less ) will reduce artifacts but this solution is not ideal.

A simple way to solve this problem is to interpolate between the current orientation and the target velocity before passing the target velocity to the governor.

Note: I removed the ‘motion aliasing’ section referred here previously; the artifacts I observed in my simulations were not related to the governor itself.

Going further: adaptive governors

Compared to the solution described above an adaptive governor can handle various situations by automatically correcting the scale factor S. This is done by measuring the bias between the expected output (target velocity at frame t0) and the actual output (real velocity at frame t1 = t0+1).

It is wiser to start with a simple governor - whether adaptive or not, the governor needs to be initialized with a base value for S; additionally when encountering obstructions, adaptive governors tend to ‘overheat’ – increasing S to a very high value. While it is possible to clamp the scale factor to a specific range, this is probably just the first in a series of adjustments – adaptive governors are smarter, they are also harder to design.

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.