XeNTaX

Hello, yes it's me again. I am aware that this game is pretty much done and dusted. Nearly everything is extractable except for animations. (but that's a seperate thread)

Now, while the people who were working on this game were incredibly diligent in their efforts, they left one thing incomplete: the UV maps for meshes.

Currently only characters have proper UVs, everything else is either borked or has no UVs at all. For example, the vehicle UVs are the ones they use for damage mapping, not their actual texture.
With the exception of characters, the broken vehicles, and a few weapons, everything else has absolutely no UVs. The actual meshes turn out just fine, but all UV coordinates are zero/nonexistent.

I realize it's a very slim chance, but is there anyone who could fix this?

Here's several sample files of each type: Vehicle, Tire, Weapon, Prop, and Building.

And here are all the already existing tools:
Ekey's .BIG Unpacker (for any extra samples)
Shakotay's Extractor (mesh only)
Howfie's .DDS Extractor (textures only)
Marisuz's Blender Importer (mesh, rigging, textures, UVs, materials)

Both tools are compiled, so they cannot be edited by others.
You should speak with the people who created them, it's likely that cars simply need a second UV channel, which should be a very simple matter.

Ekey, Howfie and Marisuz all got bored and quit a long time ago.

I already spoke to Shakotay, he wasn't able to figure it out. But you're right, maybe he'll be willing to share his source code.

And the blender importer is just a script, here's a direct link for convenience.

SergeantJoe wrote:But you're right, maybe he'll be willing to share his source code.

That's not a problem of the source code. If I remember exactly it extracts most of the UVs. For the ones it does not it's a problem of where the uv data is stored in the model data and how it is structured.
Since this is not solved in the source code it wouldn't help you either.

Chipicao wrote:[...]it's likely that cars simply need a second UV channel, which should be a very simple matter.

Of course. Then can you tell me why Mariusz (Szkaradek, who has very best experiences in this) didn't implement it in his script?

Or even better: since this being "very simple" then why not improve Mariusz' script?

shakotay2 wrote:That's not a problem of the source code. If I remember exactly it extracts most of the UVs. For the ones it does not it's a problem of where the uv data is stored in the model data and how it is structured.
Since this is not solved in the source code it wouldn't help you either.

The point was that even if someone else knew where's the other UV data and how it is structured, they couldn't just edit existing tools without their source code.
And for the record, the blender script in the 1st post was not plain text.

Chipicao wrote:The point was that even if someone else knew where's the other UV data and how it is structured, they couldn't just edit existing tools without their source code.
And for the record, the blender script in the 1st post was not plain text.

Well, true. I should've just uploaded the script by itself right away, but I wasn't sure if the .blend file had anything special in it.

shakotay2 wrote:Then can you tell me why Mariusz (Szkaradek, who has very best experiences in this) didn't implement it in his script?

He probably didn't even realize the problem was there. Only police vehicles, buses, etc have this issue. And besides, his comment said it was intended for characters only. Everything else still somewhat works, but they weren't his main focus.

shakotay2 wrote:Of course. Then can you tell me why Mariusz (Szkaradek, who has very best experiences in this) didn't implement it in his script?

Or even better: since this being "very simple" then why not improve Mariusz' script?

Maybe you should ask him instead of being a smartass.

UV2 mapping coords:


In the sample file Klienod01.perm.bin, vertex buffer at offset 245440 contains 2 pairs of half floats. This is easy to spot because uint32 @offset 245324 is "8", indicating an 8byte vertex stride, instead of 4 like other UV vertex buffers.

So as I was saying, this should be a very simple matter, especially for someone "who has very best experiences in this". In Mariusz's defense, he probably didn't care - I mean no offence to him, he did a great job. But what's your excuse?


Question: doesn't either tool extract normals??

Chipicao wrote:But what's your excuse?

I'm not here to quarrel with people.
So take over the work if you want and calm down.
But don't expect any comment from me on this matter. Thx.

shakotay2 wrote:But don't expect any comment from me on this matter. Thx.

Haha that boat has long sailed when you "commented" on my remark about how easy it should be to get UV2. You acted as if I was talking crap and now you say you don't want to quarrel with people?!

If however I misunderstood your first post in this topic, you have my apologies.

Chipicao wrote:If however I misunderstood your first post in this topic

Obviously you did.
Also if you had tried my tool on Klienod you'd seen that it is capable of what you posted previously:
Klienod01_LOD_2.obj
# uv type: 8
# 0x3BEC0-3D838
vt 0.756836 0.256836
vt 0.766602 0.283203
vt 0.725098 0.288086

It was just your starting with "very simple" what led to my response.

So take over the work or let it be.

shakotay2 wrote:Also if you had tried my tool on Klienod you'd seen that it is capable of what you posted previously:
Klienod01_LOD_2.obj
# uv type: 8
# 0x3BEC0-3D838
vt 0.756836 0.256836
vt 0.766602 0.283203
vt 0.725098 0.288086

Excuse me but being capable of identifying a "type 8" UV block is not the same as actually reading both sets of UV coords, which is what the OP wants, which is what we've been talking about.

shakotay2 wrote:It was just your starting with "very simple" what led to my response.

What part of reading 4 values instead of 2 isn't "very simple"?
Screw it, don't answer. I'm tired of this BS.

Awesome find with second UV set!

What about the rest of the stuff though? Everything else has only one set of UVs, but they must be in a different location or format or something if the existing tools can't pick them up.

As soon those errant UVs are caught we can finally be done with this once and for all.

Any luck?

I tried to modify the Blender script myself based on the given information, but I'm afraid don't have nearly enough experience to make heads or tails of this whole business.

I replaced the dummy uvs in Klienod01_LOD_2.obj at 0x60B20:


Imho it's not the 2nd uv channel - it's just the uvs for submesh_3_1.

Don't know whether they fit to the texture. If not that might be the reason I dummied them.
(As you know I closed this project some months ago.)

Did you have a look at Klienod01_LOD_0.obj, submemsh_1_1?

The uvs are slightly different from the ones for the submesh_1_1
in Klieno01_LOD_2.obj.

Don't worry about it, Chipicao figured it out.

Here's the fixed UV section of the Blender script. Unfortunately vehicle interiors still have no UVs, but those can be obtained with Shako's program.

shakotay2 wrote:I replaced the dummy uvs in Klienod01_LOD_2.obj at 0x60B20:


Imho it's not the 2nd uv channel - it's just the uvs for submesh_3_1.

Don't know whether they fit to the texture. If not that might be the reason I dummied them.

I think those were correct. They seem to fit the texture, only upside down.

Interestingly, your program manages to get the interior UVs for all models except the Klienod.


But that's just the vehicles. What about buildings/tires/weapons? Neither script nor the program can extract the UVs for those.

EDIT: Yeah, I'm pretty sure those use a different format. I'm looking at them in a text editor and there's a clear difference between the material data blocks. It doesn't even look like they have UVs at all!