Appendix: Animation Guidelines

Rigs for models for StarCraft II can be very flexible. As long as the data can be distilled to a value on a controller at a time, the Exporter will try its best to acquire and export that value. Transforms, Material Properties, and Properties on StarCraft II specific Nodes can all be animated.

Bones

• The case-insensitive prefix "bone_" can be applied to an otherwise exportable geometry to make it export as a bone only. The geometry on it will be ignored.

• The presence of the case-insensitive text "foot" in a bone object name will tag the hierarchy of bones leading up to it to be compressed less aggressively. This can be used to prevent foot-sliding artifacts from animation compression.

• Any transform in a hierarchy can potentially become a bone at runtime. The StarCraft II Exporter reserves the right to collapse away bones it deems unnecessary.

• The boneScaleType property on 3ds Max bones is not supported, and must be set to #none for all bones if you want to accurately see what your mesh will look like in game while inside 3ds Max.

Skin Weights

• Nodes in Max can be animated directly. StarCraft II does not require an explicit skeletal hierarchy.

• Geometry can be linked to a control bone as an explicit rigid bind. The exporter will collapse unanimated transforms where it deems it reasonable.

• The mesh is assumed to be at bind pose at Frame 0.

• Skin Modifiers can be used as well, but with a maximum of 4 influences per vertex. In the case of more than 4 influences, the 4 largest weights will be used.

• Skin weights are always normalized.

Controllers

• Controllers for Node transforms and animatable parameters on StarCraft II Nodes and Materials will be exported.

• Any controller that can be consistently queried at an arbitrary time should work with the StarCraft II Exporter. The "at time" MaxScript command can be used to check this behavior.

• All controllers are frame-sampled at export if keyframes cannot be properly resolved.

Animation

• Frame 0 must be clean. It should be static and at bind pose. Odd deformation and scaling issues can occur if this is not the case.

• Because Frame 0 must be clean, all animations should occur in positive frame rangers.

• No two animations are allowed to have overlapping frame ranges, and no two animations should ever share a starting or ending frame. Many tools are liable to break, and data may be lost, if this restriction is not honored.

• No transform can be animated to have a scale of 0. This will produce invalid animations and the Exporter will complain.

• Looping animations should avoid large, identifiable movements during the first few frames. When a new animation is triggered, the animation system overlays it on top of the existing animation. Large motions can often bleed through, producing unwanted visual effects. Fade times can be defined in Data to counteract this when desired.