Physics [split from network thread]

[stenyak]

are you saying the CPUs are too slow to compute the physic for several cars ?
what about AIs then ? (I heard we have AIs but I don't know how they work :lol: :oops: )

Well, i don't know what's the CPU usage for physics in vDrift (check with a profiler); but i do know of cases where physics is too cpu-hungry.
For example, if you know GPL (Grand Prix Legends, not the license)... the first runnable version took 30 minutes to run a single second of physics. Once it was optimized to run realtime, it was decided to use faked AI physics.
It's just an exageration, but keep in mind it may happen in some way. Take a profiler and do some checks. Remember that we're not talking about simply computing several cars physics, but about computing several cars physics of the last couple tenths of second (due to lag).

Maybe current Vamos physics are simple/optimized enough to run all of that with no problems, i don't know (it probably is), but i can tell that my un-optimized physics in Motorsport do not allow more than 6 cars at once on screen, and most of the problem is physics.
So just keep that in mind; do not assume things before coding all the multiplayer thing

if you have your client have updated positions/speeds whenever the server wants, you may easily end up losing control of the car because you're suddenly in a 90º drift, while you expected to be gripping nicely through the corner apex

I don't see the point of receiving anything from the server for it's own car (except in case of a collision of course)

I meant the other cars (of course you have your own data already).
If you only send car chassis data, it may look very weird during the race, and most importantly during replays. RBR (Richard Burns Rally) had a bug in its first release, the front wheels didn't rotate in replays, and it was very noticeable.

If you want to save some bandwidth, the wheels positions (not rotations) could be "guessed" running some simple physics, like a ray-mesh collision detection, if you know the suspension travel. Most of the times it should look right (except on car jumps, which i think you only have at the nordschleife ).

[thelusiv]

Maybe current Vamos physics are simple/optimized enough to run all of that with no problems, i don't know (it probably is), but i can tell that my un-optimized physics in Motorsport do not allow more than 6 cars at once on screen, and most of the problem is physics.

stenyak, do you work on the Motorsport project? If so, nice to have you around, Motorsport looks like a promising sim edit: I see from the link in your last post that you are the developer for Motorsport. Sorry for not realizing this before, I don't really follow RSCnet.org much.

Vamos could definitely stand some optimization. Set up a race with 3 AI players and you'll see what I mean. I'm not sure where to start with optimization but it will probably be a little further down the road before we start doing any heavy work on our simulation engine.

On that note, it would be really cool to combine the code in Vamos with ODE and do things like fully simulated suspension, and full collision detection between everything. I'm doing some 3D projects for school this semester and ODE is one of the libraries I plan to learn in the process. I think it would solve a lot of our collision issues and probably speed up simulation somewhat. I guess we'll see...

[stenyak]

Yes, i'm the main developer of Motorsport. The url is www.motorsport-sim.org , but right now the domain isn't renewed yet (wait 2 days or so, until the DNSs are updated).

Nigo pointed me to some of these multiplayer discussions. I haven't coded much really, but i do have some ideas, and have talked to several commercial car sim developers, so i can definitely offer some suggestions. I'll prolly let you do the coding though


Regarding ODE... it's a good library, but do not think that you can use it for replacing everything. Suspension is relatively easy to set up with ODE, but the performance is a nightmare. It's the main reason Motorsport runs so slow the more cars there are. Using a simpler, game-ish, up-down axis suspension is way faster than a proper double wishbone one. In this case, IK is the way to go.
For tire modelling, what can i say... ODE is a rigid body sim, and tires are not rigid. You're on your own for that piece of code too.

As you can see, ODE is not great for simulating a car. But it's probably the best you've got if you don't want to start from scratch. You go from nothing, to proper generic physics, in just a couple of minutes. It can always be used for trackside objects and fallen car parts.

Anyway, keep in mind that ODE collision detection code can be reused. They have had some cool additions recently, like a new trimesh collider code ("gimpact", instead of the old "opcode" one).

Sorry for the offtopic, i guess this is not multiplayer anymore O: -)

[thelusiv]

Well it's nice to see developers of other sims stopping by our forums to chat. By the way, thanks for the MOSP-1, aka VDrift GT. Did you model it yourself?

It's interesting to hear these things about ODE, performance was one thing I was concerned about, and it does seem that a pure ODE-based car physics simulation might be inneficient. However we're not looking to replace all of Vamos with ODE, we understand that ODE doesn't provide many of the things we need anyway (such as tire modelling, as you pointed out).

What I wonder is if we just used ODE for things that VDrift/Vamos doesn't really do all that well. In particular, our collision detection and response code needs lots of improvement. Suspension is another area that needs improvement. Also at this point, objects on the track are not movable, so ODE would make sense for that too.

On the topic of suspension, I see screenshots of Motorsport using double-wishbone suspension and I'm interested. We currently have a simple suspension system that does up-down movement on a curve defined by setting a "hinge" point. I have some issues with this system, mostly that it's not very easy to figure out how to make cars using that system act like cars in real life. With the current system, even if the suspension "feels right", the handling is still qutie unpredictable when one attempts difficult maneuvers like drifting. Tuning the suspesion can be a nightmare of moving hinge points around, and testing repeatedly. I have yet to find a very good way to set the hinge points on a given car and know it will work well.

So what I'm interested in trying is setting VDrift up to use a hybrid Vamos/ODE system for physics. The other option is to just write optimized versions of the things we need ODE to do ourselves, which would probably be better in the long run...what do you think? Would a hybrid system perform fairly well, or should we forget it and just write it all ourselves?

So yeah we're way offtopic, but oh well...back on multiplayer, it would suck a lot less if our system had car-car collisions. :lol:

[reece146]

We currently have a simple suspension system that does up-down movement on a curve defined by setting a "hinge" point. I have some issues with this system, mostly that it's not very easy to figure out how to make cars using that system act like cars in real life. With the current system, even if the suspension "feels right", the handling is still qutie unpredictable when one attempts difficult maneuvers like drifting. Tuning the suspesion can be a nightmare of moving hinge points around, and testing repeatedly. I have yet to find a very good way to set the hinge points on a given car and know it will work well.

The only way to make the VAMOS code emulate real life roll centers and such would be to have a dynamic hinge point. Even then it would be a PITA to develop a suspension for and it wouldn't be 100% accurate. It would be a kludge.

So what I'm interested in trying is setting VDrift up to use a hybrid Vamos/ODE system for physics. The other option is to just write optimized versions of the things we need ODE to do ourselves, which would probably be better in the long run...what do you think? Would a hybrid system perform fairly well, or should we forget it and just write it all ourselves?

I have a copy of Milliken and Milliken. I can forward the pertinent geometry related chapters to anyone that is interested in doing the coding. IIRC there are about 6 unique/different suspension models that would need to be coded.

What will the affects be on performance?

[stenyak]

Like i said in other thread at rscnet.org, i suggest using IK for suspensions. Much faster and accurate than a constraint based suspension like ODE. If only i knew how to code it.. :roll:

BTW, i didn't model the Mosp1, it was Habalux. All credits go to him.

[joevenzon]

I think thelusiv said this already, but just to reiterate, the vamos physics code (which is the car simulation stuff) is very fast and can run many cars at fast rates. I don't have exact numbers, but it should be fast enough for a dozen or so cars. It's currently iterating at 250 fps, which is way faster than we need, and could even be halved to increase performance if necessary. The really SLOW stuff at the moment, which causes multiple cars to be so slow, is the collision detection code. I end up casting a bunch of rays around (more than necessary) and use my own AABB spatial tree collider algorithm. Although my collider code is much faster than a naive implementation without any spatial sorting, it is not as fast as the ray to trimesh collision in ODE. In addition, ODE is more efficient and accurate when colliding a box with a trimesh (which I fake by casting a bunch of rays).

By the way, it looks to me like live for speed uses IK for the suspension geometry. I think reece146's suggestion is probably the best (coding up the suspension physics from his sources) if we want to fancy up the suspension code.

[reece146]

I just had a brain fart (aneurism?)... Wrenching all day will do that.

In Vamos is the hinge point supposed to be defining the suspension geometry as in the physical "rods" or is it supposed to be the instant centers?

If we were modelling the instant centers I'd suggest that the Vamos method would be more than adequate for now.

[thelusiv]

Here's how I understand the suspension hinges. The suspension does not follow a straight up-and-down path. Instead it follows a curve. This curve is defined by the hinge point indirectly. It's as if the wheel itself was attached by a straight rod of some kind from the hinge point to the center of the wheel, and the hinge allows up-down movement. Take for example the front wheels, which usually have a hinge point behind them. So if the wheel moves up, since its attached to the hinge behind it, it's also going to move towards the back of the car a little along the curve. The big difficulty in this is predicting how the car will react under this movement. I've found that the hinge points can be manipulated to induce understeer or oversteer, but it's impossible to predict or measure...I must rely on testing or the "butt dyno" which of course is really hard since my butt isn't even really in the car...

[reece146]

Here's how I understand the suspension hinges. The suspension does not follow a straight up-and-down path. Instead it follows a curve. This curve is defined by the hinge point indirectly. It's as if the wheel itself was attached by a straight rod of some kind from the hinge point to the center of the wheel, and the hinge allows up-down movement. Take for example the front wheels, which usually have a hinge point behind them. So if the wheel moves up, since its attached to the hinge behind it, it's also going to move towards the back of the car a little along the curve. The big difficulty in this is predicting how the car will react under this movement. I've found that the hinge points can be manipulated to induce understeer or oversteer, but it's impossible to predict or measure...I must rely on testing or the "butt dyno" which of course is really hard since my butt isn't even really in the car...

If it is as you said above, in Vamos we are truly modelling the the instant center of the suspension and through implication the roll center.

Given that, VDrift has enough in its model to have a "pretty damn good" suspension model without incorporating other stuff. The only caveat I can think of is the dynamic modelling and the showing of the suspension movement in an open wheel car is not there since we aren't modelling that.

I'll put together a primer on ICs, RCs and roll axis for the wiki.

[thelusiv]

Reece, if you want more info on how VDrift's suspension works, take a look at the Vamos docs: http://vamos.sourceforge.net/vamos-docs/Cars.html

I know they're kinda sparse. We should really start doing some more in-depth Vamos documentation on our wiki.

[stenyak]

I think some more attention should be paid to the suspension. If tires account for 80% of the realism, suspension accounts for 19%.

Judging by the description at vamos docs, it looks like wheels simply describe a circle around a given point. I don't know if vamos models changes in temperatures and wear, but if you intend vdrift to be realistic, you can't continue using a circle-suspension model forever. Of course right now the tire model is probably not exactly very good, so it's better to improve the 80% than the 19%, but keep all of this in mind nonetheless.

My 2eurocents.

[joevenzon]

The tire model is pretty good -- we're using pacejka's equation and some fancy(er) long/lat force combination -- but the tire constants are not.

Also, about the hinges, here are some excerpts from old e-mails from Sam Varner (the Vamos author) answering some questions I had:

The suspension hinge allows an approximation of suspension
geometries that reduce squat (under acceleration) and dive (under
braking). The usual configuration puts the rear hinge in front of and
higher than the rear axle. The driving force then tends to push the
rear of the car up. Imagine the wheels trying to drive under the
chassis. Braking pulls the rear down. Also, braking torque pulls the
rear down in this configuration.

I avoided trying to simulate multilink suspensions directly. I figured
that the hinge (and roll height) approximated most of the useful
multilink geometries. One effect that's missing is the change in camber
with suspension travel.

In response to my question of how to use measured information about a car's suspension (such as suspension type) to generate a hinge point:

The problem is that just knowing it's a strut or a wishbone doesn't tell
you enough about the geometry. What matters is how the wheel is
constrained to move as it's displaced. You'd need to know the positions
of the joints and how those joints constrain the motion of the wheel in
order to determine how the car will behave. Unfortunately, as it
stands, the code could not use that information even if you had it. I
know that's bad news if you're trying to simulate a particular car.

The hinged suspension in the code doesn't directly correspond to a real
suspension type, but it does (as far as I know) reproduce the important
performance characteristics of real suspensions--anti-squat and
anti-dive. Depending on their precise geometries, two different
multi-link (for instance) suspensions may have different
characteristics, and some multi-link suspension may have the same
characteristics as some double wishbone. There's not a direct
correspondence between suspension type and hinge position.

[Nigo]

It's currently iterating at 250 fps, which is way faster than we need

I wouldn't say that, and it certainly can't be halfed. I don't know as much as you about the physical engine, but I know the principles and if the frequency is too low, we lose realism no matter how good the engine is.
in Motorsport I've read we can change the frequency while driving. If you think the frequency can be lowered, it would be a good idea to implement something like that and try on the fly

you should open a new topic, this has nothing to do with networking :lol:

[thelusiv]

It's currently iterating at 250 fps, which is way faster than we need

I wouldn't say that, and it certainly can't be halfed. I don't know as much as you about the physical engine, but I know the principles and if the frequency is too low, we lose realism no matter how good the engine is.

Well try it out for yourself. Last night I changed it to 100 fps. I can't tell a big difference, and AI games are a bit faster. However we really do need to optimize that collision code, either with ODE or something else, as Joe says that's definitely more the bottleneck than the rate at which the physics are updated.