Game Research Forum
https://forum.xentax.com/
What do you mean by "forcing a bind pose"?Friedslick6 wrote:Animation data didn't appear to be separated from the model when I tried forcing a bind pose on Crash Bandicoot's model
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
I'm guessing that acronym is a misspelling of CGI.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.
Wonderful development! The GUI's looking good.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 wrote:
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.
But then wouldn't any texture/model data previews will also be excluded for copyright reasons? That sounds like a good work-around...chekwob wrote: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.
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 wrote:But then wouldn't any texture/model data previews will also be excluded for copyright reasons? That sounds like a good work-around...chekwob wrote: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.
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.wurlitzerfox wrote: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).
I request :3Anyway, there's no compiled build for this version of CrashEdit, but I can make one if someone requests.
chekwob wrote: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.
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.chekwob wrote: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.