(Slightly) Greater understanding of unit model files

AJE
Sergeant Major of the Army
Posts: 384
Joined: Sat 7 Sep 2013 07:22
Contact:

(Slightly) Greater understanding of unit model files

Postby AJE » Sun 19 Oct 2014 10:40

Warning: this post is technical in nature, and it is recommended the reader knows basics about hex editing before diving into all this.

For the past month or so, I've poured a few dozen hours into using my OCD to study and find patterns in the file holding unit models, with a hex editor.
(for those of you who don't know, it's in ZZ_1.dat (the big one next to the texture files), and named pc\mesh\pack\gfxdescriptor\mesh_all.spk)
Finally, I've analyzed it to the limit of my abilities, and I really can't offer any more insight into the working of the unit models, so I've decided to post it up on GoogleDocs (it's a long one).

https://docs.google.com/document/d/1H_esEcCmYAZqdk5u_DnB-PE2S2Fyn3Lt7LSxbepMyWQ/edit?usp=sharing

Now, most experienced modders probably know all about the .spk file format, so most of the parts that analyze parts of the file already editable with the modding suite are probably redundant. In that case, I'd advise skipping to the part with vertices: Section J (It's the last section in the index of my analysis). This is where the model meshes are stored, and I've learned some interesting things about that part of the file.

In particular, I now know that this section is organized by sections beginning with a "VBUF" text, and each such section contains 4 or 6 (depending on the section) sub-sections that begin with a "SUBP" text. I now strongly believe, contrary to what Vasto inferred earlier, that each model is held in one piece and not split up in the files- and specifically that each "VBUF" section holds one model, with the "SUBP" sections each holding a piece of the model that must move (like a turret). But don't take my word for it. The long, complex details of this are in the "Section J" chapter of the analysis.

Anyway, this is as much as I can do, but I have a feeling that the hex values I've isolated from their headers in each "VBUF" and "SUBP" section are the model vertices themselves. I think that all that needs to be done is for them to be translated into a more useable form (or format). If anyone can use this to get even closer to model editing in Wargame, then they are free to use any information I've found.

User avatar
Vasto
Second-Lieutenant
Posts: 898
Joined: Sat 1 Jun 2013 19:26
Contact:

Re: (Slightly) Greater understanding of unit model files

Postby Vasto » Sun 19 Oct 2014 11:55

AJE wrote:In particular, I now know that this section is organized by sections beginning with a "VBUF" text, and each such section contains 4 or 6 (depending on the section) sub-sections that begin with a "SUBP" text. I now strongly believe, contrary to what Vasto inferred earlier, that each model is held in one piece and not split up in the files- and specifically that each "VBUF" section holds one model, with the "SUBP" sections each holding a piece of the model that must move (like a turret). But don't take my word for it. The long, complex details of this are in the "Section J" chapter of the analysis.


I see there is a slight misunderstanding.

I didn't say that mesh data of a single model are split, but rather that there are sections which contain different data types (like bounding boxes, textures bindings, meshes) which cannot be easily put together into a ase2ndfbin model file format, because we don’t know that file format and I suppose that all these things should be contained in the result model file.

It is important to distinguish the difference between the "model" and "mesh". Saying that model data are split is not equivalent of saying that mesh data are split...
Image

AJE
Sergeant Major of the Army
Posts: 384
Joined: Sat 7 Sep 2013 07:22
Contact:

Re: (Slightly) Greater understanding of unit model files

Postby AJE » Sun 19 Oct 2014 13:01

Vasto wrote:
AJE wrote:In particular, I now know that this section is organized by sections beginning with a "VBUF" text, and each such section contains 4 or 6 (depending on the section) sub-sections that begin with a "SUBP" text. I now strongly believe, contrary to what Vasto inferred earlier, that each model is held in one piece and not split up in the files- and specifically that each "VBUF" section holds one model, with the "SUBP" sections each holding a piece of the model that must move (like a turret). But don't take my word for it. The long, complex details of this are in the "Section J" chapter of the analysis.


I see there is a slight misunderstanding.

I didn't say that mesh data of a single model are split, but rather that there are sections which contain different data types (like bounding boxes, textures bindings, meshes) which cannot be easily put together into a ase2ndfbin model file format, because we don’t know that file format and I suppose that all these things should be contained in the result model file.

It is important to distinguish the difference between the "model" and "mesh". Saying that model data are split is not equivalent of saying that mesh data are split...


Oh, well I'm sorry, I must have misunderstood that. I thought that you had meant the mesh files themselves were split and stored in different parts of the file. Anyway, since the modding suite can already locate and change most things about the models, like texture bindings and bounding boxes, I assume that they are held in the first few parts of the file, which would presumably explain how enhoka could get the editor to read them, but not the mesh portion, which is (I think) the only part held in the VBUF sections.

Return to “Modding”

Who is online

Users browsing this forum: No registered users and 2 guests