PHY file format?

[Terr]

(Also cross-posted in Modelling)

I need to pull out gib data from models' PHY files, but I don't see any clear documentation on the binary format. Right now I'm just messing with a hex editor to try to guess where I can find sections which define offsets to the key-value data near the end of the file.

Does anybody have information on how the PHY file is arranged?

[Jordash]

What information are you looking for specifically? Whatever it is, you would have more luck decompiling the model

[Terr]

The high level goal is to take a model and answer: "What are all the dependencies this model has?"

I already have code that reads the model file (MDL) for:

1. "internal" model name
2. skin indices and the the VMT filenames associated with each index (0,1,etc.)
3. the subdirectories searched for VMTs

However, that isn't enough, since models can pull in other models. So I use (a) to find the associated modelname.phy file... and now I need to read the PHY to figure out what gib-models are used.

I can use a hex editor and see the data I want, but I can't reliably determine the relative position of that text block inside the binary file yet.

[coder0xff]

Easiest bet will probably be to get the source code for studiomdl and reverse engineer that.

[omnicoder]

Easiest bet will probably be to get the source code for studiomdl and reverse engineer that.

Isn't all the code related to mdls closed source? I don't remember seeing the code for studiomdl before aside from the header definitions.

[Terr]

There seems to be enough for a decent start in the source code. I have an advantage: I don't need to necessarily know what all the quantitative data is, I just have to get enough of the high-level structure in place. I'll try to add bits and pieces to the VDC as I go.

A few points of interest:

• bsplib.cpp
• studiobyteswap.cpp
• ivp.cpp
• vcollide.h (maybe)

There's also the "cheap and dirty" way which I could fall back on, which is to start from the end of the file, and go towards the front until I see the top-most instance of "solid {", then split the thing up to a bunch of strings by breaking on 0x00.

I'm not above taking shortcuts to avoid extra work, but in general I'm trying to write things so that they could plausibly be extended into general-purpose ways of handling these files. (The Maven project is called Hl2Parse, which suggests a certain level of functionality.)

[coder0xff]

There seems to be enough for a decent start in the source code. I have an advantage: I don't need to necessarily know what all the quantitative data is, I just have to get enough of the high-level structure in place. I'll try to add bits and pieces to the VDC as I go.

A few points of interest:

• bsplib.cpp
• studiobyteswap.cpp
• ivp.cpp
• vcollide.h (maybe)

There's also the "cheap and dirty" way which I could fall back on, which is to start from the end of the file, and go towards the front until I see the top-most instance of "solid {", then split the thing up to a bunch of strings by breaking on 0x00.

I'm not above taking shortcuts to avoid extra work, but in general I'm trying to write things so that they could plausibly be extended into general-purpose ways of handling these files. (The Maven project is called Hl2Parse, which suggests a certain level of functionality.)

Making it from whatever .h files are available is how I was doing it in ducttape. BTW, you can still download the leak.

[crazycarl]

The first four bytes before each collision lump (which starts with the string "VPHY") is an int that describes the size of that lump. If you the skip that number of bytes, you will either land on the next lump size, or you will land directly on "solid {".

[Terr]

Carl: That looks like it works, thanks. I didn't see it since I misinterpreted the last long-value in the phyheader_t as meaning 8-bytes instead of 4... Been doing too much in Java lately I did some more poking around and updated the PHY page on the VDC.

BTW, any suggestions for a free hex editor? I've been using XVI32, but it feels a little klunky for investigating file formats. It'd be cool if I could color-code different extents.