Quote from Vain :

Two thoughts:
1. Delta times are different on different computers. If you want two computers to share common data without updating all relevant data rather often over the wire you'll have to stick with a calculation method that is guaranteed to reproduce the exact same results on any computer.

Running at a set frequency will suffer the same problem because of the same hardware flaw, this is nothing at all to do with techniques and totally related to hardware discrepancies and whether you use a delta or not it is fixed using the same method, network syncronisation.

Quote :

2. Oscillating systems such as suspensions can't be accurately simulated below a certain critical frequency that depends on it's physical properties. A momentary drop in framerate (or increase in delta-time) should not affect any relevant forces.

Oscillation within a delta, agreed. I recall tackling it on a project once (calculating the up and down time within a delta) but I have no recollection of the product that code resulted in, I may have gone to fixed rate.

Some calculations are either done outside of the delta, or more likely executed a factor of <delta> times per sync.

Quote from Shotglass :

you dont get it there is a fundamental mathematical and physical reason to use a small and preferably constant timestep

I do get it, but like I said when you drill it down to maths: additions and subtractions are no problem to a delta but multiplication, division and most other operators are. Solution - simply the maths where possible, deploy techniques which allow you to delta via a combination of tabled results.

I am getting to thinking that you guys are understanding physics only at the level of where something is in the now considering where something used to be the last time the maths where run.

You do realise that time is a dimension too right?

One other point, I think the original discussion (circa 2006) may have been in general gaming terms and not specifically vehicle phsyics, but I can't be arsed to read back now. Vehicle physics is not something I have spent a great deal of time on.

Quote :

(basically exactly what happens whenever 2 cars crash and get catapulted half way across the map in almost every simulator out there)

No that's shoddy programming and nothing at all to do with how often your physics execute. For instance LFS runs at a constant 100fps and it used to have diabolical crashes with barriers, now they are improved yet the physics runs at the same speed. Ergo, that wasn't the issue ;P

Quote :

tons of games have tried that approach and all of them failed miserably most notably in recent history is iracing

An entirely subjective standpoint, iRacing is popular and it's physics are imperfect (I didn't code it afterall *snicker*). LFS is less popular and it's physics are also imperfect. *shrug* I don't know what you are trying to say, there are games where the physics are real? I don't think so.

Quote :

you completely misunderstand what lookup tables are used for
they are used to speed up getting the same result that a complex physics simulation would get to the results of using the lookup table still need to be integrated into a physics engine that runs at a constant rate (which rfactor does to my knowledge)

All I have said is that if I was to tackle a modern driving game I think I would still use a delta [for more of the code than what most others would].

I reject wholeheartedly the notion that an entire system needs to be coded at a fixed rate, ESPECIALLY those aspects which are not syncronisation dependant.

What I do not reject is that there are difficulties in using a delta, that it is complex to code when parts of an algorythm needs to run more frequently than other parts - but if the result does not impact the sum, or if the result impacts the sum in the form of an addition or subtraction, then a delta can be used.

Quote from Becky Rose :

I do get it, but like I said when you drill it down to maths: additions and subtractions are no problem to a delta but multiplication, division and most other operators are. Solution - simply the maths where possible, deploy techniques which allow you to delta via a combination of tabled results.

you are aware that 99% of numerical physics ends deep in solving differential equations? for which what i said fully applies

Quote :

I am getting to thinking that you guys are understanding physics only at the level of where something is in the now considering where something used to be the last time the maths where run.

yeah... no
im an engineer i use numerical physics on most days and while i havent coded a numerical kernel myself my work requires me to have a fairly good understanding of what goes on behind the scenes both from a fundamental perspective as well as what the idiosyncrasies of the solutions are

Quote :

No that's shoddy programming and nothing at all to do with how often your physics execute. For instance LFS runs at a constant 100fps and it used to have diabolical crashes with barriers, now they are improved yet the physics runs at the same speed. Ergo, that wasn't the issue ;P

wrong it has everything to do with it
you sample too rarely so at your next sample 2 bodies intersect and voila shit breaks
i dont know what solution scawen uses for the problem but it probably involves oversampling whenever 2 bodies intersect to find the point when they were merely touching and working out the physics from there
ie the physics rate get increased tremendously to avoid those issues for when the rate isnt high enough

Quote :

I reject wholeheartedly the notion that an entire system needs to be coded at a fixed rate, ESPECIALLY those aspects which are not syncronisation dependant.

well good luck educating the whole world of numerical physics that what theyve been doing fro decades is wrong

Quote :

you sample too rarely so at your next sample 2 bodies intersect and voila shit breaks
i dont know what solution scawen uses for the problem but it probably involves oversampling whenever 2 bodies intersect to find the point when they were merely touching and working out the physics from there

Interpolation, similar to the Newtonian method of calculating square roots, the result is essentially guessed and then run again to get a better guess, more times you run it the closer you get. Trying to simply calculate the result exactly takes a hell of a lot longer, GPGPU's are getting very very good at that kind of thing though, bullet physics has an openCL port that uses it but not had a good look into it.

Quote from Shotglass :

wrong it has everything to do with it
you sample too rarely so at your next sample 2 bodies intersect and voila shit breaks
i dont know what solution scawen uses for the problem but it probably involves oversampling whenever 2 bodies intersect to find the point when they were merely touching and working out the physics from there
ie the physics rate get increased tremendously to avoid those issues for when the rate isnt high enough

Two specific solutions for you:

You mentioned earlier ( I think it was you ) that the jump in Quake resulted in people being able to jump different distances because of it being calculated on a delta and not on fixed rate, I argue its because John Carmack isn't as good as everyone thinks.

I'm not an engineer or a mathematician, according to IQ tests i'm quite clever but I consider myself relatively stupid - my approach is to simply things sufficiently for me to understand them rather than tackle a complex problem with complexity, so my explanation will be on that basis...

The point at which the jump is started is 0 in time.

During the jump the player will rise to a peak and drop to 0 from their starting point - and then below, this is a plottable curve, we know at the start of the jump at what altitude the player will be at at any given time after the jump is made.

We do not need to calculate the difference in position during this jump from point A (0.1 seconds in) to point B (0.11 seconds in) because we already know where the player was, is, and will be.

We simply position the player at point start + delta along the plotted trajectory. Bang, naff all computational time and syncronisable between all participants.

Like I said, time is a dimension. It's so rudimentary to quantum mechanics that you don't need to do differential equations to solve it.

Sadly, most people solve this problem with a differential equation.

-*-

Second problem, calculating when a car intersected with a barrier. You already have the speed and the position of the car at two points in time and you have the difference in time between those two points in time.

You do not need to sample at 100hz to come with +/-1hz of when the car collided, calculating the proportion of the distance travelled prior to intersection and apply that same proportion to the difference in time between start and finish - if you need to allow for acceleration and decelleration within that timeframe it does get more complicated, likewise relative rotations - the solution isnt simple.

Bearing in mind that fixed rate physics is prone to errors in the sample rate too, if the above does not generate comparable accuracy to a fully time stepped simulation in your given application, which it often will as the delta speed is usually not far off a 100Hz system (and often exceeds it) then you may need to detach the calculation from the delta.

However my point that time stepping alone was not the fault is utterly right, I think Scawen mentioned something along the lines of an error in the rebound calculation which LFS experienced with the red and white barriers.

You deal in physics in your day job, where precision is required.

Computer games are not physics. If anything, games should steer clear of them. Given some solutions out there I can't help but feel that they'd could do a much more realistic job if they did!

Quote from Becky Rose :

We do not need to calculate the difference in position during this jump from point A (0.1 seconds in) to point B (0.11 seconds in) because we already know where the player was, is, and will be.

except we dont because the player will interact with the game the world in the game and other players during the jump

Quote :

We simply position the player at point start + delta along the plotted trajectory. Bang, naff all computational time and syncronisable between all participants.

which means you have 0 air control cant be thrown off your trajectory by eg being hit with a rocket and if theres a wall in your way youll end up in a lot of trouble
the number of exceptions that method would require just to keep something as simple as a jump consistent logical and bug free is enormous and would probably far exceed the computational complexity of just simulating the jump in discrete time

Quote :

Like I said, time is a dimension. It's so rudimentary to quantum mechanics that you don't need to do differential equations to solve it.

i may be wrong but im fairly certain youre using words you dont really understand

Quote :

Second problem, calculating when a car intersected with a barrier. You already have the speed and the position of the car at two points in time and you have the difference in time between those two points in time.

first of all how would you have those 2 points in time and space without calculating the cars motion in discrete timesteps?

Quote :

Bearing in mind that fixed rate physics is prone to errors in the sample rate too

wait what? granted theres a slight systematic error from whatever granularity your number representation has but other than that there is no error in the sample rate

Quote :

Computer games are not physics. If anything, games should steer clear of them. Given some solutions out there I can't help but feel that they'd could do a much more realistic job if they did!

i cant help but feel youre talking out of your arse

The more we have his discussion the more respect I am loosing for you, you're cashing in too much these days. I used to think quite highly of you, but you seem to be approaching this from such a close minded position.

If I continue to give solutions you will reject them again and again, we're going nowhere here. On the second solution you facepalmed so completely with maximum stupidity, on the first the answers are so instinctive and obvious to me (as I'm quite practiced in my own techniques) that I do wonder if you are just heckling for the sake of it.

If you get your head out of your ass long enough you might accept there is more than 1 way to skin a cat, you might have your own solution that you believe is better than mine - but that's okay, saying my way doesn't work when I have already written so much software is like a Christian saying science doesnt work, only my explanation from this book can be right.

If you want to carry yourself in that way then carry on, I'm not goig to bother with you. Im just going to unsubscribe the thread.

Interpolation is used because of all the variables, if it was simply 1 solid body in contact with another then there would be many different solutions but even something simple like a tyre hitting a small bump in the track has to exert force on the spring and damper which dictates how much force is exerted on the body mass which in turn has an effect on the 3 other spring/damper combinations, mass and inertia have to be taken into account for all of these, air speed and direction. That's all simple stuff with nice linear characteristics, the tyres are in the middle of that lot and there isn't much linear about sidewall deflection and contact patch areas plus the damn things try and drive up and over the air flowing over them and heaven forbid I mention the fuel sloshing around the tank and the oil in the sump. Nothing to say each of these cant have a thread to its self and shared memory for the interacting elements but considering the excellent job existing physics engines do I think the time would be better spent optimising them to your needs than trying to re-invent the wheel. Oh, and also figuring out some fast procedures for those damn tyres.

My poor brain, ..........or whats left of it.

Lol, if we still took analogue computing seriously it would make things much simpler and we could have an exact replica of a cars physics model on a single chip, its the steps that cause the trouble but there is simply no way around them, we can make them smaller and smaller but cant get rid of them entirely.

Quote from Becky Rose :

The more we have his discussion the more respect I am loosing for you, you're cashing in too much these days. I used to think quite highly of you, but you seem to be approaching this from such a close minded position.

this may come as a surprise to you but your oppinion on my value as a human being a respect from random strangers on the interblag is of very little concern to me

Quote :

On the second solution you facepalmed so completely with maximum stupidity

right....

Quote :

on the first the answers are so instinctive and obvious to me (as I'm quite practiced in my own techniques) that I do wonder if you are just heckling for the sake of it.

lay them out then because from how i understand your magically more correct than a mathematical theory and framework that has been devoloped for decades and probably (cant be bothered to look it up) can be proven to be optimal all these events would require you to trigger interrupts

so lets consider a circle jump which is a fairly common thing that youd expect to work in an arena shooter
the palyer would be continously moving the mouse and thus his air acceleration vector requiring you to interrupt your jump calculation and recalcuate the trajectory every time the player moves his mouse which with the circle jump requiring continous motion is all the time
voila youve just caused infinity interrupts and with them infinity recalculations for you jump and cpu load is though the roof

Quote :

If you get your head out of your ass long enough you might accept there is more than 1 way to skin a cat, you might have your own solution that you believe is better than mine - but that's okay, saying my way doesn't work when I have already written so much software is like a Christian saying science doesnt work, only my explanation from this book can be right.

except your method is based on the experience of someone whos probably never written a physics engine while the normal approach to writing one is based on a sound theory of math and numerical physics that has a very very solid foundation
solid enough in fact that a significant portion of what we unironically call the modern world was created though its use

Quote from Becky Rose :

We do not need to calculate the difference in position during this jump from point A (0.1 seconds in) to point B (0.11 seconds in) because we already know where the player was, is, and will be.

Small note:
As far as I can see you and Shotglass are currently discussing the pro's and con's of numerical integration of differential equations of the first order with sample points equally spaced in time versus higher order numerical integration with variably spaced sample points.

The discussion as to which is better is older than computers are and depends on the set of functions that need to be computed. No need to get worked up about it.

Vain

I agree with Vain.

Ive also been painted into a corner which I'm not in, I simply visit it more often than most because of the way I approach problem solving. But I guess that's just the nature of forums.

Quote from Shotglass :

so lets consider a circle jump which is a fairly common thing that youd expect to work in an arena shooter
the palyer would be continously moving the mouse and thus his air acceleration vector requiring you to interrupt your jump calculation and recalcuate the trajectory every time the player moves his mouse which with the circle jump requiring continous motion is all the time
voila youve just caused infinity interrupts and with them infinity recalculations for you jump and cpu load is though the roof

Have you ever tried a "circle jump" in real life? I'm pretty sure that (bar minor drag differences) you'd still follow the original jump vector.

I am still wondering how other simulators calculate object collisions and can achieve the stop at wall and so on.

So LFS is currently performing some basic physic object calculation at 2000Hz? Object intersection is calculated at 100Hz?
What if there were some very special frequencies for higher speed crashes to calculate the intersection properly. Lets say that the bounding box of tire is coming to curb at high speed and could it be precalculated from integrals and set different frequency for that collision so the calculated forces wouldnt go to strange numbers?
If the physics was calculated on different frequencies for object collision there shouldnt be that big fps drop but problem would be to merge the effect of different frequencies to get the right feeling?

At a guess they would use something pre-emptive like an area around the car with a focus on objects in the direction of travel to predict when an impact is likely to happen and get some of the calculations done before it hits. Collisions are a well known problem and hard to deal with, without any kind of extra collision detection its common for cars to go straight through walls if they hit them fast enough

I really like rigs and rods soft body calculation. With some car models I downloaded the damage is 90% of what I expected. The vehicle physics is lets say 50%. Problem is really with these vertices which can be forced to the moon because of inability to calculate correct spring forces (this happends especially with very high speeds and planes). Inertias are also calculated nicely. Maybe a far future is all game from softbodies with different stiffness...