I need help reverse engineering and mapping out .bin model files from Banjo Kazooie I also have some documentation (I'm not 100% that this applies for these files specifically but I am like 85% sure) https://hack64.net/wiki/doku.php?id=banjo_kazooie:model_data ANY help is appreciated! (my end goal is to make a Noesis plugin for these files)

test files.zip

On a quick glance, 1495-model, big endian shorts,

edit: indices don't make much sense to me. Maybe take the odd ones only?

But then there will be sequences like 82 82 82, 114 114 144 etc.

address 0x8020:
    7     2     6    48   288   300  2451     0 
    0     1     1    11    12    13    25    13 
   38    11    49     1    50     0    50     8 
   58     8    66     8    74     8    82     0 
   82     0    82     8    90     8    98     8 
  106     8   114     0   114     0   114     8 
  122     8   130     8   138     8   146     0 
  146     0   146    10   156    12   168    11 
 

edit: wrong start of indices?

Correct one looks like so:

address 0x84b0:
   18    16    19     0     0   256    14    15 
   16     0     0   256    14    16    18     0 
    0   256    18    16    19     0     0   256 
   60    61    62     0     0   256    63    61 
   60     0     0   256    61    64    62     0 
    0   256    62    64    65     0     0   256 
  296   295   292     0     0   256   297   295 
  296     0     0   256   298   297   296     0 
    0   256   299   297   298     0     0   256 
   10    11    13     0     0   256    13    15 
   14     0     0   256    14    15    16     0 
    0   256    14    16    18     0     0   256 
   48    49    50     0     0   256    60    61 
   62     0     0   256    63    61    60     0 
    0   256    88    63    89     0     0   256 
   89    63    60     0     0   256   298   297 

 

Edited July 30, 20251 yr by shak-otay

22 minutes ago, shak-otay said:

On a quick glance, 1495-model, big endian shorts,

edit: indices don't make much sense to me. Maybe take the odd ones only?

But then there will be sequences like 82 82 82, 114 114 144 etc.

address 0x8020:
    7     2     6    48   288   300  2451     0 
    0     1     1    11    12    13    25    13 
   38    11    49     1    50     0    50     8 
   58     8    66     8    74     8    82     0 
   82     0    82     8    90     8    98     8 
  106     8   114     0   114     0   114     8 
  122     8   130     8   138     8   146     0 
  146     0   146    10   156    12   168    11 
  179     8   187     0   187     0   187     0 
  187     2   189     1   190     0   190     0 
  190     0   190     0   190     0   190     0 
  190     0   190     0   190     0   190     0 
  190     0   190     0   190     0   190     0 
  190    11   201    10   211    10   221    10 
  231    10   241    11   252     8   260     4 
  264     0   264     0   264     4   268     8 

 

Also here is a reference for what file is what model https://hack64.net/wiki/doku.php?id=banjo_kazooie:rom_map the file ID is the name of the file aka its number so 02DB.model.bin's File ID would be 02DB and its a "RBB Grey Toxic Barrel"

edit: that model you're looking at is a whole level's area you might want to look at a smaller model first maybe?

Edited July 30, 20251 yr by marty

17 minutes ago, marty said:

 you might want to look at a smaller model first maybe?

2DB, yay.

9 minutes ago, shak-otay said:

2DB, yay.

Some nice progress but the model is incomplete still

What did you expect? The indices are weird, as I wrote.Maximum face index is 24, so you could try build the faces from this table:

(where 256 is assumed to be a terminator, maybe just skipping 0 0 256 does the trick?)

address 0x1348:
    0     6     6     7    13    10    23    12 
    4     0     3     0     0   256     5     4 
    3     0     0   256     6     4     5     0 
    0   256     7     6     5     0     0   256 
   16    17    18     0     0   256    18    17 
   19     0     0   256     0     1     2     0 
    0   256     3     0     2     0     0   256 
    4     0     3     0     0   256     5     4 
    3     0     0   256    16    17    18     0 
    0   256    19    17    20     0     0   256 
   18    17    19     0     0   256     6     4 
    5     0     0   256     7     6     5     0 
    0   256     8     9    10     0     0   256 
   11     8    10     0     0   256    12     8 
   11     0     0   256    13    12    11     0 
    0   256    16    17    18     0     0   256 
address 0x1448:
   21    17    22     0     0   256    18    17 
   19     0     0   256    22    17    16     0 
    0   256     0     1     2     0     0   256 
    3     0     2     0     0   256    12     8 
   11     0     0   256    13    12    11     0 
    0   256    14    12    13     0     0   256 
   15    12    14     0     0   256    16    17 
   18     0     0   256    19    17    20     0 
    0   256    21    17    22     0     0   256 
   18    17    19     0     0   256    22    17 
   16     0     0   256    20    17    21     0 
    0   256     0     0     0     3     0     0 

edit: yep,

f 5 1 4
f 6 5 4
f 7 5 6
f 8 7 6
f 17 18 19
f 1 2 3
f 4 1 3
f 5 1 4
f 20 18 21
f 19 18 20
f 9 10 11
f 12 9 11
f 13 9 12
f 14 13 12
f 22 18 23
f 15 13 14

...

Edited July 30, 20251 yr by shak-otay

1495 model bin, revised, is stretched, somehow: edit2 damxxed, the correct v start is 0x45b8

old edit: futuristic?

edit: btw, checking the format description was the last I did, as usual.

The 6 extra bytes in FIs' block skipped in hex2obj are described like so:

Quote

[uu uu]     unknown
[ii ii ii ii]     u32 Sound + Collision Flags

 

edit3: uvs need to be signed shorts

 

 

 

Edited July 31, 20251 yr by shak-otay

5 hours ago, shak-otay said:

1495 model bin, revised, is stretched, somehow:

edit: futuristic?

 

edit: btw, checking the format description was the last I did, as usual.

The 6 extra bytes in FIs' block skipped in hex2obj are described like so:

 

Here is what that area is supposed to look like 

Too bad - that's not even close

I am close...

But not sure where indices starts. Anyway the documentation match almost everything from what i can see here.

EDiT: Found them... But uv are strange.

Edited July 31, 20251 yr by h3x3r

20 minutes ago, h3x3r said:

I am close...

But not sure where indices starts. Anyway the documentation match almost everything from what i can see here.

YOOOO thats so fire

 

Edited July 31, 20251 yr by shak-otay

3 hours ago, h3x3r said:

EDiT: Found them... But uv are strange.

No. Need to be signed shorts. See my previous post.

Yeah I know, but scale factor. I think it must be somewhere. Or do you have correct scale + position?

I usually don't care/ correct it in blender. uv x+63/y+100 and scale 2.0 with uv values from (modified) hex2obj.

(But I don't have a texture to test it.)

2 hours ago, shak-otay said:

I usually don't care/ correct it in blender. uv x+63/y+100 and scale 2.0 with uv values from (modified) hex2obj.

(But I don't have a texture to test it.)

Textures should be embedded in the file. Check documentation I think it goes further on about that

I checked them but can't decode them.

What platform is this game?

5 minutes ago, h3x3r said:

I checked them but can't decode them.

What platform is this game?

Nintendo 64
the documentation explains how to find out wether a texture is CI8, CI4, RGBA16 etc... I think and also the documentation shows how to find out the size e.g. 64x64

Not sure if is there any tool which supports this pixel formats like CI4/8. Most of them are CI4/8. I tried ImageHeat but result was not pleasing.

Anyway here is one texture from file 1495.model.bin

And as you can see I already have made 010 editor template by the documentation. So I know what is what.

Pixel Format > 1 = CI4. Size of buffer is callculated by (width * height / 2) which results in 2048 bytes data. Next is 32 bytes Palette. As described in documentation.

Untitled1.7z

EDiT: Well I think I got something. Not sure if it's supposed to look like this...

Well Palette Format is > xbgr1555. I noticed it on this texture.

Here are textures. You can test it.

1495_textures.7z

Edited August 1, 20251 yr by h3x3r

Thanks! But not sure whether I used tiling correctly here (floor should not use the wall texture):

Edited August 1, 20251 yr by shak-otay

6 hours ago, h3x3r said:

Not sure if is there any tool which supports this pixel formats like CI4/8. Most of them are CI4/8. I tried ImageHeat but result was not pleasing.

Anyway here is one texture from file 1495.model.bin

And as you can see I already have made 010 editor template by the documentation. So I know what is what.

Pixel Format > 1 = CI4. Size of buffer is callculated by (width * height / 2) which results in 2048 bytes data. Next is 32 bytes Palette. As described in documentation.

Untitled1.7z 2.16 kB · 0 downloads

EDiT: Well I think I got something. Not sure if it's supposed to look like this...

Well Palette Format is > xbgr1555. I noticed it on this texture.

Here are textures. You can test it.

1495_textures.7z 9.84 kB · 1 download

Sick asf, I was having trouble with the palletes myself

How did you unpack *.n64 file?

3 hours ago, h3x3r said:

How did you unpack *.n64 file?

Firstly the .n64 file is a ROM file. I'm using .bin files from the decompilation which splits the rom for you when you set it up. But I think there are other tools for doing it.

edit: you can use this https://www.romhacking.net/utilities/496/ but remember not all .bin files are model files so you should use this https://hack64.net/wiki/doku.php?id=banjo_kazooie:rom_map to know which .bin files are models and if so what model they are

Edited August 2, 20251 yr by marty

Send me please unpacked n64 file. The tool doesn't seem to unpack it. It doesn't support *.n64 extension. Even if I change it to acceptable one.

5 hours ago, h3x3r said:

Send me please unpacked n64 file. The tool doesn't seem to unpack it. It doesn't support *.n64 extension. Even if I change it to acceptable one.

it shouldnt be a .n64 file it needs to be a .z64 file. if you have a .n64 or .v64 file use this to change it to a .z64 file https://hack64.net/tools/swapper.php