Ghostbusters The Videogame .smb model format

[AxelNoir]

Hello, I wonder if anyone has any idea about the .smb file format used in the Infernal Engine for Ghostbusters: The Videogame? There doesn't seem to be much documentation on it but there are some tools to extract from other games on the same engine and format like BloodRayne. I've attached a sample if anyone is curious to take a look at it, looks to be little endian with a few submeshes inside and bounding box from what can be seen but I haven't gotten past that.

weap_trap.7z

[Sparagas]

Silent Hill: Book of Memories also uses Infernal engine, but it has no tools for it (yet).

[AxelNoir]

BloodRayne 2 also has tools that are fully fleshed out as far as I know for various formats for the game, one of them being .smb. However the format isn't the same for Ghostbusters it seems and I can't find any other information or research on the format for GBTVG that is different to the other games on Infernal Engine at the moment.

[shak-otay]

One sub mesh using hex2obj:

[sakis720]

Hi, I know am a little bit late but I have been trying to reverse this format, I have to say I have reversed/understood this format about 85-90 precent but am stuck at one problem that I want to discuss and maybe someone can help me.

So what is my problem? I have created a tool that creates new .smb files so you can put any custom model you want in the game but my only problem is referencing materials. Material reference start after the header, as you can see at image I have uploaded in this model we have 2 materials "parade\elevator2" and "old_fence" (collision_box01 is the sub mesh header that we don't care about) and between them they have a weird spacing. This weird spacing I haven't understand why its there and I don't know how it works. And if you try to reference new materials you are going to be greeted by errors, so this weird spacing plays a huge role for this format.

Here is some models and if anyone want to play around and figure out how this works.

samples.rar

[shak-otay]

...

Edited September 21 by shak-otay

[DKDave]

4 hours ago, sakis720 said:

Hi, I know am a little bit late but I have been trying to reverse this format, I have to say I have reversed/understood this format about 85-90 precent but am stuck at one problem that I want to discuss and maybe someone can help me.

So what is my problem? I have created a tool that creates new .smb files so you can put any custom model you want in the game but my only problem is referencing materials. Material reference start after the header, as you can see at image I have uploaded in this model we have 2 materials "parade\elevator2" and "old_fence" (collision_box01 is the sub mesh header that we don't care about) and between them they have a weird spacing. This weird spacing I haven't understand why its there and I don't know how it works. And if you try to reference new materials you are going to be greeted by errors, so this weird spacing plays a huge role for this format.

Here is some models and if anyone want to play around and figure out how this works.

 

 

 

samples.rar 16.41 kB · 2 downloads

 

The material names are just padded to start on the next offset that is a multiple of 4 bytes (either 0, 4, 8, 0x0c).

 

 

 

[sakis720]

[AxelNoir]

On 9/29/2025 at 5:00 PM, sakis720 said:

Huh nice work man! Looks like you finally got this working, cool! Any plans to release it soon?

[sakis720]

They are two seperate tools one for creating new smb's and one for viewing them and exporting them. Am planning to update the obj2smb tool this week as for the other tool I don't have an estimate, the tool still cannot open some specific smb files.

[sakis720]

Hi once again. I have been updating both of my tools but today as I was implementing the collision support for the obj2smb tool I ran into a roadblock. Before I explain my problem I want to explain how the collision works. The collision starts right after the material reference(s) it consists by:

48 bytes // name of the collision mesh
4 bytes // version "6"
4 bytes // ? (in most cases its null)
4 bytes // vertices count
4 bytes // faces count

Right after the vertices start which are stored as 3 float32(12 bytes) and after the vertices the faces begins which are stored as unit16 values(2 bytes per index) so each face is 3 indices (6 bytes per triangle).

After the faces the "CBoundingVolumeTree" begins:

12 bytes // of padding
4 bytes // version "3"
4 bytes // ? magic number (C4 00 00 00)
24 bytes // ?
4 bytes // null
2 bytes // 8
2 bytes // 12
96 bytes // Same vertices as above
2 bytes // header? (20 88)
70 bytes // ?

My problem is I don't know what these 24 and 70 bytes represent or how they work. 

Thanks in advance.

samples.rar

Edited October 11 by sakis720
Researched the file a little bit more.

[Tosyk]

nice work @sakis720! any plans to add bones?

[sakis720]

On 10/10/2025 at 12:58 AM, Tosyk said:

nice work @sakis720! any plans to add bones?

The SMB format doesn't include bones only static models. But on the other hand the models that have bones are named BFM and they already reversed engineered by @id-daemon.

[sakis720]