Ridge Racer Revolution 3D Models

[coldnessinmyheart]

Hi,

I recently tried to find 3D models ripped from RRR online but seemingly nobody has ripped them until now.
Then, I tried different tools like Neosis and PSXPrev but with no luck.
I know it's possible to take 3D screenshots but the results are not very good.

I'm experienced with modern software development but never worked with such old hardware/software.

Maybe anyone can help here.
I'm especially interested in the 3D models of the race tracks. The final goal is being able to import the race tracks (with textures, of course) in a modern 3D modeling software like Blender.
The cars would be a nice to have.

Thanks for reading.

[scphscpe]

Look for 3D Model Researcher on Google. But first you need to extract the data from the game's archives, for this a hex editor for research and some basic programming will do the job, C, Python, anything you're comfortable with.

Usually game archives have table of content in them with offsets and sizes for each file, it's stored in the beginning or rarely in the end of the archive. Also, rarely they have actual names there too, but more often than not they're referenced by index or there can be some ID number or CRC value instead of the name, while offsets and sizes can be represented directly or in number of sectors. Size of each sector is 0x800 bytes on CD. In rare cases there may be no table of content in the archive, instead it's stored in the game's EXE and to find it you need to do some reverse engineering with the help of Ghidra decompiler in conjunction with an emulator that has a debugger, one helps another but using only one of them makes it harder. But that's not all, sometimes data can be compressed and on PS1 it's usually a variant of LZSS and similar algorithms, here Ghidra will do a great job in turning the game's machine code into readable C code which you can use for writing a tool for decompressing.

About models. Vertex coords will be represented in fixed point format, but you can read them as integers, same for normals, UV coords shouldn't be bigger than 1 byte for each axis because 256x256 is the max size of PS1's GPU texture page. Textures are usually stored in 4 bits per pixel and rarely in 8 bits per pixel, but they can be stored in various ways, either packed into an atlas that contains all the textures and palettes for them or as individual files in TIM format or even in some proprietary format that is not much different from TIM in nature. Obviously, if they're packed into atlases then you also need to reverse engineer how the game references them.

Also you can run the game in an emulator and poke around the RAM, find where models are loaded, change some bytes in their structure and see what they change on the screen, this can help figuring out their purpose in cases when the format is overly complex.

As you see this whole process can be quite complex, but each game stores data in a different way that can be either straightforward or over-engineered.

[coldnessinmyheart]

Many thanks for your reply. I'll look into this!

[jamieoliver]

Some emulators like BizHawk or DuckStation allow you to inspect VRAM and extract textures. NooDS is starting to include debugging tools that could be useful. You can also try using PCem with an older PlayStation emulator that allows debugging.
Slope Game