<p>I think the most common way to have a the "up and down" movement of a vehicle is to actually build a physics simulation.
It does not have to be a very sophisticated one and how much realism you want is up to you.</p>

<p>But just in each frame update the velocity of the car in downward direction (gravity) until it hits the road. Then if the road has an upward slope it will also push the car up (by colliding with the car).</p>

<p>Now you have a new problem and that is the problem that the car remains parallel to the ground-plane. And the physical calculation behind this is a bit more complex.</p>

<p>When detecting if your car hit the ground you would have to detect the exact position of the hit (which part of the car hit the floor?). Then using the gravity, mass and some material properties (all of which you could just set globally and assume as easy values for simplicity) you can calculate how the reaction force to the collision will be. And you know that the force will be exerted on the collision point.
Now when you have the center of mass of the car, and the collision point, and the force created by the ground-collision, you can calculate how to rotate the car.</p>

<p>This is only a very rough sketch of how I learned to handle such things in a "real" way. I hope this was not too confusing, if you have additional questions I can rework the answer later.</p>

CC BY-SA 3.0
2016-06-05T15:47:59.580Z
Thank you, Dragonseel! I actually suspected that all went down to collision detection. Do you think AABB is enough?
phagio
CC BY-SA 3.0
2016-06-05T23:42:31.653Z
A General BB should be fine but the axis alignment of the boxes prohibits you from calculation correct rotation of the vehicles. For the easier just up-down movment you could maybe make them work. But I think for the more general solution you need rotating bounding volumes.
Dragonseel
CC BY-SA 3.0
2016-06-07T08:33:52.040Z
The collision check has to be done with all objects in the scene, correct? Or at least, the ones within a certain distance.
I wonder if calculating the vector between the center of the car and the center of the obstacle and adding it to the car's speed would suffice.
phagio
CC BY-SA 3.0
2016-06-07T08:53:46.657Z
The collision would have to be checked against all nearby objects that you want to be able to colide with. In general using that distance would not work. Think of a long object. It's center of mass would be far away from the object and the force you add would be much too large. What is physically correct to use is the penetration depth aka how deep is the object inside the obstacle (using the maximum depth). But I cannot say that in your special case it is impossible to find some plausible simplification. I just don't know enough about your project and goals.
Dragonseel
CC BY-SA 3.0
2016-06-17T11:57:02.197Z
I actually solved by creating a list of points, checking continually the vehicle's position and direction with respect to the list and updating its speed and angles to match the expected result.
phagio
CC BY-SA 3.0
2016-06-03T17:30:58.390Z
2016-06-03T17:30:58.390Z
Dragonseel
<p>As a CG assignment with OpenGL and SDL, I want to create a clone of the videogame WipeOut instead of the classical car racing game. Examples of motion in 2D have been given and are rather simple to understand; the complexity in 3D is that the road is not planar - when the vehicle approaches a cliff or a vertical loop, it should be translated on the y-axis and rotated to be mantained parallel to the road. I have no idea on how to get and update such informations (translation and rotation for the road). I thought about creating a bezier curve with informations about its derivative (overlapping the road) and keeping track of the movements of the vehicle with respect to the curve, but I don't know if it's the right (simplest) way of doing this. By the way, being able to track the position of the vehicle relative to the curve would also solve some collision problems by limiting its distance.</p>

<p>Of course, this feature is not mandatory - I could just keep a planar road - but I'd like to understand how to do it. Suggestions?</p>

<opengl>
"Anchor" vehicle to 3D path with OpenGL / SDL
phagio
# "Anchor" vehicle to 3D path with OpenGL / SDL

(Asked by: username_0 on 2016-06-02)

As a CG assignment with OpenGL and SDL, I want to create a clone of the videogame WipeOut instead of the classical car racing game. Examples of motion in 2D have been given and are rather simple to understand; the complexity in 3D is that the road is not planar - when the vehicle approaches a cliff or a vertical loop, it should be translated on the y-axis and rotated to be mantained parallel to the road. I have no idea on how to get and update such informations (translation and rotation for the road). I thought about creating a bezier curve with informations about its derivative (overlapping the road) and keeping track of the movements of the vehicle with respect to the curve, but I don't know if it's the right (simplest) way of doing this. By the way, being able to track the position of the vehicle relative to the curve would also solve some collision problems by limiting its distance.

Of course, this feature is not mandatory - I could just keep a planar road - but I'd like to understand how to do it. Suggestions?

**Tags:** opengl


---

## 1 answers

### Answer by username_1 on 2016-06-03. Score: 1 | Accepted answer

I think the most common way to have a the "up and down" movement of a vehicle is to actually build a physics simulation.
It does not have to be a very sophisticated one and how much realism you want is up to you.

But just in each frame update the velocity of the car in downward direction (gravity) until it hits the road. Then if the road has an upward slope it will also push the car up (by colliding with the car).

Now you have a new problem and that is the problem that the car remains parallel to the ground-plane. And the physical calculation behind this is a bit more complex.

When detecting if your car hit the ground you would have to detect the exact position of the hit (which part of the car hit the floor?). Then using the gravity, mass and some material properties (all of which you could just set globally and assume as easy values for simplicity) you can calculate how the reaction force to the collision will be. And you know that the force will be exerted on the collision point.
Now when you have the center of mass of the car, and the collision point, and the force created by the ground-collision, you can calculate how to rotate the car.

This is only a very rough sketch of how I learned to handle such things in a "real" way. I hope this was not too confusing, if you have additional questions I can rework the answer later.

> **Comments:**
> **username_0**: Thank you, username_1! I actually suspected that all went down to collision detection. Do you think AABB is enough?  
> **username_1**: A General BB should be fine but the axis alignment of the boxes prohibits you from calculation correct rotation of the vehicles. For the easier just up-down movment you could maybe make them work. But I think for the more general solution you need rotating bounding volumes.  
> **username_0**: The collision check has to be done with all objects in the scene, correct? Or at least, the ones within a certain distance. I wonder if calculating the vector between the center of the car and the center of the obstacle and adding it to the car's speed would suffice.  
> **username_1**: The collision would have to be checked against all nearby objects that you want to be able to colide with. In general using that distance would not work. Think of a long object. It's center of mass would be far away from the object and the force you add would be much too large. What is physically correct to use is the penetration depth aka how deep is the object inside the obstacle (using the maximum depth). But I cannot say that in your special case it is impossible to find some plausible simplification. I just don't know enough about your project and goals.  
> **username_0**: I actually solved by creating a list of points, checking continually the vehicle's position and direction with respect to the list and updating its speed and angles to match the expected result.  

---

