SimPose-ium (V4.0)

Introduction

I'm in the process of writing a Sim animation editor. On the way I've got here, which whilst it doesn't do much useful for the game, seems worth sharing.

What's new in Version 4?

• Export Sims as a Wavefront object (OBJ)
• Make a prop SKN from a Wavefront object
• A 'floor' prop is provided for the Sims to stand on (gives a ground plane reference height)

What's new in Version 3?

• Keyframe animation
• Support for displaying 'props', i.e. glasses, hats, hand-props etc
• Selectable hand meshes and textures
• Improved joint movement, blending (the effect is subtle!)
• Bug fix: previous versions were reporting 'Bad Data' when loading some of the male body meshes (B004 and B005)

What was new in Version 2?

• Support for two characters
• The ability to change the background colour
• The ability to change the colour and intensity of the ambient light
• Full control over the camera position, and zoom
• Three optional directional lights
• The ability to create, save and reload libraries of predefined poses
• The ability to control ROOT and PELVIS translations and rotations

Setup

• Get the Zipped program from here
• Create a folder somewhere convenient and unzip the program into it. It is important the you have 'Use folder names' ticked, so that the data goes into the correct locations

You now have one male, female, boy and girl figure available, plus the dark glasses and floor props.

You can add further choices to the droplists by copying model and texture files (extracted with FarExtract, downloaded from the web, or found in the SimShow GameData folders) into the appropriate SimPose folders. ObjX is a model (.skn) folder and TexX the equivalent texture (skin) folder, where X is: M (male), F (female) B (boy), G (girl) or P (prop). Inside each character folder are three others, for Head, Hand and Body models/textures.

Operation

Basics

The window is divided into two panels: the righthand panel is the character display, whilst the lefthand panel is a tabbed control with two pages.

The following sections will describe the controls on the two pages, and the menu items.

"Lights/Camera" Page

Camera/Lights controls

The main control in this group is a droplist that selects the feature to be controlled: the background colour, the ambient light, the camera, or the three directional lights. Depending upon the feature selected, the four sliders, the check box and 'Change' button become enabled as appropriate.

The required check box: directional lights only (the other three are always required). Is this directional light required?

The 'Change' button: for all but the camera. The patch to the left of the button is the colour associated with the selected feature. Pressing the button displays a standard Windows colour selection box to change that colour.

The remaining four controls, the sliders, control the position of lights and cameras around the characters. The characters can be thought of as being at the centre of a sphere, with the lights/camera positioned on the sphere and pointing in towards them.

The 'Direction' slider moves the lights/camera 360 degrees around the characters (think longitude)

The 'Elevation' slider moves the lights/camera 180 degrees from below the characters to directly overhead (think latitude)

The 'Zoom' slider moves the camera only toward/away from the characters (think radius)

The 'Offset' slider moves the centre of the sphere. Without this, the camera tends to be looking at the characters feet! The centre of view can be moved up and down (useful when zoomed in).

Viewpoint and rotation

These select the camera angle, and whether or not the characters are rotating on their axis. The NS, SE etc positions are intended to mimic the views of the characters in the game. When a camera position is selected from the droplist, the camera slider controls move to reflect the same position.

When the model is rotating, the spacebar causes the motion to 'single step' on each spacebar press. The return key causes continuous rotation to resume.

Lighting notes:

• to get the look of a character in the game use a white ambient light only (this is the default on installation)
• calculating lighting effects is time consuming, so the program may run slow with all three directional lights enabled
• to see the effect of the directional lights, the colour of the ambient light must be changed from white (otherwise it swamps the other lights). If the ambient colour is black, the characters are only lit by the directionals

"Character" Page

Characters visible + control

The program internally always has two characters loaded: Sim1 and Sim2. However, the user can control which of them is displayed and which is being controlled.

The droplist controls what is displayed: both Sims, or just Sim1 or Sim2. If both are to be displayed, there is the option of having them appear at the same physical position, or at an offset (in effect on adjacent floor tiles). Basically I don’t know how the animations for character interaction are programmed (is the space between the characters part of the animation, or because they are on different tiles?) so I've given the program both options for the moment.

The radio buttons select the Sim to be controlled. If only one Sim is being displayed, then obviously only that Sim can be controlled.

Character

The top droplist lets you select the age and gender of the character controlled (after changing the character type, you may need to step the display (spacebar) or move one of the sliders before the character displays correctly)

The next two droplists select the required body type and texture.

The last two droplists select the required head and texture.

Joint Control

The droplist selects the joint to be modified. The names are fairly self explanatory - but note that not all models have all joints - so some selections may not do anything. Since version 1, I've added the controls for the ROOT and PELVIS. These can have both rotations and translations (i.e. movements in space). You'll see that pretty much the same effects can be achieved with changes to the ROOT and PELVIS. My guess is that the ROOT is used to control the position of the Sim in space (e.g. when walking, the ROOT translation controls how far across a floor tile the Sim has moved), whilst the PELVIS is used to control the position of the Sim relative to objects (e.g. when the Sim sits down, the PELVIS is translated downwards)

The three sliders set the position of the selected joint in the three axes.

The radio buttons select the degree of control the sliders have: Course -180 to +180 degrees, Medium -45 to +45, Fine -10 to +10.

Whenever the radio button selection is changed, or a new joint selected, the sliders return to the mid-position. The sliders give control around the currently set position (i.e. they are not an absolute position - try it you'll soon see what I mean).

Animation Time

If a keyframe animation is being displayed by the controlled Sim, a droplist is provided of all the poses that can be adjusted (indicated by time). The user selects the time for the pose to be adjusted and then the Joint Controls adjust the pose at that point in the animation.

Menu Items

File

Static

Key Frame

See the notes on keyframe animation below

Animation

Ignore all these items for now.

Props/ Hands

Import/Export

These have been added to enable new 'props' (hats, carried objects etc) to be generated - see the notes on creating new props below.

Notes on keyframe animation

Background: Keyframes and LinkFrames

The term keyframe comes from traditional animation techniques (think Disney). A skilled artist would draw a character in significant positions (keyframes) to establish a movement (e.g sat in a chair, halfway out the chair, standing by the chair). A less skilled artist then performed the 'tweening', drawing the character in the positions between the keyframes, to get the required number of drawings for smooth movement over the timing of the action. So if the animation is to be shown at 25frames/second, if the keyframes were half a second apart, the 'tweener' would have to supply the other 12 frames.

The term keyframe has been adopted by the computer animation community, were an animation is stored as a series of keyframe poses, and the computer works out the intermediary positions to achieve smooth motion. In the diagram below, the vertical lines represent points in time where the computer will generate a display. The blue and green lines and dots represent the required value of some parameter defined in various keyframes. The black dots represent the intermediate values calculated for the other frames, and the red line is the apparent 'path' seen on the display.

There is one big difference between traditional animation and animation for computer games. In a film animation there is a single planned sequence of activities for the characters. In any scene, the animator always knows what the character will be doing next, and so how the animation needs to develop. In a game however, the action of a character is determined by the player (or by a choice made by the computer). For example, a Sim might be standing waiting, it could then: walk away, start dancing or start talking. The game stores these separate activities (standing, walking, dancing, talking etc) as separate animation files (CFPs). In order that the animation looks smooth, the end pose of an animation must be the same as the starting pose of all the animations that can follow it. I've called these poses/keyframes at start/end of an animation LinkFrames (if anybody knows a more generally agreed term for this idea I'd be pleased to hear from them).

 Translation vs Bounce

 The diagram above is a typical 'Translation' keyframe animation. It starts at one Linkframe (shown in blue), then after 3 intermediary keyframes (green) arrives at the end Linkframe (blue). In the example above, the length of the sequence is 18 frames, with the computer calculating the 13 intermediary positions (black). The important feature of the translation is that the start and end Linkframes are not necessarily the same, and that no assumptions are made about the intervening keyframes.

Looking at the CFP files, it is clear that the SIMs engine also supports animation where the activity is defined by half the number of frames you'd expect. I'm assuming that this is for symmetrical activities. That is those where the Sim moves through one set of motions, then the same set of motions in reverse, to return to the same Linkframe position. I'm calling this a 'Bounce' action.

A bounce action is defined by the end Linkframe and the keyframes between that and a keyframe at half the sequence length. For example, in the diagram below the left-hand half is defined by the user, then the computer calculates the mirrored right-hand half.

Hints

• LinkFrames have to come from a pose library, but its probably also advisable to create most keyframes as static poses first and store them in a library, then add them to the animation using Add Keyframe (rather than try and perform major posing whilst the animation is running).
• When a keyframe animation is saved, the names of the LinkFrane(s) are stored. When the animation is reloaded, the LinkFrame pose is taken from the pose library (assuming the same pose library has been loaded) rather than the animation file. This means that if a LinkFrame pose is changed in the library, all animations that use that pose are also changed when next loaded.
• You will need to perform posing whilst the animation is running to 'fine tune' animations. It is probably helpful to use Scale Keyframe to speed up the animation during posing, then slow it back down to the correct speed when you're happy with the result.
• SimPose-ium uses a frame rate of 30frames/second (remember this when you are calculating how long you want an animation to run for)

Notes on creating props

In order to create props, you'll need a 3D editing tool that can import and export Wavefront (OBJ) objects, or a 3d file format converter that can convert Wavefront objects into a format that your editor does know about.

Its important that the editor (and file format converter if used) maintains the object's 'face normal' data, which ironically means that my Wavefront editor, GMEdit (available on BBay for a mere $35) won’t do because it ignores normals (GMEdit was written for Poser, and Poser doesn’t use the normals data).

Basic method

This is a bit fiddley, but following these steps should achieve the desired result (its actually easier than it sounds!)

1. Pose a Sim in a suitable position to interact with the prop you want to create - so for a carried object you'd want the hands in an appropriate position, for a hat any pose will do (this is to ensure that the created object attaches correctly to the Sim)
2. Use 'Export OBJ' to create a Wavefront object from the Sim. If you create a file 'c:\path\sim.obj' you'll also get a file 'c:\path\sim.rev' - this is used during import to get the geometry of the imported object correct (see step 6)
3. Import the Sim object into your 3D editor (without scaling or repositioning it) and create the prop object you want so that it looks correct in your editor (i.e. to scale with the Sim, in the correct relative position etc)
4. Save the created object only (i.e. don't include the Sim's mesh).
5. Open the created object file in a text editor, and look for lines starting "g" (they will be followed by a name). For the first of these change the name to the name of the body part that you want the prop to attach to (as displayed in the Joints drop-down list). Any subsequent "g" lines, can either be deleted or changed to the same name
6. If in steps 4 and 5 the object was saved as 'c:\savepath\object.obj', copy/rename 'c:\path\sim.rev' as 'c:\savepath\object.rev'
7. In SimPose-ium, 'Import OBJ' the created object (object.obj). It’s a good idea to have the selected Sim in the same pose as in step 1. The selected Sim should also not have any props attached (use 'Clear Props' to remove any that are already attached). Import OBJ will attach the created object as a prop in the correct position relative to the Sim (using the data in object.rev). At this time it is shown in white (no texture)
8. Create the SKN file for the prop by 'Export Prop SKN'. If this is placed in the ObjP GameData folder, next time SimPose-ium is run it can be attached like any other prop, and have a texture assigned.

Example - the floor prop

As an example, I'll run through the process I used to create the floor prop supplied with V4.0

1. As what I want the floor prop to do is establish the ground level, the default standing pose is appropriate
2. Export the standing Sim as say 'sim.obj' ('sim.rev' is also created)
3. Import 'sim.obj' into an editor. The floor was created by adding a cube to the edit 'scene' and then scaling and positioning it so that it is just under the Sim's feet
4. The floor cube (only) was saved as 'floor.obj'
5. 'floor.obj' was opened in the Notepad editor. A number of lines "g cube" were found (saying that the faces of the object belonged to a single group called 'cube'). As the floor doesn't want to move with any body part, it needs to be attached to the Sim's ROOT. So, all the "g cube" lines were changed to "g ROOT"
6. The 'sim.rev' file created in step to was moved into the same folder as 'floor.obj', and renamed 'floor.rev'.
7. In SimPose-ium Import OBJ is used to load 'floor.obj'
8. Export Prop SKN was used to create 'floor.skn', which was then copied to the 'GameData\ObjP' folder

Advanced issues

In the above examples the created objects are assumed to be attached to a single body part. However, there is no reason why different bits shouldn’t be attached to different parts. You might make a backpack that bends with the spine, or a glass and bottle that can be held one in each hand (though stored as a single object). However, this does require some degree of understanding about the way Wavefront objects are constructed.

The "g" commands in the OBJ format control which faces belong to which group, and so which faces become attached to which body parts. In the glass and bottle example, If the glass is to be in the right hand, the set of faces that constitute the glass should be preceded by a "g R_HAND" statement. Similarly the faces of the bottle should be preceded by "g L_HAND" - the easiest way to do this is to get the editor to create the glass and bottle as separate groups, and then edit as in step 5, but replace the names by "L_HAND" or "R_HAND" as required.

Ambitions

These need information I don’t currently have:

• Displaying and modifying game animations (cfp files) - this is 95% complete - unfortunately the remaining 5% relies on discovering the contents of a 254 element floating point array that decodes the animation data file.
• Support for displaying furniture-like objects (iff files) - it would be difficult to get a character to sit down, if you cannot see the chair!
• Screen capture - for stills and animation loops

There are NO promises as to when (or if) such enhancements will become available

Thanks to

• Maxis for an excellent and inspiring game
• The folk at SImLane for hosting this site
• Keith Young, for hosting the original SimPose-ium page and SimPose-ium forum
• Aladrin Kelahn and Scott McDonnell, at SimWorkshop for all sort of technical hints and tips
• Scott Heiman, for the DirectX window for Borland's C++ windows library

Contact me here: sim@pygott.demon.co.uk