Wipeout games PHYSICS
polycounter lvl 11
Hello all,
I would like to know more about how physics in wipeout games works. I'm all up to technical reading, examples, explanations, articles. I think I absorbed a lot of google knowledge on this topic but there might be some that I missed so feel free to post link here.
thank you dear P-counters
I would like to know more about how physics in wipeout games works. I'm all up to technical reading, examples, explanations, articles. I think I absorbed a lot of google knowledge on this topic but there might be some that I missed so feel free to post link here.
thank you dear P-counters
Replies
My guess would be that they did approach the first games very simply and just tweaked things until it felt fun. If you wanted to build something like that in Unity for example there would be several things you could do. Maybe clarify what and how you want to develop things or what you need it for.
I was thinking if one raycast is enough to determine corect craft orientation... Looks like there is some voodo math behind it.
Yes I'm Unity based. I would like to archieve simmilar results I already have couple of solutions but none working as I would like so I'm eager to know more about this
Physics bro!
Raycasting, from a single point around the nose of the ship, VERY high frequency (minimum 50-60Hz, better off with a single cast going for 100 if you can).
Smooth Sphere Collisions is an option in Unity that smoothes off edges with your meshes. This is the physics equivalent of soft edges (normally physics defaults to what's basically hard edges). Think of a good circle, then a low-poly circle. That's what you gain, and it's pretty cheap.
Align the vehicle to the terrain. When the ray hits the ground, detect the normal at that point. Align the vehicle's 'up' to the normal.
Never, EVER, use the physics above as the entire solution for visuals and what not. Unless you're a pro working on a simulation engine running physics cycles at hundreds of hertz, don't even bother.
Instead, use a spring with limits attached to an invisible 'chassis'. The chassis does the raycasting and ACTUAL physics stuff. The BODY is spring onto is, and with a few simple tweaks to spring and damper rates, you can have vehicles that perform exactly the same, but can look vastly different (sliding wildly,but still in control, leaning into corners, but no real physics change).
This is FANTASTIC for balance, because everyone then thinks you've balanced many cars. Or, better yet, the cars are all equal but there's raging debate on *** should be nerfed, *** needs a buff, etc etc etc.
For JUMPS, set a cube up where you want the vehicles to be airborne. Trigger upon entry, kill the ray, and go to 'flight physics'. Animate or code the vehicle to wobble around, do a flip, etc. Then, when it get near the ground, turn the ray-casting back on and resume as normal.
Acceleration and top speed is something you'll have to balance yourself. Consider how much time is going to be lost if a player messes up and has to catch up from 0km/h while the other guy approaches top speed. Don't be afraid to slow EVERYTHING down.
The spring, damper, differential, drive and other settings for the ray/s (I'm a fan of using four for vehicles on terrain, it makes them look like they're running over stuff better) are all going to be a closely guarded secret. Keep in mind that no mesh is perfectly smooth, no collision is Hollywood perfect and nothing can be taken for granted.
Physics are still a bit of a dark art. Black magic, etc. You will never find a more wretched hive of scum and villainy than when you look through the physics of a racing game. Up to a point, it pays to be clean, but ONLY when you know what you're doing and have experience to draw upon, either your own or somebody with a LOT of skill.
For fantasy vehicles, like wipeout or slipstream, you need to have someone who can design the physics well, and communicate very well with everyone who touches that code.
A good basis is the GTR Engineers handbook, if you can find it. It came out with GTR/2, a simulation racing game, but the physics principles stay the same IF you use a similar setup. For the most part a single point system (wipeout, my demo pic, etc) won't respond the same way, but it'll get you thinking about springs and dampers, which is what you really want to do.
For vehicles with 2 or even 4 points, the advantages in physics are massive. The vehicle looks like it's on a road better over uneven surfaces (bumps affect each wheel like they should), but it's a whole world of issues when you're sorting out physics. Steering response changes vastly at different speeds and under different loads (braking accel, constant speed, etc). Same goes for basically every component.
Yes, shameless plug, but I got a PhysX driven racing game with hundreds of particles to render damn fast.
I'm trying to aproach this by separating each raycast to it's own variable. What remains to solve is evaluation function that will output vector or separate forces for each point.
Next major issue is banking in turns. Due nature of digh speeds and no contact with road it is very hard to tune so I think I will introduce some cheating to help physic with this a little. I'm not after book but more fun and pleasant result which response to user as he expects.
Nice aproach with that joint. Maybe I will incorporate this in "jump physics".
Looks like you work with Unity too. Is ehere some option to force FixedUpdate in certain Hz? except "Solver Iteration Count" raise to higher number?
http://unity3d.com/support/documentation/Components/class-TimeManager.html
Banking is fairly easy for this stuff to handle. Just make sure if there's a seam that the ray knows to go with the first road piece it hits, because that will be 'on top', and therefore what the player will understand as correct.
With flipping due to walls and other stuff, make sure the wall colliders form a good, hard edge with the ground, and ideally they should not be joined by any mesh (though verts can be in the same spot). Physics can be touchy sometimes, and this gives it a bit of help.
Another thing with walls is that with invisible colliders you can angle them in a bit, so if the vehicle hits the wall it has a bit of downward force because of the collision.
While you're in Unity, ANGULAR DRAG is your friend.
I'm using "smooth sphere collisions ON" on my invisible colliders to help along. They are separated from track collision mesh for performance purposes and sliced for occlusion culling.
I'm also thinking of doing raycasts to left and right of craft to apply force prior collision with wall in proximity of them, this should help a little to eliminate catapult effect and dampen impact forces to minimum and also I think it should help with steering.
Today I plan to incorporate banking and more complex force impulses that are tied to this beaviors.
My current code is i think 45% finished. Still I need some logic to determine when and where to apply force in case scenarios when hover raycasts fails or I'm getting airborne. I want to use same code for AI handling except that AI will use fake user input driwen trough waypoints.
Do you have some advices about AI navigation in race games? url or something realy usefull that I might not read to date.
I found that you can override solver per rigidbody trough scripting [JS] this way:
It isn't. You can also manually control the orientation of the craft; i.e point the nose specifically upwards or downwards to subtely alter your flight mechanics.
For starters, waypoints should do for now. There are ways to randomize them so they look less repetitive AND more randomly natural, but for now that kind of thing is still under wraps.
All I can say is think carefully about what you want the AI to do. Strategy can bite you; I designed almost all of the levels, and I know things. Strategies, lines, mechanics, things that players have yet to discover. If you use ALL your knowledge, then players will at first be beaten sorely, then they will see, and suddenly your cavernous skill ceiling goes down the drain. Strategy can be useful, however. If it's easy enough to understand, it can make up for some (slightly) iffy AI driving skills.
Behavior will be always different cause there will be collisions and they will be no clones with same characteristics so I'm not afraid. I used same waypoints in my previous developement and it was OK. I have some ideas in reserve how to improve in this but for now my main concern is and remain to get perfectly enjoyable physic and handling. Cause it is all based on movement this is crucial part to concentrate on.
Any other ideas how to stabilize or guide ship over track [by this I mean adding to player inputs in a way that "predicts" player desire of where he want to go] is welcome.
The spline paths seldom changed during development; how the AI adjusted to try to stick to them did as the physics of the vehicle changed moderately frequently. You can develop said physics and AI side-by-side if you have splines that follow your 'ideal' routes around the track with reasonable results. I'd still largely have your physics resolved before beginning development of AI though. In our case, we actually effectively simulated the button presses a player might make adjusting to tend towards the ideal or desired path, so non-significant physics changes did not usually have a profound effect on the AI.
Spline solution is impractical for me... too complicated to handle. More complex things tend to produce more errors
Banking.
Work out the physics, and tilt the track so that applies about half the force required to keep the car on the inside line.
This is a good start:
http://en.wikipedia.org/wiki/Banked_turn
Just remember that the idea is to keep vehicles at the correct distance to each other (in touring cars it's 1cm away, in open wheelers, it's 1m, in Slipstream it's 2m, in wipeout it would probably be more because of the 600km/h speeds), just as much as it is to help them through the corner. And the banking isn't going to be the only thing turning the car (players will still hold the turn button, and you can't have it be too effective).
If splines are too complex to handle you probably shouldn't be programming any AI.
From a level design perspective, given a track with thirty corners, I know I'd rather be placing thirty three-point splines than thirty twenty-point waypoint sections. Iterating using waypoints like that is ridiculously impractical - if one of my corners has issues, I can adjust it by fiddling a single point and the cause is usually obvious and the resolution easy. If one of yours has issues, you will end up fiddling with six or seven, and the cause is not going to be as obvious without actually hard-debugging your navigation.
That example uses all almost right angled corners. Start using long, subtely angled corners with banking and it will fall apart instantly. It also uses a "polyline". A polyline built using a lot of waypoints might as well be replaced with a spline.
400, 600, 800, a billion km/h. Wipeout, Podracer, etc. That general area or ridiculously fast.
Also if the thing is 15 meters long and you would pass about a hundred of them in a second, then it's around 600km/h.
My external editor of choice is 3ds max so i can distribude and tweak waypoints prety easy trough distribute points on path tool... I don't see this as some kind of problem.. it's designer choice I think.. I have previous experience with AI + waypoints + colision avoidance which was not bad at all
That's fine if you build your entire level geometry within a 3d editor of course, but it means you have to re-export that stuff every time you need to make subtle changes, which is still a bitch. Our pipeline revolved around an editor and sets of modular track pieces; if you wanted to change anything you moved one or more of the points, then just hit 'play'.
https://www.youtube.com/watch?v=WPj1zz-t_yY
This is an old build but physics are actual :P
It will help me a lot even if I haven't understand everything ^^'
THANK YOU !
Getting the hovering right is a complete pain and I can tell you this from experience, it takes a lot of messing about to get right so here's my hover force calculation straight from AGR2280's Github (with different variable names just for simplicity) This calculation is also coupled with custom gravity to help keep everything stable, so let me just cover the ship gravity as well.
So if you're looking to get ships hovering like Wipeout then you're going to need to control gravity yourself, the reason for this is that the ships have less gravity applied to them when they are hovering above the track then they do when they are flying. You can use the previously mentioned raycasts to determine if the ship is flying or not and then you can linearly interpolate between two different gravity forces, if the ship isn't flying then you can apply additional force on top of the grounded gravity to help dampen the hovering some more (this force is the distance from the ground).
If you want the craft to swing out then you can also apply a force at the back of the ship which is dependent of the steer/airbrake force.
Banking
There's loads of calculations and tweaks needed to get this perfect, it's quite overwhelming to explain it all and it's taken short of a year to get it perfect so check out the code on this page to see what exactly I'm doing, this is by far my most messiest script but it's still readable. Sorry for not really explaining this one too much, but it really is just a handful of different things.
First off you want to draw the track shape using a CV curve with the curve degree set to 1. After this set the curve degree to 3 then draw out a spline in the shape of your track (keep this spline flat, don't add any height variation). After this change the menu set to Surface, select the track shape curve then select the track spline then go to Surfaces - Extrude, you should now have your basic track. The reason I said not to add any height variation to the spline is because Maya automatically banks the extrusion. After this use the hull selection tool to add the height and banking to your track, this can take a while if the track is large.
Now convert the track to a polygon two times, seperate the floor from the walls from the first mesh and add them to a new layer called something along the lines of "CollisionMesh", this allows you to later treat the track walls and floor separately (you obviously won't see these meshes because they are for collision only). Now you can do whatever you want with the second mesh, I always make the track shape basic with 90 degree walls for the ship physics to work correctly so what I do here is add details that shouldn't affect the physics.