[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum

I gave up this task for a while because it became too hard to reverse. I've discovered much about .tint files, but I need to discover much more. What is known (I've attached some files for context):
1) These files are read separately from .mask files;
2) These files using one some 8 byte encoded texture file (diffuse? glow? specular? normal?);
3) These files have two blocks in each mipmap. Offset of second block are written in the very beginning of mipmap data section.
[attachment=1]
4) First block of data (except first int32 where offset is encoded) is control codes, second - indexes (what they exactly do I still uncovered);
5) These files require some sort of buffer, which is generated by client. This buffer is called unkFile in pseudo I've attached. I ve called it palette, but still unsure what it excatly do. IDA offset for palette generation: 0047B140;
6) Offset for IDA for possibly tint read function: 0048EB33.
[attachment=2]

I hope I will return to this later, now I want to apply my new discoveries to mesh viewer tool, which can never see the light if I will continue to work over .tint files...

Okay, .glow textures encoded the same way as diffuse. That's good, but I still dont understand how .tint textures are stored. The only thing that I ve discovered is that they're not bound to .mask files (at least they dont store .mask texture id at 0x9C which means that they dont need them to be read)

Btw, specular textures encoded the same way as diffuse. So only .glow and  .tint are left for decoding. Need to locate where client reads them.
 

Finally, I ve decoded these textures. I have to decompile .exe and look for texture reading function, after that I ve simply transferred decompiled C code into C# and decoded, what it actually does.
I was almost right about .mask files. But instead of storing missing data, they store control byte codes, which says to client, how much blocks it should skip or read (or read .diffuse and alpha, stored in mask) and alpha channel blocks. I ve got working prototype of program for reading such textures.

[unk_word_00]

Hey Olly,

I'm still working on my little tool, but unfortunately I'm stuck on this very same issue you're having here. To my current understanding it's not possible to extract most of the DIFFUSE textures properly, because...they are simply missing data (entire DXT blocks to be more specific). If you have 512x512 DXT1 texture with 10 mip maps, it requires exactly 174,944 bytes to store all the data (along with DIFFUSE file header). If size is less than that it looks like this:



Notice two things here:

1. The yellow row of pixels at the bottom are the missing blocks. This particular texture is missing 190 4x4 blocks in its largest mip map and some more in two lower ones as well.
2. Texture is distorted in the middle. This suggest the place these blocks are missing from (not necessary in contiguous blob of pixels though).

Having said that, I still have absolutely no idea how to get this data back. Is this some form of compression? Did they remove random pixels to protect textures from extracting? If so, where the hell are they...

2. unk_word_00 and unk_word_01 should be used somehow to handle shifts in rect. images

This I was able to figure out at least. unk_word_00 and unk_word_01 are offsets (on x and y axis respectively) in pixels from texture's top left corner. For some weird reason Mythic decided to chop up certain textures into multiple pieces and this is the effect of this operation. Here's one example:



Overall dimensions of this texture are 512x512, but the largest mip map has only 176x260 pixels and the offsets are (336, 252). By default all texture data will start at (0, 0), so basically you need to take every pixel and move it by this amount on x and y. I've tested this with converted model and this is exactly where UV coordinates are for this particular piece.

Apologize for necroposting, but have you succeed in this? I've been working over texture reading and faced same problems. I think missing data could be stored in  .mask files near diffuse.