Jump to content

A velocity/speed/distance/time question.


kent

Recommended Posts

While working on the speedometer hud, I came up with question about how speed/distance works in Torque. The hud's speedometer needle correctly spins through it's specified angles based on the target's velocity, but I don't entirely understand what the change in movement represents. An ultimate goal for a control like this is to realistically translate the raw game values into a "real speed" that is roughly representative of how the velocity actually feels to the player ... if that makes sense.


To me, the control doesn't accomplish this very well currently (nor does the original TGE version, which behaves identically). But before setting about trying to make it better, I wanted to check some basic core reasoning to make sure my foundation is correct.


So, first ("tu" is used to indicate "torque units"):

speed = obj.velocity


In the game context, would a proper unit of measure for velocity be tu/second? That's what I am assuming.


From there we would get:

tu/minute = speed * 60

and

tu/hour = tu/minute * 60


Providing us with the number of torque units an object would travel in a minute/hour at the current velocity.


So given a velocity of 10, you'd get:

10 * 60 = 600 tu/min

600 * 60 = 36000 tu/hr


Assuming 1 tu ~= 1m, that would mean that a velocity of 10 is roughly equal to 36km/hr. Right?


By the time a vehicle gets up to a velocity of 20/25 things start to feel pretty damn fast. Doing the math we get:

25 * 60 = 1500 tu/min

1500 * 60 = 90000 tu/hr


Which, if we're using the 1tu ~= 1m conversion puts it at 90km/h, or about 55mph.


First thing I'm trying to figure out is if all that is basically correct. If so, I'm wondering if the calculation ends up producing a value that is a bit slower than the velocity feels ... or if that's about right and attempting to drive a pretty basic 3d model across randomly-generated terrain @ 55mph is *supposed* to end up being rather difficult to control.


Any thoughts?

Link to comment
Share on other sites

Thinking about it, it should be possible to follow this backward to tweak the GUI in question. The control displays a range from 0 to 80 mph. So, that would represent a maximum speed of about 128kph ... or 128,000 m/hr (tu/hr).


128,000 / 60 / 60 = 35


So, by this calculation the maximum speed of the control should be 35 - which is considerably less than the default of 100.


Initially, the calculated value results in much better performance from the control. If not perfect, it seems like this approach can get in the ballpark of decently translating between object velocity and speed.


I still wonder if there is a better/more accurate way to do this.

Link to comment
Share on other sites

As far as I can tell, your calculations seem correct. Only input I have in terms of it feeling weird are:


A) torque vehicles have always felt pretty weird to me under the best of circumstances (really looking forward to having full physX vehicles, I saw a note about that from a commit three months ago on the dev branch...?)


and then of course,


B) driving even a real vehicle at 55 mph on anything but a flat road surface likely feels pretty out of control as well.


But mainly I think better physics might be what you're looking for. Torque vehicles have always felt very "floaty" and non realistic to me. I've never tried to make a vehicle game so I didn't spend a whole lot of time trying to tweak them, but that's always been my impression.

Link to comment
Share on other sites

As far as I can tell, your calculations seem correct. Only input I have in terms of it feeling weird are:


A) torque vehicles have always felt pretty weird to me under the best of circumstances (really looking forward to having full physX vehicles, I saw a note about that from a commit three months ago on the dev branch...?)


and then of course,


B) driving even a real vehicle at 55 mph on anything but a flat road surface likely feels pretty out of control as well.


But mainly I think better physics might be what you're looking for. Torque vehicles have always felt very "floaty" and non realistic to me. I've never tried to make a vehicle game so I didn't spend a whole lot of time trying to tweak them, but that's always been my impression.

A lot of the problem I was having was due to calibration. I ended up modifying the GUI a bit so it was possible to accurately align the min/max angles with the dial bitmap. That combined with correctly converting MPH to torque velocity for the maxSpeed made a world of difference. Turns out the vehicle was really topping out more in the neighborhood of 80ish - which is kind of how it felt.


I'm almost done converting a TGE vehicle resource from years ago that makes vehicles much more fun (adds adjustable transmission, rpm power band, etc.) ... so I've been doing a lot of driving over the last day or so. Floaty is a great way to describe the vehicles. It is quite fun ... but not entirely realistic. I was going to increase the impact of "gravity" to see if that would make vehicles stick to the ground a bit better.


I take it adding a physics package to the engine makes vehicles stop working? I haven't gotten that far yet. Did all objects need to be re-done to work with PhysX?

Link to comment
Share on other sites

I have some code in my project where it says in the comment that one Torque unit is not 1 meter, it is aprox 0.691.

Here it is: https://github.com/Duion/Uebergame/blob/development/scripts/gui/clusterHud.cs#L54

I do not use that code yet, I just noticed that it is there, probably from some resource or so.

No idea where it is from originally, or if it is correct, but maybe anyone here knows more about that. The only problem with that math would be, assuming it is correct that 1 Torque Unit is 0.691, that people assume it to be 1 meter and adapt their art onto it, so the speed may be calculated correctly, but the world objects would be off then.

Link to comment
Share on other sites

I have some code in my project where it says in the comment that one Torque unit is not 1 meter, it is aprox 0.691.

Here it is: https://github.com/Duion/Uebergame/blob/development/scripts/gui/clusterHud.cs#L54

I do not use that code yet, I just noticed that it is there, probably from some resource or so.

No idea where it is from originally, or if it is correct, but maybe anyone here knows more about that. The only problem with that math would be, assuming it is correct that 1 Torque Unit is 0.691, that people assume it to be 1 meter and adapt their art onto it, so the speed may be calculated correctly, but the world objects would be off then.

@Azaezel: Very cool - really close to what I was envisioning. Thanks for the heads up.


@Duion: Interesting. I don't think there is a hard-fast correct answer from the engine perspective; Torque uses torque units. Like a movie, perception is created by camera placement and relative object scale. A speedometer simulation needs to capture that perception. More or less like a director saying "OK, how fast do I need to move this 1:32 model to create footage that looks like it is moving the same speed as this full-sized car footage so both can be combined into a cohesive scene. The question is how fast the camera *feels* based on set dynamics. The answer is always going to be a product of the dynamics on set.


I am quite curious what method they used to derive such a precise number. I remember the 1 meter convention discussion being framed around Kork and what consensus agreed the model's reasonable real-world height would be. I have the impression that for original demo art GG just visually matched whatever scaling convention Tribes 2 had used, Not really sure how precise that estimate ever was.


I think if art is created with the convention 1 unit = 1 meter, a speed formula that assumes 1 unit is 0.691 could not possibly be calculating correctly. OTOH, if someone did an analysis of common Torque resources (with equivalent relative scale) and figured out that models in general seem to manifest a scale of 0.691 rather than actually being 1 meter, that would be something to seriously consider. It would certainly be interesting if someone reverse-engineered the art to come up with a more precise estimate.


Any way it goes, I've already added a TorqueUnitScale field so the control can adjust for differing art scales. I'll set the scale to 0.691 and see how it feels.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...