The physics rate is disconnected from the frame rate, but not locked at
288hz. Based on your 1/2 real time comment, it appears that on the system
described was achieving approximately 144hz.
The physics rate is disconnected from the frame rate, but not locked at
288hz. Based on your 1/2 real time comment, it appears that on the system
described was achieving approximately 144hz.
What I'm referring to is the integration time step the simulation is using
for its motion calculations, i.e., simulated time, not "real measured time".
The amount of time it actually takes to do the physics calculations is far,
far less than 1/288th of a second per cycle, even on my P-60, which is about as
fast as a stampede of turtles crawling through peanut butter, if you'll pardon
the expression :-P Games will run through their physics code to cover movement
for one graphics frame very quickly, then spend the majority of the rest of the
time drawing graphics.
If you ran GPL at 30 fps, which you'd probably agree is more than fast enough
to run 288hz physics, the physics loop would move the car about .00347
"simulated" seconds at a time, recalculate, do it again, etc., about nine or
ten times between graphics frames. If the frame rate changes to half this
value, the .00347 "simulated" time step remains the same (1/.00347 = 288Hz) ,
while it now might loop through the physics code twice as many times as before
in between graphics frames. In other words, the car is still moving .00347
seconds at a time according to the calculations, but you won't see it all
unless your frame rate is 288 or better. If that's how GPL does it, I'd say
the physics is "locked to 288Hz" as they claim (probably true).
If you wanted to look at this in terms of real time frequency of the physics
calculations, please note that the physics loop probably takes up less than 5%
of this 30 frames per second. So to equate this to real time Hz, GPL's physics
would run at 5760 Hz when the frame rate is 30. The rest of the time, it's
drawing graphics or doing other things. Mine ran at half speed, so it might
have really running at around 2880Hz, if you wanted to compare it that way.
Either way, just because my frame rate was horrible, doesn't mean my P-60
wasn't running the physics at only 144Hz.
My point is, the "simulated time step" is locked, even if it takes my ancient
machinery a day to crank out one second worth of driving time. If the time
step it was making during calculations was 1/288th of a second each (even
though it took a few seconds to make the calculations for that 1/288th of a
second), the physics system is still locked to 288Hz, in other words, the
integration time step the motion equations were using was .00347 seconds.
I ran a 1:30.xx at Monza, even though it took about 3 minutes "real time" to
do it. Know what I mean? The physics time step (or frequency) was still the
same, it just took twice as long to crunch through the numbers and draw the
graphics.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Ok, I see we are talking apples and oranges.
Yes I agree every physics computation always represents 1/288th of a second
of race time. My point was that it's quite possible to have less than 288
physics computations per second of real time because of background
operations on the computer. Things like virtual memory disk access can hog
up the CPU and can cause the physics computations to fall behind.
Just because you're getting lower frame rates doesn't mean you're getting
lower physics rates. It depends on the cause for the lower frame rates.
However if you are getting the maximum (36) fps, I can't see how it's
possible to be getting less than 288 physics computations per second since
the physics should have priority.
With online racing, when the server's opinion of racetime, and your
computer's opinion of racetime differs by enough a clock smash happens. It
would make sense that in this "disagreement" the server is considered
correct.
Ah, I see what you're talking about now :-) Yes, that must wreak havoc
during online races. I haven't even begun online programming yet and don't
know if I ever will with problems like these. Physics hurts my head enough as
it is :-)
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
...
It's just that I apply a braking torque (or force) and if this is
large, it is normal that the wheel starts moving badly. However, I
check somewhere that the brakes keep the wheel from moving, and then
fix the rotation speed to 0. Haven't tested yet what the numbers are,
but it must be in there. Not a big problem probably.
His slip vector algorithm does do well I must say. ;-)
I currently use a friction circle approach from Genta's book, where
you downsize Fy (lateral) based on Fx and the maximum Fx.
I have some pages on a combined model, but gosh, it introduces even
more coefficients, so no go for the moment!
Nope, that was just for the body rotation. Works perfectly.
...
Sounds like a slipratio delay; like (I just read this 2 days ago) the
flywheel does away with engine vibrations because of its inertia,
keeping a smoother acceleration path.
The concept could be introduced anywhere to get rid of vibrations
actually, but it's hard not too touch realism.
Yes, it does seem like that. Works a bit the same like averaging,
since your effectively multisampling (like in the graphics dept).
Oops, we're getting offtopic. And I'm getting tangled in delayed work.
Must zip!
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
I update the controller per frame drawn. It still does nicely at
80fps, no FF speed problems (MSFF, serial) that I expected.
But I haven't profiled where the time is spent, might still be in
DInput.
I just have an idlefunc() which calls OnGfxFrame() somewhere, which
does a controller update.
So the frequency varies. (ah, heresy!)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
Ash (Lost in a world of "i'm sure that should work" atm)
|
| > lol. This is the "Sim racing and money" thread!
|
| Oops, we're getting offtopic. And I'm getting tangled in delayed work.
| Must zip!
|
|
| Ruud van Gaal, GPL Rank +53.25
| Pencil art : http://www.marketgraph.nl/gallery/
| Free car sim : http://www.marketgraph.nl/gallery/racer/
Sometimes you need to go back and plug out as many things as possible
until behavior is workable again. And then see where things go off.
Anyway, hope you'll get the progress back again.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
I think its the OpenGL text that is to blame though, I have a mass of it,
and a few guys on the OpenGL forum said their program spent 90% of its time
in that code (eek!). So that could be a place to start.
Keep up the good work Ruud. By the way you are working too hard....work on
that GPL Rank :)
Ash
GPL Rank -10.8
:))
|
| Anyway, hope you'll get the progress back again.
|
|
| Ruud van Gaal, GPL Rank +53.25
| Pencil art : http://www.marketgraph.nl/gallery/
| Free car sim : http://www.marketgraph.nl/gallery/racer/
I agree Ruud...
but i expect this is exactly where GP2/3 fails horribly, i think its physics
engine runs at whatever the framerate is. Thats why the framerate is stored
in the replay files, as when viewing replays, the physics model is
recalculated (only driver inputs and start X-Y are stored), so varies
between source and replay will produce replays that make no sense.
It also explains the slomo, and the resulting problems (impossibilities) for
online or networked racing (time synchronization). In other words, it sucks.
But that was well known already.
Martijn
> I agree Ruud...
> but i expect this is exactly where GP2/3 fails horribly, i think its
physics
> engine runs at whatever the framerate is. Thats why the framerate is
stored
> in the replay files, as when viewing replays, the physics model is
> recalculated (only driver inputs and start X-Y are stored), so varies
> between source and replay will produce replays that make no sense.
> It also explains the slomo, and the resulting problems (impossibilities)
for
> online or networked racing (time synchronization). In other words, it
sucks.
> But that was well known already.
> Martijn
Agree with you almost completely here, but you forget one thing: the method
of recording input and recalculating the physics creates the possibility for
a very thorough check for cheats. Any changes to the track or the car
properties will produce what you call "replays that make no sense", thereby
revealing the cheat. The input stream is also the hardest thing to reproduce
artificially (which would be the biggest cheat of all), since the physics
engine is more or less a one way algorithm, not easy to reverse. I figure
that an artificial replay is a lot easier to make in a system that records
position information along with some other things.
So I hope that when they remove the connection between frame rate and
physics engine to get rid of slomo and improve (or should I say make
possible....) network play, the input recording bit will stay as a powerful
check against cheaters. This could coexist in my view with a replay system
based on position info.
Bart Westra
lol. Shame! I'll come running to you for help when I get into DirectX,
probably by about the year 2050 ;-) I do have an interesting sound idea.
(We're waaaay off topic now, but oh well :-)) Is it a lot of work to set up
DirectSound to take an array of data and play it through a sound card? Say a
combined 8 cylinder intake and exhaust pressure profile from a simulated
engine, at different rpm levels, etc. :-)? I'd be curious what my data might
"sound" like. Perhaps it would be too "computery", but heck, an engine sound
*is* this pressure profile, so maybe it would work!
If so, even changing the camshaft a little would produce a new sound. What
do you think?
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Frustrating. Once your friction reversal algo is right, it'll probably go
away. Wierd though that it came back. Maybe the slipratio differential
equations you're using now are causing this. (Stab in the dark on my part)
Wierd. I still don't have the book, but I would think that inputting slip
ratio and slip angle into Pacejka's formula would give the right output,
without reducing anything. It seemed to me that that was the point of it, to
do away with the friction circle. I better get the book, I guess :-)
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
>I agree Ruud...
>but i expect this is exactly where GP2/3 fails horribly, i think its physics
>engine runs at whatever the framerate is. Thats why the framerate is stored
>in the replay files, as when viewing replays, the physics model is
>recalculated (only driver inputs and start X-Y are stored), so varies
>between source and replay will produce replays that make no sense.
Ofcourse, code written like that becomes overly complex and can only
become harder to maintain. Too bad this perhaps means there will never
be GP4, since Geoff should do a complete rewrite. And not in
assembler, please.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
...
Hope I'll be around then. ;-)
When pushing 80, I hope we do have the virtual powerchair with mind
connectors (which all babies will get implanted at birth) so we can
actually feel the G forces by neural stimulations.
Check out Staccato (http://www.staccatosys.com/). WSC uses it, for
example. There's a small car engine demo which bases the sound on some
variables. I don't know exactly how active they are; I emailed them
some time ago to see if their product would be multiplatform
(Linux/IRIX/Win32), but haven't heard from them.
Given the small example I heard on TrackTalk some time ago (when the
West brothers were giving an interview), you can get it too great
heights.
The only drawback I see here is that people will want to insert their
own samples, and it's easier that way. But the best thing would be a
mix of samples and synthesizer-like malformers, something like that.
Difficult to get working like you want to, I think. :) But setting up
a few DX sound buffers is relatively easy. You might want to check out
the qdxsbuf.cpp file in my QLib (at my site, at programmers->source
code->documentation). It does some sound buffering stuff in DirectX in
C++.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/