Bob just got fatter. In addition to the mesh we use for rendering (the rectangle mapping to Bob's image texture), we now have a second data structure holding his bounds in some form. It is crucial to realize that while we model the bounds after the mapped version of Bob in model space, the actual bounds are independent of the texture region we map Bob's rectangle to. Of course, we try to have as close a match to the outline of Bob's image in the texture as possible when we create the bounding shape. It does not matter, however, whether the texture image is 32x32 or 128x128 pixels. An object in our world thus has three attribute groups:
■ Its position, orientation, scale, velocity, and acceleration. With these we can apply our physics model from the previous section. Of course, some objects might be static, and thus will only have position, orientation, and scale. Often we can even leave out orientation and scale. The position of the object usually coincides with the origin in model space, as in Figure 8-10. This makes some calculations easier.
■ Its bounding shape (usually constructed in model space around the object's center), which coincides with its position and is aligned with the object's orientation and scale, as shown in Figure 8-10. This gives our object a boundary and defines its size in the world. We can make this shape as complex as we want. We could, for example, make it a composite of several bounding shapes.
■ Its graphical representation. As shown in Figure 8-12, we still use two triangles to form a rectangle for Bob and texture-map his image onto the rectangle. The rectangle is defined in model space but does not necessarily equal the bounding shape, as shown in Figure 8-10. The graphical rectangle of Bob that we send to OpenGL ES is slightly larger than Bob's bounding rectangle.
This separation of attributes allows us to apply our Model-View-Controller (MVC) pattern again.
■ On the model side we simply have Bob's physical attributes, composed of his position, scale, rotation, velocity, acceleration, and bounding shape. Bob's position, scale, and orientation govern where his bounding shape is located in world space.
■ The view just takes Bob's graphical representation (e.g., the two texture-mapped triangles defined in model space) and renders them at their world space position according to Bob's position, rotation, and scale. Here we can use the OpenGL ES matrix operations as we did previously.
■ The controller is responsible for updating Bob's physical attributes according to user input (e.g., a left button press could move him to the left), and according to physical forces, such as gravitational acceleration (like we applied to the cannonball in the previous section).
Of course, there's some correspondence between Bob's bounding shape and his graphical representation in the texture, as we base the bounding shape on that graphical representation. Our MVC pattern is thus not entirely clean, but we can live with that.
Was this article helpful?