Reverse engineering of Wipeout

[tigrou]

I advise you to follow some tuto on youtube. That's how i get started. Unity seems to be a little bit intimidating at start but it's actually pretty easy.

About you debug issue : why don't you use MonoDevelop?

[aybe]

Ok, I've got something on screen, have a couple of things to do before rendering a track, stay tuned ...

EDIT

I'm getting familiar with the thing and it's pretty good though it crashes from time to time ... re-used most of my low-level classes with little to no changes, in probably 2-3 days I'll have something up (hopefully)

[aybe]

To be continued !

Snap886.jpg

[aybe]

Here's some more Unity treats

snap0887.jpg

Still fighting a bit with Unity tutorials but now on the track to get busy with physics

[tigrou]

Good progress

Is it Altima VII ? if yes, it seems the whole track is flipped around the X axis.

- - - Updated - - -

trivia : on DEMO01 CD (official demo CD delivered when PSX comes out), there is a Wipeout demo.

The CD had to be ready before the game was released so Wipeout was probably still in beta stage.
In "Wipeout" folder, on CD, there is TIM files (textures) that does not look like regular game textures but rather from an editor for the game.

Why TIM files ? was the game developed on machine similar to the PSX itself ? or was the editor running directly on PSX ?

Here is a screenshot of them and my comments (this is pure speculation from me)



BOOM, BOOMW: an unfinished weapon icon ?
BUG : call technical support ?
CAMERA : probably allow to define cameras along the track
CHNGTRK : edit track faces textures ?
DPA: ??
EBOLT, ECM, ELECT, FLAR, MINE, MISS, NEG, ROCK, SHLD, TURB : related to bonuses. in the first ever wipeout, were the bonuses placed directly on the track (instead of a "X" cross ?). Or is this to view bonus 3D models ? or to test debug (because the editor run "in game") ?
HALO : ?
EMPTY : ?
LNDONOFF : to switch the land (the scene objects around the track) on/off
RADIUS : to define bounding spheres around scene objects, for occlusion culling.
SAVE : pretty obvious. suprisingly there is no load icon
SHIP : to set start position of the ships, or to view 3D model ships in game ? AFAIK, the ships start positions are determined by texture indexes on track (to confirm)
SKY : turn skybox on/off
SMOKE : to add some smoke particles ? (as seen in talon's reach )
TRAKVIEW : track visiblity on/off ? or is it related to VEW files ? (to view actual culling performed at a given position?)
TRANSTRK : to edit track structure ? (eg:extend track on the side, create a tunnel,...)
VRAM : PSX vram debugging (eg : to view loaded textures, actual framebuffer ? ...).

[Xpand]

Some of those images seem to be part of some developer's debug menu. It isn't rare for developer tools (eve if it's just some part of them) to be left in the final game's files.

Those files are also in the final release version of the game.

[tigrou]

Those files are also in the final release version of the game.

I did not know that. I would be cool if it was left there and it would be possible to reactivate it.
Anyway the exe seems to not reference any of these files (while the other seems to be referenced) :/

So either there was two EXE's files, or there was two builds (compile switches)

[aybe]

And they are also in the PC version, can't remember exactly where ... and yes it's Altima VII.

I've been trying to get hold of this ptiDebug variable on the disassembly in hope this infrastructure was still in place and could be triggered but without much success

Bit of progress in Unity:

I have a ship that moves and hovers now ! but it can leave the track very easily
I need to get hold of how to constraint it close to it as well as the angles as it can become reversed ... any clues are welcome

[Xpand]

What we did for slipstream GX was to basically override Unity's physics regarding rotations and gravity. We use rigidbody components on the ships with frozen rotation and no gravity. The rotation in each axis is then calculated with a script, same with every force on it. That gives a lot more control over the ship.

It'd be a good start to look at the forces in action on a plane, because it's exactly the same thing:

[tigrou]

I was going to post something but Xpand was faster than me

Here is my two cents :

- either constraint rigid body movement (eg : rotation on X/Z axis) so it wont happen. check rigidbody panel properties; some movement (eg : roll) can be purely visual. to do this you can add ship model inside another parent object and rotate only that one. this is probably Xpand direction (no joke here ).
- (or) apply a stabilize force (torque) that make sure the ship is always up right. you need measure the difference between actual ship orientation and a target orientation and apply a force accordingly. (like a putching ball)

something like this : http://answers.unity3d.com/questions...l#answer-10426. Might be unstable or unable to handle violent collisions.

[aybe]

Thanks trying to apply your suggestions !

The plane analogy is really great and it seems the way to go as well as constraining rotations.

I have some sort of a plane for now, it does lift off a bit like WO does but it's really naive ... found a plane sample that I'm trying to pick ideas from.

A rough guess is that such kind of physics would more or less give what's needed like aero brakes and so on.

But I've never done any physics as of yet so this is likely to take a bit of time

[Xpand]

Here's a code snippet of an Anti-gravity physics engine I'm programming in C:
This takes care of the vertical portion of the forces on the ship:

player->acc.z=player->gravity+(20.0/(0.1+fabs(player->pos.z-player->proj.z))-player->vel.z*player->vel.z*player->vel.z*2.0)/player->mass;

the K/(A+fabs(height)) bit does the AG magic, making the ship float around a certain height above the ground. I can make the ship float higher or lower by increasing or decreasing "K" and make the ship respond more or less to the variations of the track by adjusting the "A" parameter (and also avoids that whole thing becoming infinite when the height is zero).

The three velocity components vel.z take part in damping the ship's wobble. It's basically the drag force present in that airplane diagram, only in the vertical axis. It's there just so the ship's oscillation decays with time.

[tigrou]

I remember I wrote (some months ago) a game similar to wipeout with a constant force to be applied from the ground. This was prototype wrote for testing only.
The vertical push force was not stable and wobble a lot. I solved this by using a simple PID controller :

distance_target = 5.0 //we want object to be always 5 units above the floor
distance_to_ground = cast a ray from object to the floor

error = distance_target - distance_to_ground 
derivative = error - last_error

// kp and kd are constants to be adjusted (stability vs speed)
force_to_apply = error * kp + derivative * kd

last_error = error

[aybe]

Thanks everyone This comes in really handy and I hope I'll be able to apply all these tips, I sort of found a couple of decent links yesterday about all this but I still need to read them. I'm quite confident that I'll get to it ... one day ! This is an entirely new topic to me so it's pretty much sound like Chinese to me for now.

[aybe]

I remember I wrote (some months ago) a game similar to wipeout with a constant force to be applied from the ground. This was prototype wrote for testing only.
The vertical push force was not stable and wobble a lot. I solved this by using a simple PID controller :

distance_target = 5.0 //we want object to be always 5 units above the floor
distance_to_ground = cast a ray from object to the floor

error = distance_target - distance_to_ground 
derivative = error - last_error

// kp and kd are constants to be adjusted (stability vs speed)
force_to_apply = error * kp + derivative * kd

last_error = error

this works really well

@Xpand still trying to digest your formula

[Xpand]

Well it uses real physics (I'm a physics engineer, so I guess that might have something to do with it), hence why it seems more complicated, but it's nothing more than the forces that would exist if the ship existed in real life, with a bit of tweaking for optimization.
The main thing to retain is the "K/(A+fabs(height))" bit, which is basically the equation for the upward force created by a compression spring (like car springs), and the vel.z^3 works as the damper in a car's suspension.

Basically what I have there is:

acceleration in Z axis = gravity + (lift_force+damp_force)/mass

Tigrou's method is best for performance on the long run though, I'd use his idea if I didn't want to waste too many resources calculating the ship's behaviour (although my method doesn't take that much more, it's just because it uses a division operation), or if I wasn't too worried about how accurate the floatiness would be (mine takes into account the ship's mass (inertia) and gravity)

[aybe]

I'll definitely give a try to your method, it's just that it takes time for me to understand this new topic

That's about 2-3 days now I'm on the physics thing and I guess it's going to take quite some time by now, I am confident however !

Here's my little training field :

snap0892.png

- - - Updated - - -

I haven't been able to reproduce your snippet

        var gravity = Physics.gravity.y;
        var zPos = carRigidbody.position.z;
        var zProj = 0;
        var zVel = carRigidbody.velocity.z;
        var mass = carRigidbody.mass;
        var zAccel = gravity + (20.0f / (0.1f + Mathf.Abs(zPos - zProj)) - zVel * zVel * zVel * 2.0) / mass;

I don't understand what

player->proj.z

is supposed to be.

Also, I might have missed something but, how does this works against Y axis since you never update it ?

thanks

(as you might have guessed, I lack complete knowledge about the subject topic , right now I'm still on the phase of copy/paste/run )

[Xpand]

I'm so sorry, I just copied that from my engine, which uses that variable to get the height of the ship above the track (it calculates proj.z from the projection of the ship's X and Y position on the mesh triangles of the track to get the distance of the track's surface to z=0). It's native to my engine, and not a generic thing (you don't need to use it).

In sum: (pos.z-proj.z) is "height":
K/(A+fabs(height))
You need to tweak the numbers to your liking, hence why I wrote K and A, they're just numbers you choose.

Also in my case the Z axis is vertical. It might not be your case (just change it to the Y axis).

[aybe]

Okayyyy that's what I just thought and been thinking it was a trap you just set for me

I have been able to get some cool results, but it's kinda hard to really understand how the thing works without proper context. Basically for both of your suggestions, they are applied when a ray cast hit is true and then I apply that force to the car (I guess it's correct since both formulas are working).

But your formula brings in 2 other interesting properties : it gets affected by mass and drag (defaults of 1.0, 0.0) while @tigrou's formula is not ... it's like in the Universe -> you discover 1 thing but there are newcomers ... I guess I'll have to document myself a bit more on the overall subject ! This just got me for today but I'll see tomorrow.

Also, I hate those non evocative variable names usually found in math formulas (K, A) but I reckon it's the usual approach. I've been trying to come up with ones a bit more meaningful : stiffness and feedback but this is pure speculation from me. Would you qualify them as such ? thanks

[Xpand]

K is stiffness, higher K makes the ship float higher and makes it harder for it to hit the ground. A is the "give". It's kinda hard to find a word for it. "A" basically determines how violently the ship will react when its height approaches 0. If A=0 then as the height approaches zero, the lift force will tend to infinity, if A=0.1 the lift force will be K/0.1 when the height=0. It provides control to avoid very larger force values that will make the ship shoot up to the sky if it hits the track.

By the way, since Unity already simulates drag, you don't need to have the drag portion of the equation there (the vel.z*vel.z*vel.z), I had to add that because my engine assumes drag is included in the acceleration equation and it's not a separate thing.