Reverse engineering of Wipeout 3 SE

[aybe]

EDIT

Here is the suite of 4 utilities to unpack PBPs for WO3:

• a GUI app that will process a folder of many PBPs
• individual command-line tools to deal with PBP, CMP, TIM
• (the UnpackCMP and UnpackTIM also work for Wipeout 1/XL/PC)

here: https://github.com/aybe/WXX-Rebirth/releases/tag/latest (check README.TXT)

There won't be anymore updates as I think they are mature enough : they successfully produced nearly 40K files (all WO3 versions).

---

Houston, we have track data !!!



After much struggling with those command-line utilities, here's finally some result !

There's still a lot to be done but this is motivating nonetheless.

[Xpand]

You're doing an amazing job man! Congrats!

[aybe]

Thanks

[tigrou]

Great job. I'd like to help but don't from know where to start.

Anyway: which track is this ? (I'm not a Wipeout3 fan at all, I mostly played WOXL and W1 (a little bit)).

I can't find it there : http://wipeout.wikia.com/wiki/Wipeout_3

Also why are textures like that (flat single color) ?

[Ace3000]

That's one of the Prototype tracks. You get them by completing certain things (I know it has to do with single race mode).

Also, the "flat colours" are part of the Prototype tracks art style. There are about 6 Prototype tracks in total, all of them have that minimalistic style except for a couple.

[aybe]

Great job. I'd like to help but don't from know where to start.

Anyway: which track is this ? (I'm not a Wipeout3 fan at all, I mostly played WOXL and W1 (a little bit)).

I can't find it there : http://wipeout.wikia.com/wiki/Wipeout_3

Also why are textures like that (flat single color) ?

I am going to publish a new tool and an Excel file prolly within 2-3 days, currently working on the spreadsheet to try identify what is what and so on ... the new tool is way better/faster, what used to take nearly 30 mins now barely takes 2 mins -> the extraction of every PBP. I manually checked WO3SE and it pretty much recognized 99% of files, there are 39530 files BTW And the tool is a GUI, no more command line , just choose input/output folders and watch it extract.

The plan:

• find which PBP is which track
• try attack the hintful ones (proto 2, 3)

Also I should get this 3d vertex picker up as I guess it'll be mandatory because while plot.ly is great to quickly preview data, it doesn't show much infos.

[aybe]

Quick update

The new unpacker:
snap0815.png

A track's vertex data:
snap0816.png

Will post the unpacker soon !

[tigrou]

@aybe : its getting interesting, I hope you keep working on it !

Note : on wipeout central the W3 tracks drawings looks really precise.



I would not be suprized somebody already found a way to parse track format...

[aybe]

1/
I didn't notice there were HQ drawings for the non-prototype tracks

2/
For WO3, see my final release of the tools:
https://github.com/aybe/WXX-Rebirth/releases/tag/latest

They will also work for Wipeout 1/XL (for CMPs and TIMs), make sure to see the README.TXT first !

3/
I haven't really made any progress in WO3 beside fine-tuning and finishing the above tools, like I've seen you enhancing the WebGL experiment recently, I am focusing on it to get WXX-Rebirth on par with it first.

I've finished the loading of textured models and the surroundings such as packing textures:

snap0824.png

snap0825.png

snap0823.png

I am close to get the same LOD that there's in the experiment, the next big step in comparison to the experiment will be to object-ify scene objects so they can be used in a game.

4/
Regarding formats of Wipeout 3,

• I'm pretty convinced the vertex data is the same since it's on PSX
• Objects now are presents and there should be indices pointing to them, unpack a track's PBP and search for strings such as CUBE, you'll find them

When you unpack a PBP you will see that:

• 4 small files with lots of blanks
• probably track-related data
• track vertices
• probably billboard stuff since textures are right after
• track sections or something
• track textures
• 2 groups of ship-related data (depends though)

Do not hesitate to share your findings or ask for help, multiple pairs of eyes are likely to help in deciphering all this mess.

5/
Basically once I reach about the same rendering as in the experiment I will take some time for WO3.

PS: in the WebGL experiment, do you know what the track faces and sections are representing ? thanks

[Xpand]

Track faces are the triangles created by a set of three vertices. Their format is something like this:
You have a set of vertices:
vertex0
vertex1
vertex2
vertex3
...
vertexn

your faces are, in a generic way:
face(i): {index of vertex ,index of vertex,index of vertex}

example:
face1: {0,1,2}, uses vertex0, vertex1 and vertex2.

About the track sections I think it has to do with how to know what track section is a corner, what track section is the starting line, what track section is the pits, where the speed/item pads are, etc. probably for both texture placement and game logic

[miljoneir]

@aybe : its getting interesting, I hope you keep working on it !

Note : on wipeout central the W3 tracks drawings looks really precise.

I would not be suprized somebody already found a way to parse track format...

I guess these images came from the wipeout 3 'kleber' website.

[tigrou]

Hi,

@aybe : the following files are used in W1/WOXL :

- TRV : contains all track vertices (x, y, z 3D points)
- TRF : contains all track faces. basically an array of indexes that references the vertexes in TRV file. This allow same vertices to be shared between triangles (as XPand explained). All objects around the track (tunnels, mountains, bridges, trees, ...) are stored separately, in the SCENE.PRM file.
- TRS : track sections. this is a double linked list of 3D vertices that represent the track curve. in other words, a list of points that follow the track.

This is used for lot of things :
- physics : collision is performed only with triangles (track faces) in current section (where the player is), not the whole track.
- rendering : each section contains a list of 3D objects to display (precalculated before). So, the game only render triangles visible from player position (occlusion culling).
- game AI + autopilot (CPU ships knows which points to follow)
- checking who is 1st , 2nd (ranking)
- checking if player passed over a weapon / boost / repair tile, ...
- ...

[aybe]

Track faces are the triangles created by a set of three vertices. Their format is something like this:
You have a set of vertices:
vertex0
vertex1
vertex2
vertex3
...
vertexn

your faces are, in a generic way:
face(i): {index of vertex ,index of vertex,index of vertex}

example:
face1: {0,1,2}, uses vertex0, vertex1 and vertex2.

About the track sections I think it has to do with how to know what track section is a corner, what track section is the starting line, what track section is the pits, where the speed/item pads are, etc. probably for both texture placement and game logic

that totally makes sense, I was getting confused with PRMs but tracks are not PRMs, thanks

- - - Updated - - -

Hi,

@aybe : the following files are used in W1/WOXL :

- TRV : contains all track vertices (x, y, z 3D points)
- TRF : contains all track faces. basically an array of indexes that references the vertexes in TRV file. This allow same vertices to be shared between triangles (as XPand explained). All objects around the track (tunnels, mountains, bridges, trees, ...) are stored separately, in the SCENE.PRM file.
- TRS : track sections. this is a double linked list of 3D vertices that represent the track curve. in other words, a list of points that follow the track.

This is used for lot of things :
- physics : collision is performed only with triangles (track faces) in current section (where the player is), not the whole track.
- rendering : each section contains a list of 3D objects to display (precalculated before). So, the game only render triangles visible from player position (occlusion culling).
- game AI + autopilot (CPU ships knows which points to follow)
- checking who is 1st , 2nd (ranking)
- checking if player passed over a weapon / boost / repair tile, ...
- ...

Hi, thanks, that's really what I was looking for and is going to keep me busy for a while !

I am close to get flat/textured models done and once it is I'll attack the tracks.

Have you tested the PBPunpacker and others I have posted ? (feedback appreciated)

[aybe]

I finally got textured objects working but I do have a strange effect, I can see through the model:

snap0839.png

Any ideas on what is causing this ?

Basically I use exactly the same code since those PRM structs are identical except that when it is a face, there is only one color; I am starting to wonder whether I mis-understand the logic of faces ... idk

thanks

EDIT : was my fault, SpriteBatch messes the GraphicsDevice, proper states should be restored before drawing

[tigrou]

I can see through the model

It's probably because back face culling is activated, and you are rendering triangle in the opposite order.

Try reverting the order you render triangle vertices (CW vs CCW). It can also depend of a flag inside the model.

[aybe]

It's probably because back face culling is activated, and you are rendering triangle in the opposite order.

Try reverting the order you render triangle vertices (CW vs CCW). It can also depend of a flag inside the model.

It's that SpriteBatch that messes everything, I was starting to wonder my code was not enough for faces but it works very well. Only the tracks are missing now and I'll have some great visuals then !

[Xpand]

That's pretty neat! I actually rebuilt the ships from scratch a few years ago, but it was through working my way through broken texture fragments and meshes that vincoof managed to extract from the graphics buffer, so some bits were off:

[aybe]

That's a really great render

[aybe]

Hey,

just IDA-ed the MAC OS X of Wipeout and there are pretty cool things in it such as the name of subs:

snap0889.png

seems like they forgot to obfuscate it !

[tigrou]

@aybe : that is really cool.

C/C++ is always sort of "obfuscated" anyway (unlike C#/Java or more high level languages).
I think what happened is this : the game exe which is released for MAC OSX version is compiled in debug mode (by mistake probably or because MAC OS X C/C++ include that by default). This is probably what is used by IDA. or maybe RTTI is turned on (this is something similar to reflection in C#).

By looking at methods names it confirms one theory we discussed before : most objects around the track are animated done using custom, hardcoded methods (instead of being defined by data in PRM files).

EDIT : could you maybe post a full list of all methods (here or by PM?) thanks.