[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum | Modifications | 3D Scenery Models
Warhammer Age of Reckoning Modding

[Derezz]

Hello, I'm new to python, I don't want to be irritable, I know that everything is very clear,but not experience does its own thing, I would like to ask for help, if possible, could you explain to me how to do it correctly?
 I open cmd and
CD C:\Python26\Lib\idlelib
then geom2obj.py fg.0.0.cre_lion_white.geom
but I don't have anything going on, no error, no file, couldn't tell what my mistake might be? please

[olly]

Hi and welcome. Check that the .geom file exists in that folder location and after checking try another .geom file name that is in that folder to convert. Are you sure it didnt successfully convert that .geom ?

[Derezz]

Thank you for your answer, all the files are in place, and the scripts, here I have a screenshot, at the moment some text appears, but unfortunately there is no obj file, what could be the problem? or am I doing something wrong?

[olly]

Your screenshot above suggests are you not typing the file extenstion .geom on the end of the file name

geom2obj.py fg.0.0.cre_harpy_01.geom

and check you have full permission on that folder and maybe try running CMD command prompt as administrator.  

[Derezz]

everything works, thanks for the help

[AlastarI]

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.

[olly]

Hi, it's been a long time since I last tried or checked if there were any updates, would be amazing if you succeeded.

[AlastarI]

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.

[olly]

Fantastic news and well done!

[AlastarI]

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.
 

[olly]

Cool

[AlastarI]

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)

[olly]

Interesting and one step closer to completion.

[AlastarI]

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.

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.


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...

[olly]

Excellent work and keep us posted on the mesh viewer new addons.