This is a demo of the rig I built for Erica from Til Morning’s Light, developed at Wayforward Technologies.
All animation credit goes to Chris Kerlegon at Wayforward Technologies
Music Source
Erica Rig
Leave a reply
Tag Archives: Rigging
Managing Interactive Game Props
An interactive prop in a game would be any animatable object in the game world that a character interacts with. As an example, to implement a player turning a valve, the player must be positioned at the right place with respect to the valve. Both interaction animations (prop – ‘valve turning’ the player – ‘turning valve’) must be played in sync with each other. What programming needs to implement this:
- Some sort of locator node in the prop rig to determine the position of the player with respect to the valve. On pressing the ‘interact’ key somewhere close to the prop, the player will be interpolated to the correct position.
- The player animation and valve animation, both should be exactly the same in length. These can be played when the player is at the correct position.
The last time we used interactive props, the animators were setting this up manually. The process would involve importing the prop rig (exposing potential naming conflicts) and manually placing the tag in the prop rig at the correct position. Once the prop and character have been animated, they would need to saved out into separate files. This is a very time consuming and error prone process. The ‘Interactive Prop Manager’ tool was created to automate all this for animators. On the surface, the tool allows the animators to import a a prop into an animation file and work on the character and prop in the same scene in Max. In our example, the valve rig can be imported into the player rig scene and the animator can animate the interaction.
Step 1: Import prop – opens a file browser window to select a file. On import, the prop is placed in the scene using the character reference tag present in the prop file. This step also renames all the nodes in the prop file with a prefix to separate it from the character rig nodes for easy identification.
Step 2: Animate – Animator animates the character and rig.
Step 3: Export Prop – saves out the prop file as its own separate animation. The thing to consider here is that in the prop file, the prop is at the center of the scene, while in the character file, the prop would be offset due to the interaction. This offset is calculated using a non keyable prop root control curve. The prop root control curve will always stay in the center of the prop rig and can be used by the animator to place the prop within the the character rig file. The offset between the player reference tag and the prop root control curve will be the amount the prop scene would need to be moved in the prop rig after export. This offset will also move the player reference tag to the correct position.
the prop rig file
the player rig file, with the prop imported and offset based on ‘player reference tag’
Smooth IK setup
IK smoothing is used to soften the motion of the IK handle as the chain approaches full stretch. It can be set up in the 3ds Max by position constraining the IK handle to two targets with distributed weights. One target should be the IK control curve(CC in gif) and the other, an object placed at the position of the first bone in the IK(FB in gif) chain. The position weights need to be set as script controllers. Given the nodes CC and FB, we can calculate smoothing using the following script for the influence of CC –
Exponential Smoothing:
x = (distance CC FB) – Rmin
y = x
if x > 0 do
(
y = (D – Rmin)*(1-exp(-x/(D – Rmin)))
)
r = (Rmin + y)/(Rmin + x)
Trigonometric Smoothing:
x = (distance CC FB) – Rmin
L = Rmax – Rmin
y = x
if x > 0 and x < L do
(
y = (D – Rmin)*sin(90*x/L)
)
r = (Rmin + y)/(Rmin + x)
Rmin is the minimum radius of influence beyond which smoothing starts to take action. Rmax, used only for the trigonometric method and it defines the maximum distance CC needs to be from FB for the arm to be completely stretched out. These values are shown in the figure as the blue curved lines (which are actually circles with the center at FB)
The weight influence of FB can be set as 1 – Influence of CC.
I personally prefer the trigonometric method because it contains the extra Rmin attribute, giving the user more control. Also, it has a more natural motion as CC approaches Rmax.
Reverse FK rig
This rig was skinned to a snake like creature which needed to perform actions like slithering, rearing its head and whipping its tail to attack. A regular spline solution that is commonly used for these kinds of movement was just not cutting it, the involved animator insisted that a much higher quality of animation could be achieved via FK follow through technique. The problem? To animate follow through in a slithering animation, the FK hierarchy should go from the head(parent) to the tail(last child) while, for a rearing animation, the FK hierarchy would need to go in a reverse direction – the rig would need to have FK controls working in both directions. Here is a demo of my solution, the Reverse FK rig:
The only drawback that this rig faced was that the ‘Mid Point’ can’t be keyed in the middle of the animation. It breaks the existing animation of the control curves since the snapping option affects transforms their previously inactive parent objects. This was easily overcome by breaking apart the animation into separate files at the frame when the Mid Point changes. These animations were later stitched together in code.
Game Rigs: Controls vs Bones Hierarchy Abstraction
This might be blatantly obvious for experienced game TAs but since I had a hard time figuring this out when I started, I’ll leave this right here…
In most current engines, for a given animated entity, an animation is ‘played’ on a base rig. The base rig is the rigged mesh file with no animation data. In the engine, the animations are applied onto the base rig and what you see in game, will be an instance of this base rig. This base rig should ideally contain only the most essential objects required for it to run in game. These are just the bones and the skinned mesh. On the other hand, a rig that is handed over to animators would contain several control curves and dummy objects with complex relations to each other which drive the bone hierarchy through constraints( and not through parenting ). It is important to keep the hierarchy of these drivers completely separate from the bone hierarchy to observe somewhat of an ‘abstraction’.
So ideally, this is how the hierarchy in your rig should look like (3Ds Max schematic view for a simple Turret rig). When the rig is exported to engine, it should be stripped of all control curves (an animator level abstraction)
This kind of abstraction provides various advantages:
- Simpler hierarchies for game objects, easy parsing at engine side
- Art can go overboard on the amount of complication of the rig
- Rig iterations can be performed at two separate levels depending on the need. The engine might demand a different bone hierarchy than the animator