In Game Physics

[James L]

            I love RCT and would love to help out, but unfortunately my programming experience ends with some embedded C code and a C++ DOS Tic-Tac-Toe game. However, I can help a little with the in game physics.

            First, I'm assuming you guys aren't developing a full blown physics engine and are only adding in bits and pieces where it's needed, (i.e. you're not detecting collisions between every object at all times) but will only add it for roller coasters and some other rides.

            So the first thing you'll probably want is to get a roller coaster moving along the track. The formula for finding velocity is V = Vi + at, where 'a' equals acceleration 't' is equal to time and Vi is the initial velocity. To find the acceleration you just need the sine of the angle the car is tilted at (with respect to the horizontal) multiplied by the force of gravity. So for example, a car titled at 60 degrees, the acceleration would be sin(60) * 9.8m/s = 8.48m/s.

            Now you may have noticed that v = at is a linear equation, it's meant for a constant acceleration, and a roller coaster is far from constant. So what you can do is find the velocity for little increments of time. The smaller the increments of time, the smoother and more accurate this method becomes. So first you figure how many times per second you want to update the cars velocity. Say we choose 100, the 't' in the equation in the inverse of the number updates per second, so 1/100 = 0.01 = t. 50 times per second would be 0.02 and so on...

After every increment you add it to the total velocity and you're left with a accurate approximation of the cars actual speed. In code it might look something like this,
            V = Vp + sin(angle) * 9.8 * 0.01;
            Vp = V;
Vp here can be called 'velocity, previous' and I'm assuming 100 calculations per second.

            To get this to work properly you'll need to know whether the car is moving up or down, so you can tack on a negative sign to one of the directions (if you don't the car will never slow down, it'll just go faster and faster). Or, you can use the full 360 degrees (probably easiest). So instead of saying it's heading 90 degrees straight down, use 270 degrees and you'll automatically get your negative sign.

If you guys find this helpful I can figure out some more stuff, like multiple cars (think I have that one figured) finding G-forces etc...

[Alberth]

I haven't really considered physics yet, I am currently working on getting the graphics up, so you can see what you're doing :p

After a bit of thinking about physics, I think there are several mostly independent issues that need figuring out. It would be great if you can make a few steps here.

Single car:
- Besides gravity, there is also air friction which is needed to prevent you from accelerating too much (ie there is a terminal velocity).
- It would be good if there was some rollercoaster type data involved too, otherwise wooden rollercoaster and steel rollercoasters would behave a lot alike. I am thinking "mass" and "wheel friction", but perhaps there are other interesting parameters that could be used?

angle:
- My current approach does not start from an angle, it starts from a path in 3D, coded as a sequence of cubic spline bezier curves.
- The roll is also provided.
- From these two, the pitch and yaw should be computed. Together with the roll that gives the sprite to draw.
- The gravity vector needs to be computed too (but that's easy; it's simply the z component of the movement, I think).

Train of cars:
- When you connect several cars together, the train of cars as a whole moves.
- Could the distribution of weight be used too (passengers may use only a few seats)?

Passenger experience:
- Nausea needs to be computed from the physics.
- Also something called "excitement" or perhaps "scaryness" of the coaster.
- Perhaps other nice parameters can be computed too? I don't know how coasters are rated but I guess someone has invented a way to give a coaster a grade.

[James L]

- Besides gravity, there is also air friction which is needed to prevent you from accelerating too much (ie there is a terminal velocity).

For that you can make a speed cap, say 120mph or something. Every time the speed is calculated just have it check to see it won't be greater than whatever the speed cap is. Also, in the original RCTs there was a height limit of each type of roller coaster, so it's possible to limit the maximum speed like that.

- It would be good if there was some rollercoaster type data involved too, otherwise wooden rollercoaster and steel rollercoasters would behave a lot alike. I am thinking "mass" and "wheel friction", but perhaps there are other interesting parameters that could be used?

Friction shouldn't be too hard. Every time you calculate the speed subtract a small percentage off, like a coefficient of friction. Then have the percentage differ for different coasters. Mass would only effect friction, and I think it would be negligible. You could achieve it all with the 'friction coefficient.'

angle:
- My current approach does not start from an angle, it starts from a path in 3D, coded as a sequence of cubic spline bezier curves.
- The roll is also provided.
- From these two, the pitch and yaw should be computed. Together with the roll that gives the sprite to draw.
- The gravity vector needs to be computed too (but that's easy; it's simply the z component of the movement, I think).

The pitch angle is all that's needed to find the speed. Unless you're asking me how to find roll pitch and yaw from the path, because I'm not even sure what a sequence of cubic spline bezier curves is!

Train of cars:
- When you connect several cars together, the train of cars as a whole moves.
- Could the distribution of weight be used too (passengers may use only a few seats)?

 I have the multiple cars figured out, it looks like this:

V = Vp + [ (V­_car1 + V_car2 +... V_carN) / N ]

Where 'N' is the number of cars and VcarN = sin(pitch angle of that car) * 9.8 * t (what 't' can be was described in my first post).
The only thing distribution of people would effect would be, say when a coaster is cresting a hill real slow, if all the people were sitting up front the train would have it make it over, or if all the people were in the back, it wouldn't make it. It would be a lot of work for a small feature.

Passenger experience:
- Nausea needs to be computed from the physics.
- Also something called "excitement" or perhaps "scaryness" of the coaster.
- Perhaps other nice parameters can be computed too? I don't know how coasters are rated but I guess someone has invented a way to give a coaster a grade.

I'm not sure how nausea was computed in the original, but you could do some simple things like make it a function of how many negative g's there are, and how much spinning the ride does. These could maybe be computed after the ride has gone through once?
The excitement was called 'intensity' in the originals. It was based on g-forces and how rapidly they were felt. That's a job for the physics engine, and I'm working on that.
A coaster grade could be given once all the ratings have been found (nausea, excitement, and intensity) so it could be a function based on those 3 values without actually doing anything with the physics.

I'm just trying to keep things simple, I think an accurate representation could be made without going too far.

Also, I haven't used Blender in like 8 years, but I am comfortable modeling. I'll see if I can get back into the swing of things and make some models. I'd like to be able to texture too, but it might be a while for that...

[Alberth]

>   >   - Besides gravity, there is also air friction which is needed to prevent you from accelerating too much (ie there is a terminal velocity).
>
>   For that you can make a speed cap, say 120mph or something.

That's a bit crude, air friction also means you approach the upper limit slowly.

>   >   - It would be good if there was some rollercoaster type data involved too, otherwise wooden rollercoaster and steel rollercoasters would behave a lot alike. I am thinking "mass" and "wheel friction", but perhaps there are other interesting parameters that could be used?
>
>   Friction shouldn't be too hard. Every time you calculate the speed subtract a small percentage off, like a coefficient of friction. Then have the percentage differ for different coasters. Mass would only effect friction, and I think it would be negligible. You could achieve it all with the 'friction coefficient.'

I'd have to look it up, but doesn't mass play a role in the conversion from g to v ?

>   The pitch angle is all that's needed to find the speed. Unless you're asking me how to find roll pitch and yaw from the path, because I'm not even sure what a sequence of cubic spline bezier curves is!

No, I think pitch is not enough. Think about roll of 90 degrees, pitch has no influence any more then.

As for cubic bezier stuff, it's juts a 3rd degree polynomial, see also http://en.wikipedia.org/wiki/B%C3%A9zier_curve
"sequence" just means you have more than one to describe the path (useful for very bendy tracks). For physics, just considering one bezier is sufficient, selecting which one to use is a matter of careful administration.

>   >   Train of cars:
>   >   - When you connect several cars together, the train of cars as a whole moves.
>   >   - Could the distribution of weight be used too (passengers may use only a few seats)?
>
>    I have the multiple cars figured out, it looks like this:
>
>   V = Vp + [ (V­car1 + Vcar2 +... VcarN) / N ]

Makes sense.

>   Where 'N' is the number of cars and VcarN = sin(pitch angle of that car) * 9.8 * t (what 't' can be was described in my first post).
>   The only thing distribution of people would effect would be, say when a coaster is cresting a hill real slow, if all the people were sitting up front the train would have it make it over, or if all the people were in the back, it wouldn't make it. It would be a lot of work for a small feature.

I am sure someone will file a bug report for it :p
But indeed, not needed for an initial implementation. It can always be improved later.

>   >   Passenger experience:
>   >   - Nausea needs to be computed from the physics.
>   >   - Also something called "excitement" or perhaps "scaryness" of the coaster.
>   >   - Perhaps other nice parameters can be computed too? I don't know how coasters are rated but I guess someone has invented a way to give a coaster a grade.
>
>   I'm not sure how nausea was computed in the original, but you could do some simple things like make it a function of how many negative g's there are, and how much spinning the ride does. These could maybe be computed after the ride has gone through once?

Sideways g's and big positive g's are also not good iirc. It could be computed with a simulation, which is probably easiest.

>   The excitement was called 'intensity' in the originals. It was based on g-forces and how rapidly they were felt. That's a job for the physics engine, and I'm working on that.

Nice!

>   A coaster grade could be given once all the ratings have been found (nausea, excitement, and intensity) so it could be a function based on those 3 values without actually doing anything with the physics.

Some form of "level" is needed, more can always be added later.

>   I'm just trying to keep things simple, I think an accurate representation could be made without going too far.

Good idea, first have something that works mostly.

>   Also, I haven't used Blender in like 8 years, but I am comfortable modeling. I'll see if I can get back into the swing of things and make some models. I'd like to be able to texture too, but it might be a while for that...

Ah, you have to talk to our graphics dev for that. He is not around very much, and seems awfully busy at the moment.

[James L]

That's a bit crude, air friction also means you approach the upper limit slowly.

This is one of those things though, that I don't think anyone will notice, I doubt it was even in the original RCTs. It could always be added afterwards though. I had to do a problem like this once, I think the air resistance varies quadratically or something. 

I'd have to look it up, but doesn't mass play a role in the conversion from g to v ?

It shouldn't, I think a problem where you find the final velocity of an object using the potential and kinetic energy equations shows it. Potential = mgh, Kinetic = 0.5mv^2. When solving for V the mass drops out.

No, I think pitch is not enough. Think about roll of 90 degrees, pitch has no influence any more then.

As for cubic bezier stuff, it's juts a 3rd degree polynomial, see also http://en.wikipedia.org/wiki/B%C3%A9zier_curve
"sequence" just means you have more than one to describe the path (useful for very bendy tracks). For physics, just considering one bezier is sufficient, selecting which one to use is a matter of careful administration.

Ahhh, I meant the angle with respect to ground.

I'll read up on the curves too. Do you have an example curve you can show me, like the track that's been made for the news post? 

I am sure someone will file a bug report for it :p
But indeed, not needed for an initial implementation. It can always be improved later.

You'd be surprised what some games do, some just round up g to 10m/s, other games don't even use F=MA! (there is a reasoning to this, but I cant remember what).


From the little bit I've done on g-forces, it seems pretty simple.
Gs = (V^2 / r) / g
Where V is speed, r is the radius of the circle it's traveling through and little g is 9.8
Seems easy enough for dips hills and unbanked turns, but banking, inversions and all that fun stuff makes it a little harder.

[Alberth]

Seems fine to abstract from air friction. We'll eventually get a patch to add it :)

Ah right "0.5mv^2" looks familiar. Ok, my memory is thus wrong.

Angle with respect to the ground is still a bit wobbly, as not all ground is level :p
You mean with respect to the z-plane. That should work indeed. Not sure that you actually need to compute the cos though; the direction vector of the path curve already gives you a fraction of z versus the movement vector, which is also what cos expresses.

I just posted a blog explaining the math a bit, I don't think there is anything new in it for you, but I added an example of a spline that is more exciting than a straight horizontal line :)  This one is the most complicated one that I have currently. You should be able to make new cases easily, like a horizontal line with full rotating roll, or so.
Each tile in the game is a (vertical) stack of voxels. x/y positions inside a voxel run from 0 to 255 (inclusive), z positions run from 0 to 127 (also inclusive) in a voxel.
In other code, you'll find z to run from 0 to 255, but that's wrong and should be fixed (although it's unlikely to happen any time soon, or at all).
The world origin is at the bottom corner furthest away from you, with positive z running up, positive x running to the left, and positive y to the right.

[James L]

Haven't got much of a chance to look at this today, but my gut feeling is to use the derivative to find the angle with respect to horizontal. Only catch would be the need to know where exactly the car is on the curve when the angle is found.

I'll spend some more time on this and get back to you.

[Crof]

Would it be wise to add a .cpp file dedicated to methods involving solving relevant physics problems like acceleration, gravity, air resistance, G-forces, etc?  Maybe it could be used to handle other things like randomness and anything else math intensive that is useful to more than one object.

Two reasons I suggest this is the obvious "solve the problem once, use everywhere" benifit, but also I fear solving physics problems with the real formula may prove to be far to CPU intensive when the game gets populated.  Personally I'd like to start with real equations, but if the CPU load gets too much then its very easy to just change them to simpler equations that get close to real world results while using simpler "fake" formulas.  If they aren't centralized then it could become a nightmare to change them.

I wouldn't mind taking some time soon to fill in such a file with relevant methods and formulas, but someone like Alberth or another project leader would need to create the basic file, name it, and add it to the project and svn.  Even if I'm able to submit a patch with a new file, I don't want the pressure of naming it ;)

[Crof]

Also, I had a question come up while ago that's relevant to physics:

How big is a square in the game in real-life measurements?  (I assume that we'd be initially working in metric)

2 meters x 2meters?
Not sure of the height relation to width, but if I recall they are shorter than they are wide.

I wasn't sure if this was decided yet or not, but it'll be important for physics and the eventual display of things like speed to the user.  (I'm sure they won't care to know their roller coaster has a top speed of 180 voxels/hour hehe)

[Alberth]

Wouldn't it be used in exactly one place, namely in the roller coasters? Since it is all object-oriented code, the computer will duplicate it for every coaster that is built.

Unless I am missing something, the logical place would be in the file that computes the path/speed of it.
Math formulas are usually not very big, so a separate file seems a bit overkill-ish to me at this time.

One thing to watch out for is duplication of code however. I prefer almost anything above that :)
If you need a filename, "physics.{h,cpp}" would seem like a good name :)

[Alberth]

The graphics are 1/2 height of the width, ie 2 voxels on top of each other is a cube in term of graphics.
The used coordinate system is not reflecting that however. The z size is 256, which is also the x as well as the y size.

Tbh, I have no idea of how the voxel size relates to the real world. I'd say make something that looks nice in-game, then relate that to a nice real-world number.
If you try to make it "real" you're probably forcing yourself in a corner unnecessary. The goal of the game is to be a fun game, it is not aiming to be a realistic simulation of real-world things, if you ask me.

[James L]

Finally did some more work on this, think I have g-forces figured out. Just up to you guys to do the hard stuff.

There are two formulas, and both are pretty simple. To find the acceleration felt through a turn you need the radius of the circle that car is passing through. So first you have,
r = V^2 / g*tan(angle)
Little 'r' is the radius, 'V' is the speed of the car, 'g' is the acceleration due to gravity (9.8 m/s/s), and the tan(angle) is the angle the car is tilted. Just like before the angle is in respect to some sort of world origin (maybe the voxel origin or something).

With the radius found you can plug and chug into this formula: a = V^2 / r. That gives you the acceleration in m/s (or whatever unit of length is used), divide this result by 'g' (9.8) to give you an answer in 'G's'

This gives the same old problem of finding angles, and which ones you need to use. I'll do some more work and come up with a way to roll this all into one process, taking into account the roll orientation and all that other stuff.

Some implementation suggestions though. This won't need to be run as frequently as the speed calculations since this is all behind the scenes. Even 10 times less I think would be accurate enough for us.

[James L]

I'm back and I think I got it. There are two g-forces that need to be found, lateral g's and vertical g's.

Lateral G's
This is found using the yaw angle. This is the angle the car is facing in the XY-plane. With that angle you run through the two equations above, but now you want to include the roll of the car (like in a banked turn). Just add on, aSin(rollAngle) where 'a' is the acceleration (Not converted to 'g's'), and the angle is the roll angle.

Vertical G's
Found using the same angle to find speed (the angle with respect to the z-plane). And, adding in the roll you have aCos(rollAngle), same variables as above.


I'll do a little example to better illustrate how it works.
The car is running through a banked turn at 15m/s. The track is banked at 25 degrees, but other than that the track is horizontal. The turn is a 45 degree turn.
First we'll do the lateral g's. Find the radius, r = 15^2 / g tan(45) = 22.95. Now the acceleration, a = 15^2 / 22.95 = 9.8 (unintentional, I swear) . Since it's banked we have to add in the second term, so we have, aSin(roll) = 9.8sin(25) = 4.14. Add these two together, 4.14 + 9.8 = 13.94, divide by 9.8 to find the G's and we have 1.4 g's.

Running through that example I noticed this may only work if the angles are found once per track piece... Or that lateral g's should only be found on curved and inversion pieces... Straight pieces can still have vertical g's (like a lift hill), but the whole radius method won't work for straight pieces. Lots of little things to take into account.

[Alberth]

I don't have the entire picture yet, I need to think it through one time. It should be quite doable, it's just forces.

One first problem seems to be that there is no radius. I can calculate the position and orientation of a car at every point at the track though. Speed is obviously also derivable by doing a simulation.
Given that there are no unknown variables in play here, I don't see why you'd want to compute these forces more than once, for example during "testing" of the track.


A more interesting problem is the "scaryness" or "excitement" or whatever you want to call it. Absolute no idea how to derive a number for that :(

[James L]

A more interesting problem is the "scaryness" or "excitement" or whatever you want to call it. Absolute no idea how to derive a number for that :(

Shouldn't be too hard. I know the intensity is based on g-forces, and excitement on turns and nearby scenery. I could  graph g-forces vs. intensity and come up with a formula, it probably won't be exact but it'll be close. I could do the same thing for the excitement and nausea rating.