MDL file

From Wiki

Jump to: navigation, search
Line 124: Line 124:
 
!colspan=2|32bits
 
!colspan=2|32bits
 
|-
 
|-
|-NC-||-00-
+
||-NC-||-00-
 
|}
 
|}
  
Line 140: Line 140:
 
!colspan=2|32bits
 
!colspan=2|32bits
 
|-
 
|-
|-ID-||-NF-
+
||-ID-||-NF-
 
|}
 
|}
  
 
  ID
 
  ID
This 16bit value identifies the context of the animation. For instance, 0 for an "idle" animation. 4 for an "open" animation (eg. a door.) The meanings of the IDs appear to be implicit rather than conventional. Ie. they are hard wired into ''Sword of Moonlight'' itself. For a complete list of known IDs, see [[MDL (file format)/Appendix A (animation IDs)]].
+
This 16bit value identifies the context of the animation. For instance, 0 for an "idle" animation. 4 for an "open" animation (eg. a door.) The meanings of the IDs appear to be implicit rather than conventional. Ie. they are hard wired into Sword of Moonlight itself. For a complete list of known IDs, see [[MDL (file format)/Appendix A (animation IDs)]].
  
 
  NF
 
  NF
This 16bit value is an accounting of the number of frames comprising this animation. The frames are not interpolated over time, and appear at regular intervals. There is no standard reference in terms of timing. However traditional (eg. original ''Sword of Moonlight'' files) playback speed is approximately 30 frames per second (reports exist that [[PRF]] files are useful for modulating playback in some way unclear / not well documented)
+
This 16bit value is an accounting of the number of frames comprising this animation. The frames are not interpolated over time, and appear at regular intervals. There is no standard reference in terms of timing. However traditional (eg. original Sword of Moonlight files) playback speed is approximately 30 frames per second (reports exist that [[PRF]] files are useful for modulating playback in some way unclear / not well documented)
  
 
<ifieldset class="spec">
 
<ifieldset class="spec">
<legend class="tech">1st Tinman ANIMATION FRAME
+
<legend class="tech">THE PER (Tinman) ANIMATION FRAME BUFFER
===Variable length frames===
+
===The per animation frame buffer===
 
</legend>
 
</legend>
  
</ifieldset>
 
<ifieldset class="spec">
 
<legend>⋯</legend>
 
</ifieldset>
 
<ifieldset class="spec">
 
<legend>Nth Tinman ANIMATION FRAME</legend>
 
 
</ifieldset>
 
</ifieldset>
  

Revision as of 16:58, 6 April 2011

<legend class="caps">

Header

</legend>

16 8bit bytes in total
LF HA SA TB PC 00 -16- PCSZ -16- HASZ SASZ

<ifieldset class="spec"> <legend> swordofmoonlight.h </legend>

LF: leadflags perhaps bitwise flags
HA: hardanims JointMIMe-like animation (PSOne)
SA: softanims Vertex/normalMIMe-like animation
TB: timblocks Textures (PSOne TIM image format)
PC: primchans one or more required (meshes)
00: unknown00 perhaps always one
PCSZ: primchanwords dword anims block offset (could be 32bit)
HASZ: hardanimwords dword sizeof anims block
SASZ: softanimwords dword sizeof diffs block

</ifieldset>

LF

This byte is not super well understood. It is either a straight value, or a bitwise combination of flag values. Known values are 0, 1, and 4. For not animated, Tinman style animation, and Scarecrow style animation respectively.

HA ¦  SA

These bytes are the number of hard and soft (aka. Tinman/Scarecrow) animations contained within the file.

TB

This byte is the number of PlayStation TIM images embedded within the file. These images are used as textures. It seems that the EneEdit tool somehow overrides the use of the embedded images, in favor of external TXR images which it is able to generate (please note that the author himself is uncertain the accuracy of this claim!!)

PC

This byte is the number of sub headers in the file, of which there is one of per each separate section of geometry (a MDL may include many such sections.)

PCSZ ¦ HASZ ¦ SASZ

These three 16bit values indicate the size of the first three data blocks. The units are in 32bit intervals. In other words, a value of 4, indicates 16 bytes. Each block begins after the previous block, therefore it is necessary to sum the preceding blocks in order to arrive at the offset to any given block. There is a fourth block, which runs to the end of the file. The four blocks respectively pertain to 3D geometry, Tinman animation, Scarecrow animation, and TIM images. The TIM images themselves can consecutively be thought of as 4th, 5th, and so on blocks. It's a matter of personal interpretation.

<legend class="tech">1st PRIMITIVE CHANNEL

Primitive channels

</legend>

7 32bit words in total
- -VB- - - -VC- - - -NB- - - -NC- - - -PB- - - -PC- - - -00- -

<ifieldset class="spec"> <legend> swordofmoonlight.h </legend>

VB: vertsbase dword offset to vertex block
VC: vertcount
NB: normsbase dword offset to normal block
NC: normcount
PB: primsbase dword offset to face block
PC: primcount
00: unknown00 probably always zero

</ifieldset>

VB ¦ NB ¦ PB

These three 32bit (the alignment is 32bit, the values themselves may be 16bit) values are offsets which should be added to the end of the header (or the beginning of the first primitive channel sub header) in order to reach the beginning of the Vertex/Normal/Primitive (face) data belonging to this primitive channel. Part of the #Per vertex location, #Per vertex lighting, and #3D primitives blocks respectively. The units are in 32bit intervals. In other words, a value of 4, indicates 16 bytes. The offsets are absolute, which is to say, not relative to one another.

VC ¦ NC ¦ PC

These three 32bit (the alignment is 32bit, the values themselves may be 16bit) values account for the number of elements expected to be found within the data indicated by VB, NB, PB respectively.

<legend>⋯</legend>

<legend>Nth PRIMITIVE CHANNEL</legend>

<legend class="tech">3D PRIMITIVES BLOCK

3D primitives

</legend>

<legend class="tech">PER VERTEX LOCATION BLOCK

Per vertex location

</legend>

<legend class="tech">PER VERTEX LIGHTING BLOCK

Per vertex lighting

</legend>

<legend class="tech">Tinman ANIMATIONS BLOCK

Tinman animations

</legend>

32bits
-NC- -00-
NC

This 16bit value accounts for the total number of animation channels. A channel may have primitives associated with it or not. Channels are arranged hierarchically / outwardly from a single top-level channel. When one channel is animated, the effect is applied accumulatively to the subordinate channels.

00

This 16bit value is not understood. It may always be 1.

<ifieldset class="spec"> <legend class="tech">1st Tinman ANIMATION

Animations by ID

</legend>

32bits
-ID- -NF-
ID

This 16bit value identifies the context of the animation. For instance, 0 for an "idle" animation. 4 for an "open" animation (eg. a door.) The meanings of the IDs appear to be implicit rather than conventional. Ie. they are hard wired into Sword of Moonlight itself. For a complete list of known IDs, see MDL (file format) / Appendix A (animation IDs).

NF

This 16bit value is an accounting of the number of frames comprising this animation. The frames are not interpolated over time, and appear at regular intervals. There is no standard reference in terms of timing. However traditional (eg. original Sword of Moonlight files) playback speed is approximately 30 frames per second (reports exist that PRF files are useful for modulating playback in some way unclear / not well documented)

<ifieldset class="spec"> <legend class="tech">THE PER (Tinman) ANIMATION FRAME BUFFER

The per animation frame buffer

</legend>

</ifieldset>

</ifieldset> <ifieldset class="spec"> <legend>⋯</legend> </ifieldset> <ifieldset class="spec"> <legend>Nth Tinman ANIMATION</legend> </ifieldset>

<legend class="tech">Scarecrow ANIMATIONS BLOCK

Scarecrow animations

</legend>

<legend class="tech">1st PlayStation .TIM IMAGE

TIM imaging

</legend>

<legend>⋯</legend>

<legend>Nth PlayStation .TIM IMAGE</legend>