Game Development Reference
In-Depth Information
There are no real surprises here. We just store the
position
,
up
, and
lookAt
values as
Vector3
instances, along with the perspective projection parameters we also had in the
EulerCamera
class. In addition, we provide a couple of getters so that we can modify the attributes of the
camera. The only interesting method is
setMatrices()
, but even that is old hat for us. We first
set the projection matrix to a perspective projection matrix based on the field of view, aspect
ratio, and near and far clipping plane distances. Then, we set the model-view matrix to contain
the camera position and orientation matrix via
gluLookAt()
, as discussed in Chapter 10. This
will actually produce a matrix very similar to the matrix we “handcrafted� in the
EulerCamera
example. It will also rotate the objects around the camera, instead of the other way around.
However, the nice interface of the
gluLookAt()
method shields us from all those silly things like
inverting positions or angles.
We could, in fact, use this camera just like an
EulerCamera
instance. All we need to do is create
a direction vector by subtracting the camera's position from its look-at point and normalizing it.
Then, we just rotate this direction vector by the yaw and pitch angles. Finally, we set the new
look-at position to the position of the camera and add the direction vector. Both methods would
produce exactly the same transformation matrix. It's just two different ways to handle camera
orientation.
We'll refrain from writing an explicit example for the
LookAtCamera
class, since the interface
is perfectly simple. We'll use it in our last game in this topic, where we let it follow a neat little
spaceship! If you want to play around with it a little, add it to the
LightTest
we wrote earlier or
modify the
EulerCameraTest
in such a way that the
LookAtCamera
class can be used like a first-
person-shooter camera, as outlined in the previous paragraph.
Loading Models
Defining models like our cube in code is very cumbersome, to say the least. A better way to
create these types of models is to use special software that allows WYSIWYG creation of
complex forms and objects. There's a plethora of software available for that task:
ï?®
Blender
, an open source project used in many game and movie productions.
It's very capable and flexible, but also a bit intimidating.
ï?®
Wings3D
, our weapon of choice and also open source. We use it for simple
low-poly (read: not many triangles) modeling of static objects. It's very
simplistic but gets the job done.
ï?®
3D Studio Max
, one of the de facto standards in the industry. It's a
commercial product, but there are student versions available.
ï?®
Maya
, another industry favorite. It's also a commercial product but has some
pricing options that might fit smaller purses.
That's just a selection of the more popular options out in the wild. Teaching you how to use one
of these is well outside the scope of this topic. However, no matter what software you use, at
some point you will save your work to some kind of format. One such format is Wavefront OBJ,
a very old plain-text format that can easily be parsed and translated to one of our
Vertices3
instances.