TGE physics: strange time and gravity
by Joel Baxter · in Torque Game Engine · 02/06/2002 (1:36 am) · 5 replies
Couple of things that have been bothering me. See what y'all think.
Strangeness #1:
In several files, TickSec is used to represent the amount of time that has passed from one engine tick to the next. This should be 32 ms, or 0.032 sec. If you look at the actual definition of TickSec though, you'll see that it is defined as (F32(1) / TickMs), or 1/32, which is 0.03125. By coincidence this is darn close to 0.032 so it still works pretty well. However if you were to change the tick frequency it would not... let's say that you had one tick every 10 ms; you would want TickSec to be 0.01, but instead it would be 0.1, off by a factor of 10.
In this one I'm really wondering if I have some sort of mental block that is leading me wrong about what TickSec means, since otherwise I can't see why (F32(1) / TickMs) would even accidentally be specified as the definition for TickSec, but I've thought about it and can't see any other interpretation. If I'm correct, and there's an error here, then fixing the definition of TickSec might help the physics modelling in small ways. Heck, it might actually help in large ways, since integrating the movement equations can be finicky.
Strangeness #2:
In player.cc (and also in the vehicle code), gravity is defined as -20. This is later used in an equation multiplying it by TickSec to get a change in velocity over the course of 1 tick, so this number should represent acceleration from gravity. Since that's -9.8m/s/s, and the code seems to work in seconds as its unit for time when dealing with movement equations, then 20 game units must equal 9.8m, for about 2.04 meters per game unit. But, the player bounding box is 2.3 units high, so that would make the player pretty darn tall.
In projectile.cc, on the other hand, we have this code:
(BTW, notice that they use TickMs/1000 instead of TickSec, so this code doesn't have the time accuracy problem mentioned above.)
Now that code seems to indicate that one game unit corresponds to one meter.
Whassup with that? Certainly seems odd. It looks like the player/vehicle constant for gravity acceleration is twice what it should be, but that's hard to believe, as gravity already feels on the "light" side for players.
Hmm. Well, maybe it's just late at night and I'm confused.
Strangeness #1:
In several files, TickSec is used to represent the amount of time that has passed from one engine tick to the next. This should be 32 ms, or 0.032 sec. If you look at the actual definition of TickSec though, you'll see that it is defined as (F32(1) / TickMs), or 1/32, which is 0.03125. By coincidence this is darn close to 0.032 so it still works pretty well. However if you were to change the tick frequency it would not... let's say that you had one tick every 10 ms; you would want TickSec to be 0.01, but instead it would be 0.1, off by a factor of 10.
In this one I'm really wondering if I have some sort of mental block that is leading me wrong about what TickSec means, since otherwise I can't see why (F32(1) / TickMs) would even accidentally be specified as the definition for TickSec, but I've thought about it and can't see any other interpretation. If I'm correct, and there's an error here, then fixing the definition of TickSec might help the physics modelling in small ways. Heck, it might actually help in large ways, since integrating the movement equations can be finicky.
Strangeness #2:
In player.cc (and also in the vehicle code), gravity is defined as -20. This is later used in an equation multiplying it by TickSec to get a change in velocity over the course of 1 tick, so this number should represent acceleration from gravity. Since that's -9.8m/s/s, and the code seems to work in seconds as its unit for time when dealing with movement equations, then 20 game units must equal 9.8m, for about 2.04 meters per game unit. But, the player bounding box is 2.3 units high, so that would make the player pretty darn tall.
In projectile.cc, on the other hand, we have this code:
mCurrVelocity.z -= 9.81 * mDataBlock->gravityMod * (F32(TickMs) / 1000.0f);
(BTW, notice that they use TickMs/1000 instead of TickSec, so this code doesn't have the time accuracy problem mentioned above.)
Now that code seems to indicate that one game unit corresponds to one meter.
Whassup with that? Certainly seems odd. It looks like the player/vehicle constant for gravity acceleration is twice what it should be, but that's hard to believe, as gravity already feels on the "light" side for players.
Hmm. Well, maybe it's just late at night and I'm confused.
#2
#2. The player's gravity is 20m/s not 9.8m/s. Strictly a "feels better" thing. At 9.8 the player floats around too much and nobody liked it.
02/06/2002 (12:45 pm)
#1. Right now it seems to be the number of ticks in a second, and not the duration of a tick in seconds. We'd have to go through the code to see how it's being used... but taking a quick glance, it does seem to be used pretty often as a "duration in seconds", which is wrong. I'm not sure that it will have much impact on the physics, but that should be fixed. Good catch :)#2. The player's gravity is 20m/s not 9.8m/s. Strictly a "feels better" thing. At 9.8 the player floats around too much and nobody liked it.
#3
02/10/2002 (6:41 pm)
Did anyone ever research what was making people floaty? I mean, I run around in 9.8m/s^2 all the time without feeling floaty (sober).
#4
02/10/2002 (6:57 pm)
It's the speed at which the player runs, which is something like 50km an hour. If you run him at "normal" speeds, it feels like he's hardly moving.
#5
That's assuming we're on an earth gravity planet in the first place. Oh well, just more stuff to play with;)
02/10/2002 (9:50 pm)
Huh. So we're really running time at a 1.4:1 ratio (at least for gravity), and then our power suits are letting us run at 20mph (scale).That's assuming we're on an earth gravity planet in the first place. Oh well, just more stuff to play with;)
Torque Owner David Stewart Zink
(b) So convenient that the square root of 1,000 is 31.62278. If you change your tick milliseconds to that all the code should start working at once. TickMask becomes hard to calculate.
(c) I love the phase of development where someone replaces all the constant numbers with whatever manifest constant has the most similar value.
(d) Are SecTick and TickMs supposed to be the same value? (Well, SecTick == F32(TickMs))
(e) You can't set TickMs to anything except a power of 2, so you can't have 10 or even an integral number per second.
(f) I have been much enjoying your posts Mr. Baxter.