3D Programming Tricks - Beginning Android Games - page 572

In Chapter 8, the pseudocode with which we described a physics simulation update looked
like this:
Vector2 position = new Vector2();
Vector2 velocity = new Vector2();
Vector2 acceleration = new Vector2(0, -10);
while (simulationRuns) {
float deltaTime = getDeltaTime();
velocity.add(acceleration.x * deltaTime, acceleration.y * deltaTime);
position.add(velocity.x * deltaTime, velocity.y * deltaTime);
}
We can translate this into 3D space by simply exchanging the Vector2 instances with Vector3
instances:
Vector3 position = new Vector3();
Vector3 velocity = new Vector3();
Vector3 acceleration = new Vector3(0, -10, 0);
while (simulationRuns) {
float deltaTime = getDeltaTime();
velocity.add(acceleration.x * deltaTime, acceleration.y * deltaTime, acceleration.z * deltaTime);
position.add(velocity.x * deltaTime, velocity.y * deltaTime, velocity.z * deltaTime);
}
And that is all there is to it! This simple physics model is again sufficient for many simple 3D
games. In the final game of this topic, we will not even use any acceleration because of the
nature of the objects in the game.
More complex physics in 3D (and 2D) are, of course, harder to implement. For this purpose,
you'd usually want to use a third-party library instead of reinventing the wheel yourself. The
problem on Android is that Java-based solutions will be much too slow, due to the heavy
computations involved. There are some solutions for 2D physics for Android that wrap native
C++ libraries like Box2D via the Java Native Interface (JNI), providing the native API to a Java
application. For 3D physics, there's a library called Bullet . However, there aren't any usable JNI
bindings for this library yet. Those topics are well outside of the scope of this topic, though, and
in many cases we don't need any sophisticated rigid-body physics.
Collision Detection and Object Representation in 3D
In Chapter 8, we discussed the relationship between object representation and collision
detection. We strive to make our game-world objects as independent from their graphical
representation as possible. Instead, we'd like to define them in terms of their bounding shape,
position, and orientation. Position and orientation are not much of a problem: we can express
the former as a Vector3 instance and the latter as the rotation around the x, y, and z axes
(minding the potential gimbal lock problem mentioned in Chapter 10). Let's take a look at
bounding shapes.