[release] SleepingDogs mesh extractor

[shakotay2]

For discussion I kindly beg to use this thread: http://forum.xentax.com/viewtopic.php?f ... 160#p88160
and leave this release thread for updates and format contributions.

This is a mesh extractor for SleepingDogs' *.perm.bin files.

### 7 years later, start, [www uploadmb com has ceased working] so I had to collect the 5 exes I had backupped.
########################################
SleepDogs_old.exe is for characters ONLY and the only version using thresholds (notcut/cut button).
########################################
.

SleepDogs_MeshExtractor.zip

Having a look into the *_log.txt file finding # threshold correction: off
means that the concerning exe doesn't use those values.

For sampan01 (fender, steering wheel), vertex type 12 I may have optimized too much 7 years ago, dunno.
(At least button t12 is missing in the newer exe files.)

### / 7 years later, end

Character meshes (Jackie, winston) are o.k.
Jackie's UVs need some reducing (faces range = 0.75).

Motorcycle 270DX01 mesh & UVs seem to be o.k. (wheels missing)

shak-otay, September 2013





format (taken from Jackie.perm.bin):
faces (indexbuffer) f1,f2,f3 as 3 uint16

vertices in a 16 bytes vertexblock:
x,y,z as 3 uint16 - (divided them by 1024 to get floating point values)
10 bytes to skip (00 00 D0 31 BB FF E0 CC 61 FF for example)

texture coords x,y as 2 uint16 (half floats)

edit: u can use Texturefinder on Winston_TS00.temp.bin for example to get the textures:



(Params for Winston in old MeshExtractor: x= 0.5 and faces range: 0.75)
(Better use new version v2.1 of TextureFinder.)


I don't think this would have been possible without the help of Mariusz Szkaradek.
So a big Thx and the credits go to him!


(Don't ask me why the window-panes do have an offset.)

The cabin seems to have an outer and an inner mesh in LOD0.

[SergeantJoe]

Speaking of which, for most models the mesh is in a ModelName.perm.bin and the textures are in a ModelName_TS0.temp.bin

However, a large chunk of the characters have generic names in this format:

A/T = [Model]/Texture
M/F = Male/Female (S = Special)
B/H = Body/Head

IE:
TF_B_001.temp.bin = Texture_Female_Body_001.temp.bin

AS_B_PoliceOfficer.perm.bin = Model_Special_Body_PoliceOfficer.perm.bin

[shakotay2]

Well, with the faces of the vehicles it's a little bit complicated.
For bisai01.perm.bin for example I found 193, 1321 and 4529 faces (LOD1,2,3?).
But if you display 3 models there are weird faces for example in LOD2 model.

With the help from Mariusz Szkaradek I understood that the 3 submeshes have to be devided up.

In fact there seem to be 8 submeshes.
SM 0 having 193 faces
no 1 to 3 have 99, 535+579+50 and 46+12 faces (1321 in sum)
The 4529 faces split up on submeshes 4..7

So the riddle is solved thanks Mariusz.

edit: hmm, I've made a comparison between the faces in the submeshes 1 to 3 and the ones of the errorness LOD2 SM.
They are identical!
So my error seems to be in the relation to the vertices list. Sure it's a rather simple one but I have to stick to RL again...

[artworkplay]

Great job guys. Any way to code a method to get the model's armature and weights as well?

[SergeantJoe]

Ooh, yeah, armature would be great. Here's some stuff that might help with that.

But then again it's most likely a whole different realm so I understand if it's not possible at this time.

[shakotay2]

I'm sure there are methods but since I lost many hours with current coding I think I will be done when vehicles are done.
So this is the weird faces problem I'm just solving (hopefully):

With bisai01 there are 3 LOD models (I just call them like this).
LOD_2 consist of 4 submeshes. One problem was to combine the 7 faces sections they are divided up into.
(Since LOD_1 has 3 submeshes LOD_2 starts from SM 4.)
This is a table of the relative min/max face indices as they are found by the parser:

Code: Select all

SM 4            SM 5      SM 6       SM 7
1/1535         
                1/520
1536/3334
                          1/1039
3335/3662
                                     1/346
                                     347/386

I didn't want to create an obj for each SM.
Maybe there is a trick with absolute face indices in blender/ wavefront obj format (more than just marking SM groups with 'g ').
I'm pretty sure I fiddled around with a prob that doesn't really exist.

That is to add 3662 to all face indices of SM 5. But when the parser finds SM5 our last max face index
(of SM4) is 1535. And before we reach 3662 of SM 4 there's another SM 6.

You see/understand the prob? If not don't worry - I think I got it now. I'll simply do a 2nd parsing pass.

(Anyway - if someone is just rolling on the floor/laughing maybe he kindly could tell me a better approach. )

edit: it's going to look better on vehicles but there are still some planes I'd like to know where they're coming from (hopefully it's only an offset again):

Guess in 3 or 4 days I can update the extractor (with minor errors left):

[SergeantJoe]

Yikes. I'd love to help but all that is way over my head.
Somewhat of a disappointment that bones/animations won't be supported, but still, thank you once more for all your hard work.

Really hope you get that issue sorted out.

[shakotay2]

(view upate in first post)

[SergeantJoe]

Thank you, now every single character opens perfectly!

...yet I noticed that some vehicles cause it to crash. Here's an example bin and the generated files.

Also, the vehicles that work still seem kind of wonky. I've tried changing the X, Y, And Z thresholds, but it just doesn't seem to come out correctly.

[shakotay2]

Also, the vehicles that work still seem kind of wonky.

As I wrote somewhere: "some minor errors are left".

...yet I noticed that some vehicles cause it to crash.

Yep, weird error. Thx.
Thought I solved it on LeoCoastGuard and wondered about the messy low level LOD_2.
Now RidgeCop works, too (see end of startpost).

[shakotay2]

Looks like a sampan01 submesh is ruined by the threshold calculation.
I first made a quickhack for a threshold correction (thc).

Then I decided to remove th on vertex type 12. It's working for LeoCoastGuard and "Dampfross" perm.bins. I also scaled up and rotated the interiors.

(get final version from start post)
If there are problems with other models use "intermediate version".

[SergeantJoe]

Say uh, I think I spotted a rather large problem.
I know that you said it's not perfect, but for nearly every vehicle I open, the insides are completely missing!

http://puu.sh/4H6iC.jpg
http://puu.sh/4H6mZ.jpg
http://puu.sh/4H6Cj.jpg

I've tried messing with the thresholds and thc button, but nothing happens.
Everything else comes out fine. Is this a problem with the files themselves?

[shakotay2]

I know that you said it's not perfect, [...]

Yep, it's the missing submesh_1_1 for LeoCoastGuard for example.

I fixed it in my last posts upload (which is replaced now by the final version in the start post).


But as you can see some threshold error again on y axis. Think I never will solve this...

edit: I used threshold 1.0 for x/y/z.
This seems to work for the wilful submesh (but not for the whole model (all 0.5)):


edit2: finally I removed "thresholding" from type 12. If this should be reported to be working on all models I would clear up the versions garbage...

[SergeantJoe]

Yay, now all meshes come out perfectly!

But, there is another big problem. The parts that were missing only have dummy UVs, for both 0.5 and 1.0 thresholds.

I could just remake them from scratch but it would be nice if you could fix this one last thing.
Here are the textures for that particular model if you need to test it.

[shakotay2]

The parts that were missing only have dummy UVs

Yes, this was a workaround for existing type 12 submeshes. So for the missing ones now.

But luckily I seem to have found uv data for LeoCG, LOD1, SM 1_1:


Finally I did a final version (-> start post).
Mirrored the mesh. Then there's no need to flip normals. (Seems at the end I will be confused totally... )

(I really hope there are no more issues 'cause I'm really tired now of "Sleeping Dogs"... )