Just thought I would make a post to comfort the majority of members who might be reading all of this...I have no idea what the hell they are saying either, your not alone people!

Quote :

Do you save any clockticks using look-up tables instead of doing a float trig op?

You save a bucket load. Sin() used to take an age to calculate and now it is fast. A table lookup used to be quite quick to calculate and now it is blindingly supremely fast... So Sin() is still slow, just not as slow as it was

Quote :

While cheats sort of work most of the time there you will always get very strange results at times.

This is true, but I also think you get strange results doing it the long way too. In fairness to LFS the update frequency occurs at such a rate that this only happens during extreme situations such as a crash, but the cars can still behave very strangely.

Quote :

Suppose the frame rate stays at, say 100, but for whatever reason it drops for a second or so to below 10

10fps is quite an extreme performance level anyway, first off I would say that doing single calculations meens you are not creating such heavy CPU loading in the first instance and so are less likely to drop to 10fps and more likely to maintain a very steady framerate than if you are using brute forced physics.

However peeks and troughs do happen. In my experience I have found getting round this is easy, firstly the delta adjusts straight away anyway, the very next frame is worked out using the delta from the last - but also I these days add a little dampening by working the delta out with the average fps over the last 5 frames and this smooths out most bumps in the road caused by nasty background tasks.

If performs level fluctuations are extreme, such as 100fps to 10fps and back again, I dont think it matters if you are doing the calculations once or a million times a second - it isnt going to be playable anyway

Quote from Becky Rose :

This is true, but I also think you get strange results doing it the long way too. In fairness to LFS the update frequency occurs at such a rate that this only happens during extreme situations such as a crash, but the cars can still behave very strangely.

True, but the strange crash effect happen far less now. But if you do it the right way the more you can ramp up the calculation frequency the less the strange effects will become. Something that is not as true for the "cheat" route.

Rigs of Rods uses a huge amount of springs per truck. You will probably find that only a few rods would be required around the suspension mountings in the LFS cars to get the basics of chasis flex working well enough.

We can already see that each car fully built as per the ROR trucks would add a huge amount of calculations to the core engine of LFS.

Its all for future work anyway, probably more S3 and by then we will all be running dual core at least. More than enough power for the full model

Quote from Woz :

Its all for future work anyway, probably more S3 and by then we will all be running dual core at least. More than enough power for the full model

You meant quantum processors, didn't you?

Quote from Becky Rose :

10fps is quite an extreme performance level anyway, first off I would say that doing single calculations meens you are not creating such heavy CPU loading in the first instance and so are less likely to drop to 10fps and more likely to maintain a very steady framerate than if you are using brute forced physics.

However peeks and troughs do happen. In my experience I have found getting round this is easy, firstly the delta adjusts straight away anyway, the very next frame is worked out using the delta from the last - but also I these days add a little dampening by working the delta out with the average fps over the last 5 frames and this smooths out most bumps in the road caused by nasty background tasks.

If performs level fluctuations are extreme, such as 100fps to 10fps and back again, I dont think it matters if you are doing the calculations once or a million times a second - it isnt going to be playable anyway

Well, you are right with the last point, but this IS Windows we are talking about . It could be a silly thing such as the automatic updates going off, or any other services that can momentarily stutter your game (and most games are susceptible to such stutter). The point isn't so much in the simulation killing itself, the point is that you aren't simulating the same thing anymore if the framerate is different. There is always an error associated with discretization schemes, and the error is always larger the longer the timestep. In an online racing game, a person running at 30fps will experience slightly different physics than the person running at 100fps, which will give either of the two an unfair advantage (depending on how the errors affect the physics), and this is without taking into account the fact that the person with 100fps will have an advantage anyway. But, as Scawen says, that is really not the most important reason why high frequency of updates is necessary in any case. It is the stiffness in a system that leads to high frequencies, which themselves require short timesteps in order to not blow up. There are ways to run stiff systems with timesteps that are (much) longer than what would normally be required, but this is really a whole new can of worms altogether. Not to mention, if there is a bug in the physics code (there always is one ) you can never be sure if it's because FPS is fluctuating wildly or something else is going on.

In my opinion, the best way to go about doing things is keeping the timestep of physics updates absolutely constant, and in each cycle running enough iterations of the physics code to catch up with the real time clock, rendering the result, lather, rinse, repeat.

I say keep the physics engine running as a different thread than the rendering engine.

That way on hyperthreading cpus there will be some gain. on SMP, even more so

I had a go of your Rigs of Rod last night, it was quite good fun for a bit - once I figured out how to get other trucks anyway. It does need a bit more purpose to it though but i's clear to see that it is early stages.

Now I just need to write something worth playing myself and you and Scawen can talk about something i've done and rip it to pieces too ...

Quote from pricorde :

Hi there, I'm the Rigs of Rods developer.

Scawen got it right, I need a high rate of simulation steps to avoid instabilities. The trucks have a bit too much flex, but making them stronger would require even more steps. Keeping the trucks heavy helps also to keep stability.

Event the wheels are made with beams, so you have also tires flex!

The physics simulation is indeed at fixed rate per second. The advantage is that on high end machines this boosts fps because you do less physics pass par frame. On low end machine, the physics can not be simulated realtime, so I slow the time in the game (the game is in slow-mo) in order to avoid instabilities....

My (limited) understanding is that, as you have already noted, switching to a Runge Kutta (or even higher order) integrator will make a huge difference to instabilities. Euler integrators blow up all over the place.
It would be interesting to know what kind of integrator is used in LFS ? Scawen ?

Here is a good article on the issues of physics models 'blowing up'
(two versions of the same paper - one in pdf)
http://www.gamasutra.com/features/20000215/lander_pfv.htm
http://www.darwin3d.com/gamedev/articles/col0499.pdf

pricorde, I love your game! I'm a "Screamer 4x4" fan, and your game transmits the same fun, freedom and realism It would be great to see this game finished, I will buy it for sure

@col - what's an integrator in this context please? (not mocking, i'm a techy but not a scientist ).

Quote from Becky Rose :

@col - what's an integrator in this context please? (not mocking, i'm a techy but not a scientist ).

numerical approximations to calculate integrations ;P

I'm a techy too, Rose, but I've had to do this stuff before anyway. :-)

An integrator is used to calculate where things end up at the end of the frame (i.e. at a specific time) when they are subject to a force. It's a way of solving differential equations in other words.

http://en.wikipedia.org/wiki/Runge_kutta
and
http://en.wikipedia.org/wiki/Euler_integration

are good references.

Steve

I really waiting ... It will change everything, I hope .
(like in the past, the 3D graphic accelerator cards)

http://www.theinquirer.net/?article=21648

It will change nothing for LFS, as the AEGIA PhysX processor is incompatible with our beloved sim. Maybe there's a way to exploit if for misc eyecandy, like dirt and smoke particles, but it's not possible to accellerate LFS' tyre model.

Quote from Becky Rose :

@col - what's an integrator in this context please? (not mocking, i'm a techy but not a scientist ).

read the article i linked to - it explains it better than I ever could
It starts off very easy to understand, showing you how even the limplest video games use a version of a Euler integrator. It then gets much trickier - so you would probably need to look at other references, but its a good introduction i think.
fwiw, I'm very much a techy/creative rather than a math/science person, so I find this stuff has a steep learning curve (steep like a cliff )

@becky

The thing that i found most enlightening was highlighted by figure3 in that article. I was doing some spring/mass stuff on gameboy, and it kept blowing up on me. So I instinctively started introducing more damping, and the sort of techniques you were suggesting. That approach doesn't work, even though is seems like it should !. Fig3 shows that for the given time steps, the curve with the least change can be the one that blows up (e.g. the most damped one can be worst !).

So the only way to fix things is either to have a faster 'sampling rate' or use a more complicated/accurate method of guessing where everything should be at the next time step e.g. Runge Kutta etc.. The more complicated 'integrator' uses up more resources, but allows you to use a much lower clock for the physics. I suppose the most efficient balance between fancy math and brute force depends on the specific application, and the likelyhood of it blowing up.

Quote from AndroidXP :

It will change nothing for LFS, as the AEGIA PhysX processor is incompatible with our beloved sim. Maybe there's a way to exploit if for misc eyecandy, like dirt and smoke particles, but it's not possible to accellerate LFS' tyre model.

I would like to see much more enviroinment physics where AEGIA PhysX could suite better AFAIK. Better smoke is one thing and perhaps weather and ground changes. Driving line on gravel and grass wear away where people usualy cut's the corner and dirt spreading on tarmac. I think there could be many areas where simple physics could be used.

It's cool to see Scawen getting into RoR, and pricorde getting into LFS!
you guys are legends, even if i can only understand the bits with words like 'wobbly' in.

Hehehe, don't ya just love these geeky pissing contest's!!!!, makes me feel reletively normal and non-geeky that I don't have the foggiest what most of you guys are on about.

Dan,

Pricorde, I back that 100%. Runge Kutta integrators are well suited to problems of e.g. celestial mechanics (although these days it's done in much fancier ways) where the forces are smoothly varying. RK beats Euler in the sense that the error is about the square of the error of the Euler method, so if an error is small, its square is even moreso. But this analysis is all fine and well as long as the forces etc. vary sufficently smoothly over time, which in games is very rarely the case. It may well be that the RK could perform even worse in terms of stability if sudden collisions etc. are taken into account, there is no inherent reason why it should perform any better than Euler. Since absolute accuracy of the solution in a game isn't even a priority (since the trajectory is all the time controlled by the player anyway) I don't think that for game application there's real incentive to use Runge Kutta, especially since Euler can be tailored to treat some exceptional cases such as collisions much more easily.

Quote from pricorde :

For example, if I need 2000 steps/second of Euler integration for stability, the RK would allow to do e.g. only 500 steps/second, but each step of RK is way more complex to calculate so at the end Euler beats RK, by sheer brute force and simplicity [...]

Very good point.

Steve

Salut Pricorde, and congrats !
We had lfs, quite cool with three devs and now just one guy is trying to beat them ! Keep up, may be you say : it is not that much complicated, just basic structural computing, but as nobody did it before, I just applause !
Even if the chassis flex seems to be a bit exagerated (even if some trailer are really that flexible) it is so cool to look at everything bending ! The difference between that and all the game, I mean all the game not just the car sim, is that now it is alive, everything bend as in real life : so cool.
So perfect, I love it ! Keep up Pricorde you have got something !

i really like the game, but... here are some tips that would be usefull=

keys:
- esc = a option menu, instead of quiting game0
- instead of the little screen thing for instruction to move the crane, a key to enlarge that sceern thing.

other:
- ofcourse the flexible trucks(i know ur working on it )
- a "instructionmovie" to see how to do things(for people like me= uni-braincell)
- better turning.

these are some things that would make the game even better, i think...
really love the game

ive got a little problem with ror (at least i had back in .25 havent tried in .26 yet)
basically pedals on my dfp are rathe disfunctional ... i can either set them to combined which results in the game not reacting to pedal input at all and if i set them to sperate i get brake and gas on the gas pedal