EvilEngine/PIPT: Difference between revisions
Battlepedia>Seil No edit summary |
Battlepedia>Igorseabra4 No edit summary |
||
Line 5: | Line 5: | ||
==Format== |
==Format== |
||
The pipe information contains additional material |
The pipe information contains additional material information for level objects. The file starts with an int which defines the amount of entries, then each entry has the following layout, being 0x0C bytes long in BFBB and 0x10 in Movie: |
||
{| class="wikitable" |
{| class="wikitable" |
||
Line 12: | Line 12: | ||
| 0x00 || int || [[AssetID]] || [[MODL]] |
| 0x00 || int || [[AssetID]] || [[MODL]] |
||
|- |
|- |
||
| 0x04 || int || |
| 0x04 || int || unknown || Usually -1; might be mesh index in the model? |
||
|- |
|- |
||
| 0x08 || byte || Related to visibility? || |
| 0x08 || byte || Related to visibility? || |
||
Line 20: | Line 20: | ||
| 0x0A || byte || Destination/Source Blend || When one of the digits is set to 0, their default factors will be used instead. |
| 0x0A || byte || Destination/Source Blend || When one of the digits is set to 0, their default factors will be used instead. |
||
|- |
|- |
||
| 0x0B || byte || |
| 0x0B || byte || unknown || |
||
|- |
|||
| 0x0C || byte || unknown || Only present in Movie. |
|||
|- |
|||
| 0x0D || byte || unknown || Only present in Movie. |
|||
|- |
|||
| 0x0E || byte || unknown || Only present in Movie. |
|||
|- |
|||
| 0x0F || byte || unknown || Only present in Movie. |
|||
|} |
|} |
||
Line 38: | Line 46: | ||
* 0x0A - Inverse Destination Color |
* 0x0A - Inverse Destination Color |
||
* 0x0B - Source Alpha Saturated |
* 0x0B - Source Alpha Saturated |
||
===Movie Model Asset ID=== |
|||
One important detail in the PIPT asset in Movie Game is that, in some of the entries, the model [[Asset ID]] will be a hash of the model's name without the .dff extension at the end, being different from if it were hashed from the name with .dff. This can be noted in [[Industrial Park (level editor)|Industrial Park]]'s PIPT editor in which some of the PIPT entries refer to the model's name without .dff at the end: |
|||
[[File:PIPT editor important.png]] |
|||
It's unknown why this was done this way and whether having the entry reference a hash with .dff at the end will work or not. |
|||
[[Category:Asset]] |
[[Category:Asset]] |
Revision as of 16:22, 27 April 2019
PIPT | |
---|---|
Pipe Info Table | |
Type | Binary |
Games used | The Incredibles |
Format
The pipe information contains additional material information for level objects. The file starts with an int which defines the amount of entries, then each entry has the following layout, being 0x0C bytes long in BFBB and 0x10 in Movie:
Offset | Type | Description | Notes |
---|---|---|---|
0x00 | int | AssetID | MODL |
0x04 | int | unknown | Usually -1; might be mesh index in the model? |
0x08 | byte | Related to visibility? | |
0x09 | byte | Culling | |
0x0A | byte | Destination/Source Blend | When one of the digits is set to 0, their default factors will be used instead. |
0x0B | byte | unknown | |
0x0C | byte | unknown | Only present in Movie. |
0x0D | byte | unknown | Only present in Movie. |
0x0E | byte | unknown | Only present in Movie. |
0x0F | byte | unknown | Only present in Movie. |
Note: this applies to big endian (GameCube) only. The 4 bytes are reversed in little endian.
Blend factor types
- 0x00 - Source Alpha/Inverse Source Alpha
- 0x01 - Zero
- 0x02 - One
- 0x03 - Source Color
- 0x04 - Inverse Source Color
- 0x05 - Source Alpha
- 0x06 - Inverse Source Alpha
- 0x07 - Destination Alpha
- 0x08 - Inverse Destination Alpha
- 0x09 - Destination Color
- 0x0A - Inverse Destination Color
- 0x0B - Source Alpha Saturated
Movie Model Asset ID
One important detail in the PIPT asset in Movie Game is that, in some of the entries, the model Asset ID will be a hash of the model's name without the .dff extension at the end, being different from if it were hashed from the name with .dff. This can be noted in Industrial Park's PIPT editor in which some of the PIPT entries refer to the model's name without .dff at the end:
It's unknown why this was done this way and whether having the entry reference a hash with .dff at the end will work or not.