From LBA File Information
|Programs supporting this format|
ANM files contain 3D object animations.
|This page may need some cleanup. It should be reformatted to use wikitext instead of <pre> tags.|
Lba1 Animation File Format Specification Abstract: The characters in LBA are animated using a skeletal transformation system. for further details of such systems, i refer to the wikipeda article. http://en.wikipedia.org/wiki/Skeletal_animation LBA defines bones using a pivot vertex (part of the mesh geometry) and three parameters (euler angles or cartesian offset respectively). The bones are defined in the model file (consult the model file specification). Animations are defined as a row of keyframes, each defining the complete state of the skeleton for a specific point in time. aside of the skeletal state the animation also defines the velocity of the character in a local cartesian coordinate system. you won't find a line of code in the twin engine commanding twinsen to move vertically while climbing up/down a ladder. it's all defined in the climbing animation. Table of content: 1) general file structure 2) file header 3) keyframe header 4) bone entry 5) comments & open-end questions 1) general file structure a) file header (8 bytes) b) for each keyframe in file: keyframe header (8 bytes) for each bone in keyframe: bone entry (8 bytes) 2) file header a) number of keyframes (unsigned 16bit) b) number of bones (unsigned 16bit) the number of bones defines the size of all keyframes, because in every keyframe every bone state is defined. c) loop entry #1 (unsigned 16bit) d) loop entry #2 (unsigned 16bit) in most LBA animations, there's a short intro sequence. for example in the intro sequence of Twinsen's running animation Twinsen swings his leg forward and leans backward while accelerating. after this entry sequence the normal running loop runs endlessly. The animation defines an entry frame in which the looping part of the animation begins. all frames before this entry frame belong to the intro sequence. after it has passed the last frame of the animation, the "read head" jumps back to the entry frame. Strangely the entry frame seems to be defined twice. at least in all animation files (about 20-30) i examined these two file entries contained the same value. 3) keyframe header a) length of keyframe (in milliseconds?) (unsigned 16bit) b) character velocity x component (signed 16bit, formatted in LBA fixed point format) c) character velocity y component (signed 16bit, formatted in LBA fixed point format) d) character velocity z component (signed 16bit, formatted in LBA fixed point format) These 3 components define the velocity vector in this keyframe. LBA later interpolates the velocities between two keyframes linearly. 4) bone entry a) type (unsigned 16bit) possible values: 0 The three parameters of this bone define his rotation in local cartesian coordinate system of the character using euler angles. else The three parameters of this bone define an offset in local cartesian coordinate system of the character. b) parameter X (signed 16bit) c) parameter Y (signed 16bit) d) parameter Z (signed 16bit) Cases: da) Rotation Bone The three parameters define a rotation using euler angles. the formatting of the angles works this way: Value in file | degrees | radian _______________________________________ 0 | 0 | 0 256 | 90 | pi/2 512 | 180 | pi 1024 | 360 | 2*pi The X angle specifies the rotation around the local cartesian X axis, the Y angle rotation around local Y axis a.s.o. NOTE: I had to invert the Y angle to get the right rotation (mine first was mirrored) but i'm not sure whether LBA is using a right handed coordinate system or if i made a mistake somewhere. To get the correct end position the rotations have to be done in the order X Y Z (euler angles are only unambiguous if the order is sustained) db) Offset Bone The three parameters define an offset in local cartesian coordinate system of the character. The values are formatted as LBA fixed point numbers. 5) comments The bones in the mesh are NOT ordered like a tree in memory ( which would be: child node/leaf directly follows its parent node in memory). Therefore the bone states aren't either. open-end question: why is the loop entry frame in each keyframe defined twice, as described above? --- This specification has been written by Omni ---
Information provided by: Omni