I found an interesting truck simulator called rigs of rods, in which the chassis for the trucks flex in what looks like a realistic (with some tweeks perhaps), manner, and I was wondering if the following approach might be of some help, seeing as lots of people want karts and they're dependant on decent chassis flex.

here are the source urls:

post by pricorde:
http://www.ogre3d.org/phpBB2/v ... 50b33838bd1fa145b88f62854

rigs of rods:
http://rigsofrods.blogspot.com/

"Yes, a spring array is a good way to model a vehicle, but the springs must be very, very strong so the integrator must run on very small time steps to avoid instabilities. This version uses a simple Euler integrator, with 100 integration steps per frame, and a capping at 20fps (below 20fps, the simulation is not realtime), so the integration steps are never below 1/2000th second (with several hundred nodes to compute)!!! And even with that, the chassis is not as rigid as I would want.
I hope that with a Runge Kutta intergrator it will require less steps per second.
The good news is that the model is extremely simple : I simulate monodimensional beams connected by ball-joint. The consequence is that I do not have to compute anything that has to do with angles (rotational speeds and moments, ...). I just compute nodes movements, and nodes are dimension-less objects. Also I do not compute anything central (center of inertia) and in fact if you split the truck in two, the two parts move independentely and realistically (I have seen impressive wheels run-offs)...
Yet the simulation is realistic : all the rigid body "laws" emerge from the interaction of nodes. You observe that the truck has a center of inertia, moments of intertia, you name it, but it is never explicitely computed.
Since everything is ball-joint, you must triangulate everything, and you can always obtain other joints by contruction (many extra triangulation beams are masked in trucks).

The Beam engine is not opensource, the main reason are that it is a horrible programming mess, and it does not uses a good integrator yet.

It is not vehicule engineering research : it would be too resource consuming to really simulate chassis parts. I intend to add some game logic someday.
I chosed trucks because everybody does cars The initial objective was to do a "truck trial" game :
http://www.europatruck-trial.c ... rie/bildergallerie_l1.php
with an extremely precise terrain map (~10cm resolution) that deforms under the wheels! But I am afraid the polygon count would be tremendeous...
Meshes are deformed manually. Skeletal would be better since it would allow more complex meshes, but it has the wrong topology for a truck (tree vs mesh)."

Interesting system.
I enjoyed the google video on the Rigs of Rods website!
So many possibilities!

I had a go on this a while ago and enjoyed myself. I got bad fps but I could see the that the physics where very good.

Looks like you got Scawen intrested anyway!

Andy.

Yeaa, Scawen getting excited

But this game was very heavy when I tried it, must be all the calculations.

Armadillo run meets LFS ..

Man, im gonna try rigs of roads right away ...

edit: getting 50fps (actually almost 60) in 1280x1024 with AA level set to 2 and best possible AF. Im running an amd64 3200+ with 1gb of ram with a x800.

I dont really understand why it is necessary to compute anything more than 1000 times a second because of the speed of the internal timer - there has to be a better way. Locked speed physics are certainly easier to work with in a computer game when dealing with physics, but why lock it over 1000fps?

Personally I try to do all my physics with delta timers and software driven interupts for division and multiplication where absolutely necessary. Which is much faster in runtime as physics only need calculating the once every frame update - rather than several thousand.

Thats an interesting read for sure. I think chassis flex would transform LFS, at the moment the body of the car is ridged so you lose a bit of realism in that.
Good to see Scawen excited

Another physics patch on its way in a few months? Yes, please.

Quote from felplacerad :

edit: getting 50fps (actually almost 60) in 1280x1024 with AA level set to 2 and best possible AF. Im running an amd64 3200+ with 1gb of ram with a x800.

Yeah, but thats a uber system you got there Compared to LFS my FPS was lowish.

Quote from axus :

Another physics patch on its way in a few months? Yes, please.

Im gonna pray for that!

Nice system, very nice.

Scawen does a thumbs up for chassis flex... Did someone just say karts?

(I don't necessarily want karts, I'm just counting one thing and another together.)

Vain

I very much doubt the system used in RoR is usable in LFS at all, alteast at that amount of detail. If you were to make these calculations for the whole car body, then the already very CPU dependent LFS would break down totally. I don't think calculating hundreds of springs together with the other physics is a good idea.

The best way is IMO "just" to figure out how to bend the front and rear suspension in correlation to eachother in a realistic way and use a simple model that produces reasonable results. Maybe precalculate the bending behaviour based on the car mesh, but doing all these things in realtime is overkill for the actual change in car behaviour.

IMHO, Mr. Roberts should rather use the time to figure out a collision detection that doesn't send you into space (), instead of trying to create the most accurate bending simulation ever (only if he lets us modify the supporting struts, so we can experiment with the best flexing behaviour - kinda like BridgeBuilder in LFS j/k).

I only want chassis flex if Scawen is able to do it in a way that we don't need a 3 ghz PC just to run LFS with one car.

I think to have chassis flex that complicated, the devs would have to sit down and design proper chassis first for all cars. A simple value for "not much flex" or "lots of flex" would probably be a start.

Quote from Becky Rose :

I dont really understand why it is necessary to compute anything more than 1000 times a second because of the speed of the internal timer - there has to be a better way.

Very stiff springs have a very fast oscillation frequency, I guess thats the reason for him having to use so many calculations per second.
Nontheless a very nice and interesting program

Just to confirm, this is not the way forward for LFS at the moment! I was just saying how I was impressed by the way those trucks move, it's the first time I've seen such a nice flexy body system and it's great how it naturally supports things like towing a vehicle and carrying another vehicle. It looks good for a game of the future when you can do that much calculation for several vehicles at once, at even higher frequency.

Quote from ORION :

Very stiff springs have a very fast oscillation frequency, I guess thats the reason for him having to use so many calculations per second.
Nontheless a very nice and interesting program

Yes that is true, but just for interest, the way it comes straight to my mind is stability. With too low an update frequency, the nodes will very soon spasm out of control. It's always happened when I've made wobbly box things in the past and often happens when developing physics systems. One example in LFS is the spring above the wheel which is supported by a tyre below. The wheel is light compared with those two large spring effects and can easily cause instability. That is the reason for LFS's high update rate of 2000 Hz in the sub-updates, which avoids the cars jumping up and down all on their own due to jumping wheels! You saw in the google video, at one point, in a crash when some vertices went a bit wrong.

What happens is you have some very stiff springs for the chassis members, supporting a node which let's say is 10 kg. The physics engine finds out in one update that the springs are stretched by 5 cm. Now the super string spring applies a force of [A LOT] to that 10 kg mass. So in the next update you find that 10 kg mass has gone maybe 10 metres away or whatever, when really it should only have moved a mm or so.

The update time steps must be small enough so that large force acting on the small mass at the node, doesn't push the node too far away.

Scawen, what about some kind of compromise between FEA and rigid body simulation?

Quote from Scawen :

... The physics engine finds out in one update that the springs are stretched by 5 cm. Now the super string spring applies a force of [A LOT] to that 10 kg mass.

but... the total thrust to that 10kg mass is normal (= not so small it is irrelevant to the calculations nor so big it sends the engine to spasms) because the interval between updates is very small (.5ms you said?)

yeah , the timer res must be high enough so that there are never very large 'fake' thrusts exerted anywhere . that's a doozie.

(for heavens sake, i am way waaay behind you guys in physics sims... only thing i did was some sort of ball bounce/rotation non-realtime simulation with my programmable calculator)

Well I was just illustrating what happens, as some people may not have seen physics systems in development, going mental. It's something I find quite funny as you are working on something intended to be realistic, and the most crazy things are happening.

But ok instead of [A LOT] let's make up some figures to demonstrate.

Let's say a beam for a truck when loaded with 1000 kg (approx 10000 Newtons) stretches 5 mm. Now let's say it's currently deflected by 1 mm and this is acting on a 10 kg node. The 10 kg node will experience a force of 2000 Newtons, and so accelerate at 200 m/s^2. Let's say the update rate is 100 Hz. So in the 0.01 second time step, the node will accelerate to 2 m/s. Its average speed over that time is 1 m/s, so it moves 0.01 m (1 cm).

Now for the next physics update. The node is 9 mm the other way, so now it will experience a force of 18000 Newtons! It will accelerate by about 18 m/s... and go much too far the other way! And now we have a spasming truck.

That's a simple analysis but I am just trying to demonstrate why the update rates must be in the thousands, when you are trying to simulate something very stiff. Soft and squidgy things can run at really low update rates.

That is not to say LFS can or cannot do chassis flex by some means in future, it's purely answering the "why are the update rates so high in the truck simulation" question.

I think I see why I dont get it, I work so completely differently. As a programmer I think well wide of the box and do my own thing. It is after all just a hobby for me.

Generaly speaking if I can fake something by multiplying it by the delta (the 100Hz value) rather than repeat it x times for every Hz then i'm much happier. 1 calculation fully timescaled.

The only [common] tasks you cannot do by multiplying the delta is a multiplication or a division - these are the things which need to be done on an interupt.

One neet dirty cut corner for a lot of physics I use, such as something stretching under a loaded weight as in your example, is to measure the loading on a scale of 0 to 90, the position on the scale is calculated by adding to the current position the (current loading minus the torsion) multiplied by the delta. Then adjust the node by the sin of said scale multiplied by its maximum flexibility.

A total cheat, but the same thing in just a few calculations. Using a pre-rendered trig table for the sine calculation of course...

At the end of the day a computer game can never be real - and using real physics always misses something, such as the tarmac coarseness factored by the heat expansion of the tarmac effecting the contact patch of a tyre...... You can never be truly realistic, so using real maths is a sure way to make sure you are not perfect. So I cheat and fake the real thing by "look and feel" ...

That's why I said "there has to be a better way...". Of course "better" is a matter of opinion. I think I already know where you stand on that because i've seen LFS when it doesnt get it right which is usually only in crashes as the time slice isn't short enough to process them accurately, so we get those massive crashes.

Becky, there is one nasty problem with the way you suggest, namely that the physics behaviour may be linked to the frame rate. Suppose the frame rate stays at, say 100, but for whatever reason it drops for a second or so to below 10. This can really throw your calculations off if you're doing just one update per frame, even if you are not handling stiff systems such as what Scawen mentions, if nothing else the collisions is what will get you.

So one solution wouldbe to find a way to do very very fast calculations so the dt goes even lower huh...

why does nyquist theorem come to mind? hm...

ah! idea! If the frequency of oscilattion of the spring is of the same order of magnitude (or, worse!, higher) than the frequency of the physics engine you WILL have issues sooner or later. "Sampling" comes to mined as well... 'cause you are essentialy sampling the motion, as it happens.

Only way would be to somehow suppress the high-freq oscilations as they would be supressed in a piece of metal anyway. there are many things to absorb high-freq waves.

i will think about it...

Quote from Becky Rose :

A total cheat, but the same thing in just a few calculations. Using a pre-rendered trig table for the sine calculation of course...

Do you save any clockticks using look-up tables instead of doing a float trig op? I thought modern processors are fast enough with float operations.

Think of it like sound. The higher the frequency of the sound you want to record the higher the recording frequency you have to use to capture the sound correctly. If you do not use a high enough frequency you will not record the sound. The same happens with springs etc.

If you tried to sample a sine wave with a frequency of 20Hz you need a sample rate far higher than 20Hz to record the shape of the wave. If you use a sample rate that is too low you get incorrect results, for example use a 20Hz sample rate and you might not record anything if you sample points occur when on the 0 line. If you are lucky enough to get the sample right you will get a triangle wave, again wrong.

While cheats sort of work most of the time there you will always get very strange results at times. Some things just need to be done the long way.