IFP

Материал из GTAModding.ru
Перейти к: навигация, поиск

IFP - это анимационный формат серии игр GTA, начиная с GTA III. В GTA: SA используется новая версия формата, хотя игра поддерживает и старую. IFP-файл может содержать несколько отдельных анимаций, которые разделены на объекты и связаны с анимированными персонажами и / или объектами. Каждый объект содержит некоторое количество кадров.

Содержание

Спецификация

Анимационные пакеты имеют простую иерархию, не меняющуюся от версии к версии. В основном, каждый анимационный файл состоит из заголовка хранения общей информации о файле.

Каждая анимация состоит из нескольких объектов. Каждый объект содержит список кадров, то есть информацию о положении объекта в пространстве и его размерах.

IFP
 |
 |
 +---Анимация
 |       |
 |       +---Объект
 |       |      |
 |       |      +---Кадр
 |       |      +---Кадр
 |       |
 |       +---Объект
 |              |
 |              +---Кадр
 |              +---Кадр
 +---Анимация
         |
         +---Объект
                |
                +---Кадр
                +---Кадр

Типы данных

По умолчанию анимационные пакеты используют следующие типы данных:

  • CHAR - символьный тип (1 байт);
  • INT32 / UINT32 - 32-разрядное целое число со знаком / без знака (4 байта);
  • FLOAT - c плавающей запятой (4 байта);
  • TVector3 - FLOAT[3] (12 байт);
  • TVector4 - FLOAT[4] (16 байт).

Version 1

Strings

Even though strings are null terminated they are aligned to a 4 byte padding what means that their length (including the terminating zero byte) must be a multiple of 4. The trailing bytes are usually zero, too. The following part of the article uses TString for identifying string types. All those strings are following the rule descriped in here.

Data structures

Version 1 packages are introducing some additional data structures. Those are always indicated by an 4 byte constant length string. The following table lists the different data structures and their formats. All data structures are inherting from an abstract base data structure. This base data structure must not be used inside the file (also this would not make sense since it does not hold any data except information about identifying itself). The whole file follows this rules so animation package itself can be seen as one section.

Structure and descriptionSpecification
BASE
Abstract base section.
(8 byte)
identifier  : CHAR[4]
offset      : UINT              // offset to the end of the section
// Note: Offsets are always relative to the current file position.
ANPK
Major section of the file.
information : INFO<TAnimation>  // section information data (see below)
INFO<T>
Collection of multiple sub sections of type T.
entries     : INT32             // (count of encapsuled sections)
name        : TString           // (name of the collection)
sections    : T[entries]        // Subsections
NAME
Holds an string.
name        : TString
DGAN
Holds data for TAnimation.
anim. info  : INFO<CPAN>
CPAN
Holds data for animation objects.
object info : ANIM
ANIM
Holds data for animation frames.
object name : TString           // Also the name of the bone.
// Note: Because of this fact that this string uses 28 bytes by default.
frames      : INT32             // Number of frames
unknown     : INT32             // Usually 0
next        : INT32             // Next sibling
prev        : INT32             // Previous sibling
frame data  : KFRM
KFRM
'Abstract' section inherting from BASE and representing a frame type.
There are 3 known specialisations of this base structure: KR00, KRT0 and KRTS.
time key    : FLOAT             // This value is the last one of the specialised sections.
KR00
Inherting from KFRM and defines an collection of rotated frames.
(Offset - 4) / 16 = X
rot         : TVector4[X]       // Rotation as quaternion
KRT0
Inherting from KFRM and defines an collection of rotated and translated frames.
(Offset - 4) / 28 = X
{
  rot       : TVector4          // Rotation as quaternion
  pos       : TVector3          // Translation
}[X]                            // Repeated X times.
KRTS
Inherting from KFRM and defines an collection of rotated, translated and scaled frames.
(Offset - 4) / 40 = X
{
  rot       : TVector4          // Rotation as quaternion
  pos       : TVector3          // Translation
  scale     : TVector3          // Scale
}[X]                            // Repeated X times.

Note: The sections are listed in the order they appear inside the file for better understanding.

Animation

The data structures descriped above can be used to define the data structure for animations. Note that TAnimation does not inherit from BASE. Offset information are stored inside the encapsuled animation data.

Structure and descriptionSpecification
TAnimation
An animation entry of the package.
(8 byte)
anim. name  : NAME
anim. data  : DGAN

Exact version 1 hierarchy

The following tree shows an basic hierarchy of an version 1 animation file:

ANPK
|
+-- INFO<TAnimation>
     |
     +-- NAME/DGAN
     |         |
     |         +-- INFO<CPAN>
     |         |    |
     |         |    +-- ANIM
     |         |    +-- ANIM
     |         |    +-- ...
     |         |
     |         +-- ...
     |
     +-- ...


Version 2

Version 2 archives got basically the same hierarchy as above, but the structures are a bit different. In version 2 all strings are null-terminated, but they got a constant size of 24 bytes.

Header

4b   - FourCC   - 'ANP3' (Animation Package 3, Version identifier. However there is no pack with ANP2)
4b   - Int32    - Offset to end of file
24b  - Char[24] - internal file name used in the script
4b   - Int32    - Number of Animations

Animation

24b  - Char[24] - Animation Name
4b   - Int32    - Number of Objects
4b   - Int32    - Size of frame data
4b   - Int32    - Unknown, always 1

The size of data value is a number of bytes which corresponds to the exact size of the frame's usable data, including the compressed coordinates and rotation info.

Object

24b  - Char[24] - Object Name
4b   - Int32    - Frame type: Child = 3, Root = 4
4b   - Int32    - Number of Frames
4b   - Int32    - Bone ID

Frame

Root frames usually follow the following structure:

2b   - Int16    - Quaternion X
2b   - Int16    - Quaternion Y
2b   - Int16    - Quaternion Z
2b   - Int16    - Quaternion W
2b   - Int16    - Time (in seconds)
2b   - Int16    - Translation X
2b   - Int16    - Translation Y
2b   - Int16    - Translation Z

Child sections normally have no translation values:

2b   - Int16    - Quaternion X
2b   - Int16    - Quaternion Y
2b   - Int16    - Quaternion Z
2b   - Int16    - Quaternion W
2b   - Int16    - Time (in seconds)

To convert quaternion and translation values to floating values divide them by 4096 and 1024, respectively.

External links