Reverse engineering of Wipeout

@Xpand : interesting.

The formula I give (PID) is a general purpose method. This can be used to control systems using a feedback loop (with stability and precision to a certain degree).
Some specific formulas that model concrete physics models (like the one you give), might, however, work better or be more precise.
I would not care too much about CPU performance on today computers. This should not be the bottleneck. I would simply choose a method that can be tweaked easily and give the best gameplay. That is the most important aspect to me.

About the formula you give :
"K/(A+fabs(height)) " and also " vel^3 " where does this came from ? do you have any reference, paper, wiki page? (for learning) i'm (unlike you) not a physical engineer :redface:

I took a look at Hook formula, but it seems to be not that thing.

about "dividing the force by mass", it came from F = m a right (pretty basic stuff :D)?

Yes, you divide force by mass to get acceleration, like Newton's 2nd law states: F=mass*acceleration

about the K/(A+fabs(height)), it's a cheat that comes from, for example, the electrostatic force between two charged particles: Fe=Ke*charge1*charge2/(r^2), which states that the repulsion/attraction force between two charged particles is proportional to their charge and inversely proportional to the square of the distance between them (as distance increases, the force decreases). I just considered "Ke*charge1*charge2" as "K" and since I wanted to save some processor cycles I used the absolute value of the distance between the track and the ship fabs(height) instead of calculating its square. I added the "A" to avoid problems with division by 0, like I stated in my previous post.

The vel^3 (cube power of the velocity) comes from the aerodynamic drag equation:
http://upload.wikimedia.org/math/9/9...7b238e5de9.png
all those variables have a meaning you can see here: http://en.wikipedia.org/wiki/Drag_%2...#Types_of_drag I just made them all "2.0" for now.

I know it says v^2 in that equation, I used v^3 because I want to take into account the sign of the velocity (if it's negative or positive), so the force points opposite to the movement of the ship. I can use the v^2 just like that equation, but then I have to multiply by v/abs(v) to get the sign of the force (v/abs(v) can be -1 or 1), but again, to save processor time and avoid divide-by-0 problems I just used the v^3.

The PID method is good for setting variables that you can consider independent, like temperature in an oven, position of a mechanical arm, etc. For something that requires other stuff to characterize it (like a force), the PID leaves out those important variables and treats the force as an independent thing (when it isn't). Because this is a game PID would probably be a better choice than doing a physical simulation of the whole thing due to its simplicity, and I'm pretty sure they used it in the first Wipeouts. When rigidbody physics come up, you get stuff that depends on other stuff and differential equations everywhere, and PID just doesn't cut it.

You guys rock, Amazing how much work .. I checked all your formulas, :dizzy :eek , yes,yes it's all right :g lol

Quote:

---

Originally Posted by Xpand

The vel^3 (cube power of the velocity) comes from the aerodynamic drag equation:
http://upload.wikimedia.org/math/9/9...7b238e5de9.png
all those variables have a meaning you can see here: http://en.wikipedia.org/wiki/Drag_%2...#Types_of_drag I just made them all "2.0" for now.

I know it says v^2 in that equation, I used v^3 because I want to take into account the sign of the velocity (if it's negative or positive), so the force points opposite to the movement of the ship. I can use the v^2 just like that equation, but then I have to multiply by v/abs(v) to get the sign of the force (v/abs(v) can be -1 or 1), but again, to save processor time and avoid divide-by-0 problems I just used the v^3.

---

Surely velocity cubed would make the drag parameter unphysical/unrealistic? Would it not be better to define a Heaviside function using logic to ascertain the direction of the drag e.g....?

if (v < 0) {
sign = -1;
} else {
sign = 1;
}

and therefore have your velocity squared again.

Oh indeed. I forgot about that function (which is weird because I use it so many times in other stuff)! Thanks!

The velocity^3 would be unrealistic in the sense that the dampening would happen a lot faster than with v^2. Which isn't necessarily a bad thing, but yeah its real world equivalence is the drag Power and not the drag Force: http://upload.wikimedia.org/math/e/3...82a89503b1.png

Things are stalling over here ... :frown: @Xpand I've somehow tried to 'upgrade' your code with a hover distance but failed miserably, I've also looked at 'hovercraft physics' on the web and got a cube to hover manually, then I tried to use that PID approach on it but again I failed ...

Also I've been looking at thrust/torque, while I can move and turn fine another problem surfaced : it never stops since I'm not on the ground ! Applying a physic material on the rigid body obviously did nothing...

Just to make it clear : should I completely bypass Unity's physics system and think of everything or are there are physics-related things you'd keep on ? (beside constraining X and Z rotations)

thanks !!!

You just need to constrain the rotations, because you'll have a rolling ship everytime you enter a banked corner otherwise.

For the linear movement just use the AddForce command in Unity: http://docs.unity3d.com/ScriptRefere....AddForce.html
Also use the rigidbody.drag property so your ship doesn't accelerate without limit and slows down when you stop accelerating.

The rotations you have to work with angles directly and transform rotates.

Ok I'll give it a try and post my results ! thanks !!!

EDIT also, I found that script posted by the BallisticNG author and this is really a good hint; however it cannot be a simple copy/paste, will have to digest those 900 lines and hopefully I'll have something solid !

- - - Updated - - -

Works very well, victory :rock

Next step is to try upgrade your script with hover distance :D

When I get comfortable enough I will start looking at sources of BallisticNG and AGR2280 !

I love the look (graphics) and feel (physics) : https://www.youtube.com/watch?v=zuy9sryZSIc

It is very PSXish (it is intended I guess)

Now imagine being able to play this with all W1 & WXL tracks :hyper

EDIT : oops, seems it is discussed on this forum : http://www.wipeoutzone.com/forum/sho...project/page13 :redface:

Yes it's pretty good but it runs way too fast, I can't stop hitting walls ! There should be some Vector class IMO :P

@Xpand

here's the situation here:

I've been striving to do some of the ship physics all by myself, from scratch :D

Using 4 hover points, an angular drag of about 20 and not constraining the rotations : the thing is quite 'okay' in the sense that I've got an automatic leveling to the surface below myself and it's quite realistic. But there were 2 major issues occurring then : this was undesired when on edges of the track and whenever on air the ship was not leveling to the horizon or whatever.

So I began trying address the 'on-air' issue but it just seems that in the end, to get an 'enjoyable' game one has to resort to all kind of hacks (understand here not rely at all on physics provided by Unity), just like the BallisticNG ship controller code that has been posted recently on the forum.

My question is : is this really the way to go or is there a slight hope in getting cool craft physics using the facilities provided by Unity ?

thanks :D

Enjoyable gameplay is indeed riddled with hacks. You have to "bend" the physics engine to your will, and do some trickery for it to do what you want. That happens in pretty much all games.

I kind of forgot there were programming patterns recently as I was quite amazed by Unity, but that definitely makes sense.

Okay, I'll just base myself on that BallisticNG ship controller code then and see if I can improve/tune it to my needs ... thanks :+ :+ :+

@aybe : can only agree with Xpand.

About your hover issues : have you tried the following : when you shoot rays against the track, you do it against a special collision track 3D model that has only the "ground" track faces set (these faces have a special flag in the TRF file). These are the one that rise up/down quickly when you use the "Quake disruptor" weapon. Only these faces should be considered when calculating ship/floor distance or actual track orientation.

BTW, you consider ALL track faces when performing regular colisions, because you want don't want ship to go out the track.

To avoid issue with gaps : if a ray does not collide with anything, simply take the latest valid result (that you keep somewhere) :

Code:

---

if(ray.hit(..., out result))
{
  lastValidHit = result;
}
else
{ 
  //oops, there is a gap, take latest result
  result = lastValidHit;
}

//do something here with "result"
...

---

or you might consider another approach : the idea is to always have a 3D track orientation for any given ship position. I supsect the original game to do something like that since it's quite easy to calculate. Not need to shoot rays. Here how to do : you loop trought all track sections, calculate the one which is the nearest from the ship (by calculating ship/section distance). Once you have the nearest section, you calculate the normal vector of that section (easy and could be precalculated before and stored). This is the actual track orientation and the one the ship should have. Even if the ship goes out off the track but continue moving forward) you still get a 3D orientation.

To avoid brutal changes, you can smooth that out using an interpolation method :

Code:

---

var orientation = to calculate...
smoothorientation = Quaternion.Slerp(smoothorientation, orientation, 0.7f); //between 0.0 and 1.0

---

instead of using 4 push forces, you might consider using only one (at center of gravity) and actually rotating the ship by simply applying a torque to the rigid body (so that the ship is always more or less oriented like the track).

Thanks everyone, going to give all your suggestions a try !

Bit of a deception here, I thought those 3D frameworks would provide a smarter approach but that seems to apply only when it's fully featured in regards to realistic physics. I guess that BEPU physics is a little more featured but not sure it outweighs the facilities of Unity ... I might give it a try later though as what seemed to be tough is a bit clearer now -> I'd just have to follow that composition pattern of Unity.

Basically at this point it's a simple copy/paste operation, still I'd like it to be a bit more than that ... still have a few links to read and also look at the AGR2280 and I think I'll get started. (and the TRS format as well since I've never used it yet, just seen that debug path in the experiment)

Bit of progress here !

- I separated concerns of model and controller
- tried that hovering/leveling again from scratch and it seems it's a better route -> leveling is coherent and it is now unaffected by a tunnel whereas previously it was going crazy (@tigrou seems like I'll need your air tip at some point !)
- also hitting walls is coherent as well though it will certainly need a different physic material to behave like the original game
- edit : I do constrain rotations now

The simplest approach works the best !! The feeling is definitely Wipeout-like when the ship raises/lowers its nose, will need a few magic values later.

For BallisticNG code however, I've abandoned for now as it's too early, I'll certainly take higher-level hints from it but at this point I was not feeling that simply fixing the errors will do the job, plus many constants were missing as well.

So a little victory but definitely more positive than the stalling of last days :D

Quick update to let you know what's going on:

- cleaned out the classes and now have separate layers for the walls and the ground -> prepped the thing for easier usage
- got some sort of DIY prototype with hovering, pitching, airbrakes, sections and so on, though wall hitting was not right

But I've just started porting the Ballistic NG code :g Been able to guess the missing constants for now, got the hovering and thrusting, still a lot remains to be done. I'm trying to understand the thing a bit at the same time, I kind of went the same route on my own but it was way less tuned ... I should have some solid physics within a few days, hopefully :D

Go go aybe!

Here is a video of the 1st prototype ! :rock

https://www.youtube.com/watch?v=0hVcILbw4tw

There are still a few issues but the main substance is here, I've been studying the game and tried to mimic its behavior as close as possible.

I've abandoned using code from BallisticNG and AGR2280, problems being that the 1st is incomplete and misses many things, the 2nd while fully available I could hardly find anything to grasp from it (you might disagree). The copy/paste of snippets worked at first but later went problematic, I guess all should be in but I did not feel taking this route :blarg

So what you see above is my DIY approach, different by a couple of aspects, done by a physics newbie not constraining rotations, letting the engine do its job and try to cohabitate with it instead of bending it; over time I got something relatively stable ...

Let me know what you think about the video !

I have a couple of questions for you guys if you can give some hints:

• how to make pitching more reactive when going down the long air-jump ?
• how are on-air periods approached, is it by using a stronger gravity ?
• how to add the user's free pitch and make hovering aware about it ?
• proper airbrakes, is it just torque+slowdown or does horizontal force should be considered too ?
• high-speeds can still make the ship pass through the ground when landing, even with continuous detection

Thanks :D

EDIT: website secured @ http://wxx-rebirth.com/ :p

@aybe :
This is great, lot of hard work so far. Please continue like that...

There still many things to fix until it really feels like the real game but the gates are now open

I take a look at your questions later on, when i will have some time.