Hi, wondering if I could get any help on this.  SAO HF uses a variant of the established PSP GMO format that Noesis cannot parse.

 

The chunk structure seems to be the same as standard GMO, each with a header consisting of a 2-byte LE chunk type ID, 2-byte LE chunk header size, and 4-byte LE chunk total data (header + data) size.  However the developers seem to have customized the format, adding in custom parameters at the start, and possibly changing around some of the ID mappings.

 

For now I've been able to track the tree structure and visualize it, but not sure how to figure out what data goes where and how to feed this to Noesis or similar programs.

 

I've attached two sample files.  Any advice on how to proceed?

input.zip

Hi, and welcome to the forum!

As a start I usually don't use Noesis (which has different strengths, imho.)

This gmo mesh format looks simple, using hex2obj for getting one submesh (there's 27 of them) in the bigger gmo (uvpos=28 ?):

(if no one else cares I could create a Make_H2O project for it, but not too soon)

The smaller gmo contains 44 GTX blocks, textures I assume.

Edited May 30May 30 by shak-otay

Thanks, so I should extract the binary data for each of the mesh nodes and feed it to the hex2obj utility?

Usually I use hex2obj for getting one sub mesh only and sometimes create a Make_H2O project then.

 

edit: here are the H2O files - I didn't check all of them, maybe more correction required (no 17 is the only one with FVFsize 48/uvbsize 40 atm)

Use the File\saveAs Mmesh feature of hex2obj instead of loading each H2O file separately.

map00760000_4_0_0_0.gmo_00026.zip

Edited May 31May 31 by shak-otay

6 hours ago, kirby0louise said:

应该提取每个网格节点的二进制数

It seems the model is composed of multiple polygon chunks. This is the first one, made up of triangular faces. Vertex positions and normals are stored as floating-point numbers, and UV coordinates should follow the normals. However, the UV data in this sample looks messy, so I can't confirm this for sure yet.

28 minutes ago, KuWuniss6 said:

However, the UV data in this sample looks messy,

Not really:

 

Looks great, any tutorials on how to create the .h2o files to automate this?  I see that the zip has a bunch of files that presumably are tiny little config/scripts, but I can't make heads or tails of them.  Apologies if this should be straightforward, I'll have more time over the coming days to explore with this new utility.

Edited May 31May 31 by kirby0louise

4 hours ago, kirby0louise said:

Looks great, any tutorials on how to create the .h2o files to automate this? 

I don't have a current tutorial but if you have basic knowledge of the 'C' language the Make_obj project could come in handy. (It's similar to the Make_H2O project which wasn't too popular.)  edit: in Make_obj the HFloat() has to be checked

Otherwise you could read here.

Quote

I see that the zip has a bunch of files that presumably are tiny little config/scripts, but I can't make heads or tails of them.

That's the parameter files for hex2obj. Example:

 

0x324 300 // start address of face indices and their count
Vb1   // Vertex block mode
36 28     // FVFsize and uv pos
0xc388 108  // start address of vertices and their count
020000  // code for the format (float/half float etc, endianness, strips or triangles)
0x0 255  // address and count for uv data, if not in vertex block, uvpos is 99 then

 

edit: if you want to start with .gmo from scratch, here's some details marked with rectangles:

0xcbc 864
Vb1
36 28
0xfee4 386
020000
0x0 255

Edited May 31May 31 by shak-otay