Sansal,
I tested your tool and tried to extract, modify and import back some objects and I see now why there is a problem with textures for reinserted objects.
Both lurbz's DATNavogator and your tool do not extract/write back the full information concerning 3D-object faces. This becomes a problem for objects which use more than one texture plate, such as hull+deck+bridge/superstructure which come together in a single block/combined object for all the ships in SH3.
Here is an extract from the lurbz's description of Type 1: 3D chunk
Quote:
triangle data: there are ntri triangles and their texture mapping, each one is as follows
vertex1: unsigned 2-byte int
vertex2: unsigned 2-byte int
vertex3: unsigned 2-byte int
texture coord1: unsigned 2-byte int
texture coord2: unsigned 2-byte int
texture coord3: unsigned 2-byte int
????????????: one byte
|
The byte with question marks which lurbz could not identify is actually the texture plate number out of those used for the object. Say, usually three textures are used for the hull+deck+bridge object of the SH3 ships, their numbers will be 0,1,2, respectively. The texture number is written in the faces section in the 13-byte step.
This needs to be taken into account in the tool upon extracting/importing objects. It is also important to find the way to take this into account when entirely new object using a few texture plates is imported as a part of the entirely new model, created externaly by some other program.