Need help regarding reverse engineer a model file

[Silence Exterminator]

can someone help me regarding something related to binary i correctly reverse engineer and found vertex buffer for head build a head i also found the face indices section as the format was very easy but the problem is i use model researcher and enter the starting offset for face indices it form the faces but in wrong direction as in the picture provided also the format is very easy so if any one wants to help me out the model is also provided as well

Wei_Head.perm.zip

Edited May 23 by Silence Exterminator
included a file i forgot

[roocker666]

You need to upload a sample

[Silence Exterminator]

3 minutes ago, roocker666 said:

You need to upload a sample

sample is provided

[sw-emre]

Hey if im not mistaking .perm format only exist in Sleeping Dogs,someone already made an SDK for the game and a model exporter and importer,i belive format is mostly reversed,just the skin weights isnt supported at the moment, you can only import static models into game,more format info can be found in the SDK.

https://github.com/SDmodding/ModelExporter
https://github.com/SDmodding/ModelScriber
https://github.com/SDmodding

[sw-emre]

 

[Silence Exterminator]

yh but i want to practice my own so thats why i started my own research on it and i did found the vertex buffer and face indices starting offset but dont know why its not showing up correctly so if u can help me i will be really obliged, thanks.

[sw-emre]

I understand, unfortunately I cannot reverse formats, but this format has been researched for almost a decade since the Xentax forums,its not very simple format.From what i heard Tangents and Skin Weights is the only parts left to reverse other than that format is fully reversed thanks to debug symbols accidently shipped by the devs(paved the way to create an SDK),you can maybe check the github repos that i sent for the parts you having problem with its an open source project after all.

[Silence Exterminator]

21 minutes ago, sw-emre said:

I understand, unfortunately I cannot reverse formats, but this format has been researched for almost a decade since the Xentax forums,its not very simple format.From what i heard Tangents and Skin Weights is the only parts left to reverse other than that format is fully reversed thanks to debug symbols accidently shipped by the devs(paved the way to create an SDK),you can maybe check the github repos that i sent for the parts you having problem with its an open source project after all.

i mean i just wanted to carry my own research i did everything just faces are not shown correctly i just need help with that so i could learn and increase my knowledge in reverse engineering but its fine if u can't, np thanks again for ur time 😅 

Edited May 23 by Silence Exterminator

[DKDave]

18 minutes ago, Silence Exterminator said:

i mean i just wanted to carry my own research i did everything just faces are not shown correctly i just need help with that so i could learn and increase my knowledge in reverse engineering but its fine if u can't, np thanks again for ur time 😅

This looks like the values to use for that example mesh:

 

[Silence Exterminator]

8 minutes ago, DKDave said:

This looks like the values to use for that example mesh:

 

thanks alot bro thanks alot for taking out ur precious time for me i really appreciate it from bottom of my heart one thing i do want to ask that can u explain me or give me some tips regarding how u figured out the correct padding for vertices and vertice limit?

[shak-otay]

I made a tool for perm.bin 10 years ago on Xentax - sadly Wei's head crashes it.

But hex2obj works:

[DKDave]

7 minutes ago, Silence Exterminator said:

thanks alot bro thanks alot for taking out ur precious time for me i really appreciate it from bottom of my heart one thing i do want to ask that can u explain me or give me some tips regarding how u figured out the correct padding for vertices and vertice limit?

It just takes practice - once you find the start of the vertex data, you can usually see a pattern for how many bytes each vertex entry uses - in this case it's 24 bytes (12 for vertices, so the padding is 12 to the next vertex).  Some vertices may be in their own block, other files may have themcombined with UVs, Normals, bone info and other stuff all in one large block.

To calculate the vertex count, you can look through the data and can often see where the pattern changes - do some calculations between the two address to give an approximate vertex count and then refine it.  In Model Researcher, you can also find the face data first, that's usually easier to see.  You can put the face values into MR with no vertex info and it'll tell you how many vertices that face data should use.

 

 

 

[Silence Exterminator]

12 minutes ago, DKDave said:

It just takes practice - once you find the start of the vertex data, you can usually see a pattern for how many bytes each vertex entry uses - in this case it's 24 bytes (12 for vertices, so the padding is 12 to the next vertex).  Some vertices may be in their own block, other files may have themcombined with UVs, Normals, bone info and other stuff all in one large block.

To calculate the vertex count, you can look through the data and can often see where the pattern changes - do some calculations between the two address to give an approximate vertex count and then refine it.  In Model Researcher, you can also find the face data first, that's usually easier to see.  You can put the face values into MR with no vertex info and it'll tell you how many vertices that face data should use.

 

 

 

thanks for the explaination i understood the technique of finding the vertex limit through face data but one thing i didn't understand is that u said something regarding 24 bytes 12 for each vertices how can i check that in model researcher and Hex editor i provided the pictures u can guide me through that where i should look to find those data sorry if i am asking the basics i am a begineer but have alot of passion for reverse engineering, thanks.

[DKDave]

The bits highlighted in red are the vertices, and there are 24 bytes (0x18) from the start of one vertex to the start of the next.  The first 12 bytes of each block of 24 are the 3 float values for 1 vertex, the next 12 bytes are something else - not sure what they are, I didn't look too closely at those.  For Model Researcher the padding is the length of the other data after each vertex, in this case 12.

 

 

 

[Silence Exterminator]

18 minutes ago, DKDave said:

The bits highlighted in red are the vertices, and there are 24 bytes (0x18) from the start of one vertex to the start of the next.  The first 12 bytes of each block of 24 are the 3 float values for 1 vertex, the next 12 bytes are something else - not sure what they are, I didn't look too closely at those.  For Model Researcher the padding is the length of the other data after each vertex, in this case 12.

 

 

 

thanks again i got it there is a clear pattern too of zero repeatedly in the pic u can see

[Silence Exterminator]

3 hours ago, DKDave said:

The bits highlighted in red are the vertices, and there are 24 bytes (0x18) from the start of one vertex to the start of the next.  The first 12 bytes of each block of 24 are the 3 float values for 1 vertex, the next 12 bytes are something else - not sure what they are, I didn't look too closely at those.  For Model Researcher the padding is the length of the other data after each vertex, in this case 12.

 

 

 

bro thanks again for ur help with ur help i was able to reverse engineer other files too like pants as u can see in pic also one question can u help me find the uv data cause its usually after vertex buffer or with in vertex buffer if u can please find that for the head i can study it and then do for other models as a practice thanks.

[shak-otay]

What I found looks strange (teeth?). Well, see, need to turn the thing:

The normals might be compressed in the vertex block, 2 x DWORD, aabbccFF, 2x24= 48 bits?

Edited May 24 by shak-otay

[roocker666]

UVs are in other block(at 0x1e6c0) but are Half-Float and without padding. But maybe you need to split a few parts so export the obj and then split meshes on Blender(assign the texture and those Uvs that don't match the texture probably use other textures so split those)

Edited May 24 by roocker666

[roocker666]

39 minutes ago, shak-otay said:

The normals might be compressed in the vertex block, 2 x DWORD, aabbccFF, 2x24= 48 bits?

I think those are vertex colors, there is other block at 0x18C80, maybe those are Normals(?)

[Silence Exterminator]

8 hours ago, roocker666 said:

I think those are vertex colors, there is other block at 0x18C80, maybe those are Normals(?)

thanks alot bro for ur help! also i checked the offset that u provided for the UVs data its really the end of the file so any tip how did u get to know they are UV data cause to me it looked like more vertex data so again any tip to find UV data also if possible to guide me regarding normal section too and how to locate it, thanks

[roocker666]

49 minutes ago, Silence Exterminator said:

thanks alot bro for ur help! also i checked the offset that u provided for the UVs data its really the end of the file so any tip how did u get to know they are UV data cause to me it looked like more vertex data so again any tip to find UV data also if possible to guide me regarding normal section too and how to locate it, thanks

Vertices, Uvs and Normals can appear in same block(buffer) together or in different blocks, that is the key, So always try to analyze the whole file. Vertices, Uvs and Normals types varies on each model, they could be all Floats or a mix of Floats and shorts or Half-Floats so pay attention to that too.

I have no Idea about Normals, those could be in vertices block like "shak-otay" said or in other block like I said. It is hard to tell because I got nothing from both blocks.. That is all I can do, sorry.

[DKDave]

Just some more info: the file is made up of various segments.  Each segment has a 16-byte header, which contains the size of the data in that segment, followed by that amount of data.  So the first segment contains 0x220 bytes of data after a 16-byte header.  In that file there are 9 segments, so you have 3 for material info, then bone palette, Index Buffer for faces, 3 vertex buffers, and the final segment contains info on the submeshes to split the model into the correct parts.  This model contains 3 submeshes.  The first vertex buffer contains the vertices and probably normals.  The second vertex buffer is the bone weights and indices.  The third vertex buffer is UVs.

 

 

[Silence Exterminator]

5 minutes ago, DKDave said:

Just some more info: the file is made up of various segments.  Each segment has a 16-byte header, which contains the size of the data in that segment, followed by that amount of data.  So the first segment contains 0x220 bytes of data after a 16-byte header.  In that file there are 9 segments, so you have 3 for material info, then bone palette, Index Buffer for faces, 3 vertex buffers, and the final segment contains info on the submeshes to split the model into the correct parts.  This model contains 3 submeshes.  The first vertex buffer contains the vertices and probably normals.  The second vertex buffer is the bone weights and indices.  The third vertex buffer is UVs.

 

 

thanks for the reply one more question i am just querous cause i never touched weights in reverse engineering so for my knowledge i want to ask that can u give me any tip or guidence to reverse the weights i can then work on it as i use model researcher which exports just obj and obj doesn't store weights info so for me to export weights have to write a tool for that i know c++ so i guess i have to write a .fbx file format in order to export weights so if that the case can u guide me how can i write an fbx file any link or helpful source, also the pic i provided refers to what u said is the section to weights and i can also see a pattern of FF in a column, thanks

Wei_Head.perm.zip

[Silence Exterminator]

1 hour ago, Silence Exterminator said:

thanks for the reply one more question i am just querous cause i never touched weights in reverse engineering so for my knowledge i want to ask that can u give me any tip or guidence to reverse the weights i can then work on it as i use model researcher which exports just obj and obj doesn't store weights info so for me to export weights have to write a tool for that i know c++ so i guess i have to write a .fbx file format in order to export weights so if that the case can u guide me how can i write an fbx file any link or helpful source, also the pic i provided refers to what u said is the section to weights and i can also see a pattern of FF in a column, thanks

Wei_Head.perm.zip 74.45 kB · 0 downloads

i think the weights are represented by a 4-byte float right?

[Silence Exterminator]

On 5/25/2024 at 1:05 AM, DKDave said:

Just some more info: the file is made up of various segments.  Each segment has a 16-byte header, which contains the size of the data in that segment, followed by that amount of data.  So the first segment contains 0x220 bytes of data after a 16-byte header.  In that file there are 9 segments, so you have 3 for material info, then bone palette, Index Buffer for faces, 3 vertex buffers, and the final segment contains info on the submeshes to split the model into the correct parts.  This model contains 3 submeshes.  The first vertex buffer contains the vertices and probably normals.  The second vertex buffer is the bone weights and indices.  The third vertex buffer is UVs.

 

 

i researched first vertex buffer for normals using model researcher used the type as shorts and printed the data got very clean info but still not the correct normals section i guess also i provided the model file if u want to check ur self cause i am clueless about this. also the structure is 24 in stride, so you got 3 floats for position, and the other 12 bytes are int8 or uint8 for the 3x4 matrix

Wei_Head.perm.zip

Edited May 26 by Silence Exterminator