Crash Bandicoot 1/2/3 (PSX) - NSF/NSD File Archives

[chekwob]

Animation data didn't appear to be separated from the model when I tried forcing a bind pose on Crash Bandicoot's model

What do you mean by "forcing a bind pose"?

[chrrox]

make the model into a t-pose

[chekwob]

So it turns out those file extension-looking things are directly related to the entry types. This is the list I found in Crash 2 NTSC-U and my guesses/knowledge of the contents:

Code: Select all

NONE
SVTX	Object Animation(?), "Shape Vertex"(?)
TGEO	Object Model(?), "Thing Geometry"(?)
WGEO	Scenery Model(?), "World Geometry"(?)
SLST	Precomputed Scenery Occlusion Data(?), "Scenery List"(?)
TPAG	Texture Page
LDAT	Link Data(?)
ZDAT	Level Section (objects, collision)
CPAT*
BINF*
OPAT*
GOOL	Game Code
ADIO	Audio
MIDI	Music
INST	Instruments
VCOL	Vertical Collision(?), Virtual Collision(?)
LINK*
MDAT*
IPAL	Palette(?)
PBAK	Playback (i.e. Demos)
SDIO	Speech Audio
VIDO

(*) Not present in any NSF file

It all matches up, but a bunch of these types don't appear in NSF files at all. I'm thinking the game engine uses the same format internally for all kinds of run-time generated data as it does in the NSF files. So just because something doesn't appear in an NSF file doesn't necessarily mean that it isn't used internally.

I haven't made any progress on the models, sorry. Can't seem to figure out how they work.
I made some minor progress with editing level scenery. I can move some vertices around, but only the X and Y coordinates. I can't seem to find the Z coordinates anywhere.

[Friedslick6]

Man, all this time I always thought that .INST might be short for "Instance". "Instrument" makes way more sense.
Anyway, It's good that I managed to have some correct foresight for once lol.
About the Z-coordinates, to quote Andy Gavin's blog:

Dave and I experimented with pre-calculating the visibility and sort (the Playstation had no z-buffer, and hence no easy way to sort polygons) ahead of time on the SGI workstations the artists used. Although painful and expensive, this worked really well.

I'm guessing that acronym is a misspelling of CGI.
EDIT: Nope, stands for Silicon Graphics International.

[chekwob]

Download Link - CrashEdit v0.09

New version of CrashEdit, v0.09. This will let you mess around with the objects in-game, changing their positions, types, some settings, and a few other things. With the 3d area view thing, you can press D to undock it into a separate window, so you can glance over at it while changing settings in the objects. You can also use the arrow keys and A/Z to reposition the camera's focus point, and click+drag to change the angle and zoom. Just hit find and type "entity entry".

You'll have to rebuild the disc image yourself to test any changes, which can be complicated because of how PSX disc images work (they're Mode 2/Form 1 format, which is unusual). I'll work on making a program to do this later.

EDIT: Made the download link a bit more obvious.

[Friedslick6]

Wonderful development! The GUI's looking good.
Regarding the 3D preview textures, you may want to temporarily use the crate textures I ripped here. No credit required, just until proper textures are implemented.

[chekwob]

Something I forgot to point out in my post is that the 3d viewer doesn't quite work right for Crash 3, because the objects in that game are actually 4 times the size of the Crash 2 ones. So while boxes are 400x400x400 in Crash 3, they'll be rendered as 100x100x100 in the viewer because it's based off of Crash 2. This leaves a lot of spacing between objects, and makes adjusting the camera more tedious.

Wonderful development! The GUI's looking good.
Regarding the 3D preview textures, you may want to temporarily use the crate textures I ripped here. No credit required, just until proper textures are implemented.

I didn't use those initially for copyright reasons, but now that I think about it, I could add support so that if your texture rip image is in the same folder as the exe, it will use those instead. I think that's what I'll do.

[Friedslick6]

I didn't use those initially for copyright reasons, but now that I think about it, I could add support so that if your texture rip image is in the same folder as the exe, it will use those instead. I think that's what I'll do.

But then wouldn't any texture/model data previews will also be excluded for copyright reasons? That sounds like a good work-around...

[chekwob]

I didn't use those initially for copyright reasons, but now that I think about it, I could add support so that if your texture rip image is in the same folder as the exe, it will use those instead. I think that's what I'll do.

But then wouldn't any texture/model data previews will also be excluded for copyright reasons? That sounds like a good work-around...

My intent is for the program to rip the models and textures for the objects at run-time, so even if you found some weird modified NSF file with all kinds of different models, it would show them just like they would appear in-game. This is especially important because (IIRC) different level themes will have entirely different objects for a specific type:subtype pair, eg 4:0 might be a walking robot in the futuristic levels, while it might be a falling platform in the ruin levels (just an example, probably wrong in this case).

[Friedslick6]

Ah, okay thanks for clearing that up.

[chekwob]

I think I should turn everyone's attention to a thread on the HPZR forums:
http://hpzr.proboards.com/thread/7484/c ... ting-suite

An excerpt from that thread:

I'm currently working on a sort of hacking utility/editing suite for Crash 1. It's still at an early development stage so I can't release too many details, but as of right now I'm only able to view object models, level models, and disassemble executable GOOL binary code (GOOL is the scripting language that Andy Gavin/Naughty Dog developed for the Crash series; a majority of the game's function is the result of executing 'GOOL processes' for every conceivable game object, which are managed by the game engine in much the same way an operating system manages its processes, where a sort of inter-process communication/event based system allows objects to communicate with one another).

From the screenshots, you can see that there is a significant level of support for extracting level and object models for Crash 1 (although currently untextured). There's also some kind of GOOL bytecode disassembler shown in the screenshots.

This is easily the most significant work done so far (at least that I know of) on reverse-engineering the game. Although most of it applies directly to Crash 1, a lot of it is still very much applicable to Crash 2 and 3.

Anyway, that aside, there have been some stuff:

Entries actually have names, interestingly enough. I just assumed they were identified in an arbitrary numerical manner, but sure enough the "entry ID's" were specially-encoded strings. Credits to wurlitzerfox (from that thread) for finding this one. These strings can sometimes be pretty human-recognizable, so I don't think they are necessarily computer-generated. Names like "WillC", "FruiC", "BoxsC", and "ScrbC" show up for GOOL entries, for example, and they contain the code for objects identified by the same name.


SVTX is apparently the vertices for the object models. The polygon/texture-mapping data is held elsewhere, in the TGEO entries (or so I've come to understand, I don't know the specifics to this one). Presumably, each SVTX would be one frame or keyframe of animation for a given model, considering that texturing does not change between different frames of a given animation. Again credits to wurlitzerfox, he's the guy who's figuring out all this stuff.

As of commit ddc78cf, CrashEdit supports viewing Crash 1 level scenery (minus the texturing) and exporting to OBJ and COLLADA formats, although blender really doesn't like opening the output models (maybe they're too big or something? I think I should scale them way down). Noesis supports them just fine, though. There's no vertex color support in OBJ, which means all you'll get is vertices and colorless, untextured polygons. It's really unfortunate, because the only format I know of that supports this is COLLADA, and that's a super-complicated (and surprisingly strictly trademarked) mess. I don't think I'm even exporting to it properly, either. Anyway, there's no compiled build for this version of CrashEdit, but I can make one if someone requests.

I've got some part of the Crash 2/3 scenery models down (vertices are good, polygons are not yet understood). Nothing reliable enough so far, though. (EDIT: oh yeah, I found the Z coordinates by the way)

Anyway, that's all I can think of right now. That guy's reverse-engineering progress is amazing. All kinds of great stuff is coming from that.

[ikskoks]

Anyway, there's no compiled build for this version of CrashEdit, but I can make one if someone requests.

I request :3

The most interesting feature from that post you linked is audio editor. It would be amazing to record voices in different languages and create a dubbing. Also font and text editing would be appreciated by translators. ^^

I wish good luck and many thanks for you and wurlitzerfox for making impossible possible!

[chekwob]

https://www.dropbox.com/sh/yv93g4wsdde3 ... netest.zip
This version's a bit modified, adding a "View all C1 scenery" option to open a window displaying the entire level's scenery.

You can do a search for "scenery" with the find feature, and hit "find next" to cycle through them. You'll most likely get a lot of errors when opening the NSF files because the program still doesn't fully support crash 1 NSF's yet, but it's enough to read the models and view/extract them. There will also be duplicate scenery entries for the non-beta versions because of the way the editor handles the crash 1 retail version's compression system (or rather, that it doesn't). This is all stuff I'm trying to iron out before I up the version number to v0.10.

Again, NOESIS is the only thing I've found so far that will actually load the output COLLADA file. However, you can open it in NOESIS and then save it back out again from there and then blender will be able to open it. For some reason, Blender doesn't recognize the colors at all. Makes me wonder if Blender even supports vertex colors.

EDIT: I should mention, you can drag with the mouse to zoom/rotate the camera, and the arrow keys and a/z keys to move the camera's focus point.

[Friedslick6]

I think I should turn everyone's attention to a thread on the HPZR forums:
http://hpzr.proboards.com/thread/7484/c ... ting-suite

From the screenshots, you can see that there is a significant level of support for extracting level and object models for Crash 1 (although currently untextured). There's also some kind of GOOL bytecode disassembler shown in the screenshots.

This is easily the most significant work done so far (at least that I know of) on reverse-engineering the game. Although most of it applies directly to Crash 1, a lot of it is still very much applicable to Crash 2 and 3.

That's a huge development update! I'm trying to wrap my head around it as I write this. A thanks to you and wurlitzerfox for your continued efforts.

As of commit ddc78cf, CrashEdit supports viewing Crash 1 level scenery (minus the texturing) and exporting to OBJ and COLLADA formats, although blender really doesn't like opening the output models (maybe they're too big or something? I think I should scale them way down). Noesis supports them just fine, though. There's no vertex color support in OBJ, which means all you'll get is vertices and colorless, untextured polygons. It's really unfortunate, because the only format I know of that supports this is COLLADA, and that's a super-complicated (and surprisingly strictly trademarked) mess. I don't think I'm even exporting to it properly, either.

The most compatible option would be a COLLADA format w/ baked maps and a separately baked alpha map, imo. Compatibility can be dealt with externally though, so it's not a high priority. Ultimately it's just impressive that model conversion is a reality at this point.

Edit: Changed opinion

[chekwob]

v0.10 is out.

• C2/C3 level box count can be changed (it's a property set in obj_willy). You can also make it negative. I'm not sure why you would want to do that, but it works and the game renders the "-" sign properly and everything.
• The entityentry viewer now shows objects in nearby entries, making it easier to identify which part of the level the entry defines.
• You can use Friedslick6's box texture rip (found here) by saving the image into the same folder as CrashEdit and naming it Textures.png.
• C1 scenery entries are viewable in 3d, untextured, and may also be extracted in OBJ or COLLADA format. The COLLADA export function is broken, and you will need to import the model into NOESIS and save it back out to correct this.
• There is now a game version selection window which will prompt you to select a game version when opening an NSF file.
• You can now save Crash 1 retail NSF files, but will discard the "chunk prelude" if you do so. You will also need to zero-out the bytes 0x418 to 0x4AF in the associated NSD file so that the game knows the prelude is absent. This will increase load times for that level. Note that the two beta versions were already supported because they do not use these preludes.
• If you open a Crash 1 NSF file you will receive a warning about VABv6 not being fully supported. This is very minor and can safely be ignored.

Right now I have a bunch of work to do on crash 1 models, both object and scenery, so that might be my next milestone for v0.11. We'll see.