Jump to content

StarFox64 3D .modelbin


LeoFeroz

Recommended Posts

  • Engineer

Usually I don't write scripts. I prefer using the Make_obj tool. Sometimes. But I've spent too much time with this simple format already.

I gave H2O files for use with hex2obj. To give you the idea. If you want a script you'll need to wait for someone else.

Link to comment
Share on other sites

30 minutes ago, shak-otay said:

Usually I don't write scripts. I prefer using the Make_obj tool. Sometimes. But I've spent too much time with this simple format already.

I gave H2O files for use with hex2obj. To give you the idea. If you want a script you'll need to wait for someone else.

Ok thank you

Link to comment
Share on other sites

  • Engineer

Well, this format could be a good opportunity to revive the Make_obj/Make_H2O project(s). Will take some weeks, though, because I don't have much spare time.

edit: couldn't resist; but one of the 9 sub meshes was weird. Need to calculate/estimate the FVFsizes because I didn't find them so far.

)-sub_mesh-1.png

Edited by shak-otay
  • Like 2
Link to comment
Share on other sites

On 11/6/2023 at 2:39 AM, shak-otay said:

Well, this format could be a good opportunity to revive the Make_obj/Make_H2O project(s). Will take some weeks, though, because I don't have much spare time.

edit: couldn't resist; but one of the 9 sub meshes was weird. Need to calculate/estimate the FVFsizes because I didn't find them so far.

 

Well, take as much time as you need. your help is very good, oh one more thing I asked one of the guys at the xentax discord server about this format he said it doesn't have a header and that's why it's almost impossible to write a script if you want I can send you the rest of the files taken from the game

Link to comment
Share on other sites

  • Engineer
3 hours ago, LeoFeroz said:

I asked one of the guys at the xentax discord server about this format he said it doesn't have a header and that's why it's almost impossible to write a script

This guy doesn't seem to know that the magic tables (addresses, counts) are in the modelgdb file.

The FVFsize is the thing in question but it can be calculated from the other values.

You might test it this evening, I guess.

Link to comment
Share on other sites

12 hours ago, shak-otay said:

This guy doesn't seem to know that the magic tables (addresses, counts) are in the modelgdb file.

The FVFsize is the thing in question but it can be calculated from the other values.

You might test it this evening, I guess.

The raw .modelbin data file had no headers, which was what I was replying to because that was all that was posted at the time.  Now that I've seen the .modelgdb files I can see the full structure of the data.  You've got vertex data size and vertex count to calculate the stride, and each submesh has a VertexFormat value (such as 0xfcf003b) which somehow indicates which vertex elements are present.  Some are Floats, some are Shorts, but that info is hard to interpret accurately - that's the only unknown in the submesh info.

Link to comment
Share on other sites

  • Engineer

Carry with poise - they may think you're a magician. 😉

edit: Files from opening post - newer blenders seem to quarrel with flat meshes. Had to trick around with local view and such to display correctly:

 

f3383eee_.png

Edited by shak-otay
  • Haha 1
Link to comment
Share on other sites

  • Engineer

@all: you may try out this Make_H2O project. But you'll need hex2obj for processing the .H2O files.

If you don't have hex2obj I'm sorry. You'll need to wait until I'll upload a fixed version, next year, maybe. I don't like the old one.

Or wait for someone's script.

edit: last sub meshes H2O needs to be corrected (FVFsize, always)

here number ... _11.H2O (32 instead of 52):

0x95b40 22
Vb1
32 24
0x95b6c 16
021000
0x95b84 255

 

 

Make_H2O-Starfox.zip

Edited by shak-otay
Link to comment
Share on other sites

17 hours ago, shak-otay said:

@all: Vocêpode experimentar este Make_H2O projeto. Mas você precisará de hex2obj para processar o . Arquivos H2O.

Se você não tem hex2obj eu sinto muito. Você vai precisar esperar até que eu vou carregar uma versão fixa, no próximo ano, talvez. Não gosto do antigo.

Ou esperar o roteiro de alguém.

editar: últimas submalhas H2O precisa ser corrigido (FVFsize, sempre)

aqui número ... _11.H2O (32 em vez de 52):

0x95b40 22
Vb1
32 24
0x95b6c 16
021000
0x95b84 255

a small problem the tool can only correctly read the modelbin/modelgdb ones that I gave you and the others it creates the h20 files but hex2obj exports exploded meshes
image.png.eca3990533552db4f1106e01a0ecee6a.png

Link to comment
Share on other sites

  • Engineer
4 hours ago, LeoFeroz said:

and the others it creates the h20 files but hex2obj exports exploded meshes
 

Without a sample of that kind I can't tell. Delete the last H2O file (biggest number) as a workaround then use hex2obj again (delete all .obj files before).

For the textures: you'll need to get the dimensions from the texturegdb file. Seems it's not 296x2304. It looks swizzled also.

Link to comment
Share on other sites

  • Engineer

w: 1024 ofs: 72

h: 512 ofs: 88

just a quick look. inside the file there is the word “swizzle”, I don’t know which one exactly, I chose PS2 as an example, the bpp is clearly 16 bits. (I chose a random format r5g6b5 for example) *(the rest is up to you)

image.thumb.png.3d6158912c33a0d0cf429e4779ee7ef1.png

Link to comment
Share on other sites

  • Engineer
3 hours ago, shak-otay said:

296

296 is a clear indent to a block of lines. after indentation uint SizeBlocStrings , > аrr_strings (string up to the first null byte)

00 09 00 00 - this is the possible number of nodes, since after are 2 uint (zero, unk) and 9 indents to the nodes, I think so

Each "node" has 2uint at the beginning as (Offset_in_Strings_block, LenName):: edit: Not LenName, maybe type node?

🙂image.thumb.png.d38234c8987ba718fb03f22541d4da6f.png

Edited by Durik256
Link to comment
Share on other sites

10 hours ago, Durik256 said:

296 is a clear indent to a block of lines. after indentation uint SizeBlocStrings , > аrr_strings (string up to the first null byte)

00 09 00 00 - this is the possible number of nodes, since after are 2 uint (zero, unk) and 9 indents to the nodes, I think so

Each "node" has 2uint at the beginning as (Offset_in_Strings_block, LenName):: edit: Not LenName, maybe type node?

🙂

  .tga
image.png.40b7a1b7058f963d8ddc47797546dcce.png
here are some gdb files decrypted or in text, whatever
unfortunately the textures gdb doesn't have any in .text
TextModelgdb.rar

TextModelgdb.rar

Link to comment
Share on other sites

  • Engineer

I had some batch processing with GUI (other format) but it was ugly and

refraining from a GUI is harder than you may think of.

I'd not be surprised if DKDave or someone else presented a script before I even get into action...

 

edit: found that batched version from 5 years ago. Maybe I'll check it next week.

btw: batch processing is rather worthless, imho, without included texture handling. Which I usually don't care for.

Edited by shak-otay
  • Thanks 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...