Bump maps

[Darth InSidious]

Warning: Thread contains semi-technical gobbledegook. Prior reading is suggested as follows:

http://www.lucasforums.com/showthread.php?p=1866325&highlight=bump%2C+bumpmap%2C#post1866325

http://www.lucasforums.com/showthread.php?p=2726680&highlight=bumpmap#post2726680

http://www.lucasforums.com/showthread.php?p=2272433&highlight=bump%2C+bumpmap%2C#post2272433

http://www.lucasforums.com/showthread.php?p=1899966&highlight=bumpmap#post1899966

http://web.archive.org/web/20080527213705/http://ccg.dladventures.com/index.php?title=Textures&printable=yes

 

All right, as everyone knows, bump-mapping in the KotOR games only works under certain circumstances, which means the devs could make it work and we can't at present.

 

In order to try and address this in part, I've been oing a bit of examination of the difference between the .tpc and .tga of a sample bump texture (DAN_Flr3B) in a HEX editor.

 

So far, I have three observations:

1. The files are different lengths, the .tpc ending at line 555FA, the .tga at line 5560B.

 

2. Different file beginnings (headers?). The .tpc file begins:

 

00 00 00 00 00 00 80 3F 00 01 00 01 04 09 00 00 00

 

Whereas the tga file begins:

 

00 00 02 00 00 00 00 00 00 00 00 00 00 01 00 01 20

 

Further, the .tpc file, following the first line, has 6 lines (lines 11 - 66) blank, and begins at column 10 on line 77; the .tga file begins at column 2 on line 11.

 

3. File endings. Both files end with the following .txi information:

isbumpmap 1 bumpmapscaling 2 xbox_downsample 128

 

However, the .tga file repeats this information twice, and has at appearing once well before the end of the file.

 

The file to which Flr3B is a bumpmap - DAN_Flr3.tpc has the same or a similar break at the start of the file, and ends:

 

envmaptexture

CM_Baremetal

 

.TGA files I have edited with GIMP, however, end with:

 

TRUEVISION-XFILE.

 

A similar pattern in the .tpc files' beginnings and endings was found in the KotOR 1 copies of V_EHawk01 and V_EHawk01b , although the extrated .tga of V_EHawk01 does not have the ending plain-text.

 

A comparison of DAN_Flr3B and V_EHawk01b reveals similarities, too. The main body of both files begins similarly. V_EHawk01b begins:

 

7D 83 FE FF 80 86 FE FF

91 6E FC FF 86 81 FE FF 86 83 FE FF 8A 89 FE FF 94

 

DAN_Flr3B begins:

 

80 7B FE FF 77 83 FE FF

7B 84 FE FF 84 80 FE FF 86 80 FE FF 84 80 FE FF 84 80 FE FF 84

 

Both files also end similarly, repeating 80 80 FF 3F before the "isbumpmap", etc. part.

 

Whether this actually advances us at all, I don't know, but I thought I'd share it.

[Quanon]

We'll need someone who can read this Hex code jumble... You could try and replace parts in the TGA with TPC code. You know like what we do with the head models. Copy hex bits from one file to another.

[VarsityPuppet]

We'll need someone who can read this Hex code jumble... You could try and replace parts in the TGA with TPC code. You know like what we do with the head models. Copy hex bits from one file to another.

 

Unlikely. It did help that mdl files were at least in the same format, tpc and tga are considerably different (from what I understand anyways)

 

Once upon a time, I talked with stoffe about such things, and she said that tpc files are basically direct draw (dds I think) with a custom header. The reason a tpc2tga converter exists is because not all the information in tpc is required to generate a tga file. That's what I understand anyways.

[magnusll]

It might be interesting for you to know that Kotor's graphic engine requires all textures to be generated using the same faces used by the geometry of the object.

 

Normally when the objects get generated in 3DSMax whatever textures apply to them (e.g. lightmaps) will use their own faces. However the structure of the .mdx files requires the information about those textures to be relayed using a list based on the number of vertices and faces used by the model geometry. This means if the faces of one or more of the textures are a different number, a conversion process is required to "remap" the texture faces to the original geometry faces. That's what gave me big headaches while including them in KAurora.

 

How that would make your bumpmap invalid instead of simply mangled, however, I've no clue...