-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathwriteup.html
More file actions
executable file
·380 lines (319 loc) · 17.3 KB
/
writeup.html
File metadata and controls
executable file
·380 lines (319 loc) · 17.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
<HTML>
<HEAD>
<TITLE>
COS 426 Final Project
</TITLE>
<BODY>
<CENTER>
<H2>
COS 426, Spring 2011<BR>
Ricky Arietta (rarietta), Alice Fuller (aafuller), Amy Ousterhout (aousterh), and Robert Timpe (rtimpe) <BR>
</H2>
</CENTER>
<HR><BR>
<!------------------------------------------------------------------------>
<!------------------------------------------------------------------------>
<H2>List of Implemented Features</H2>
<!------------------------------------------------------------------------>
<!------------------------------------------------------------------------>
We have implemented the following features:
<ul>
<li><A href="#requiredfeatures"> Required Features: </A>
<ul>
<li>3D Perspective Viewing and Objects
<li>Lighting and Smooth Shading
<li>User Input
<li>Computer Control
</ul>
</ul>
<ul>
<li><A href="#advancedfeatures">Advanced Features: </A>
<ul>
<li>Simulated Dynamics
<li>Texture Mapping
<li>Multiple Views
<li>On-screen Control Panel
<li>Procedural and Physically-Based Modeling
<li>View Frustum Culling
<li>Level of Detail Control
<li>Collision Detection
<li>Sound
</ul>
</ul>
<HR><BR>
<!------------------------------------------------------------------------>
<H2><A name="requiredfeatures"> Required Features </A></H3>
<!------------------------------------------------------------------------>
<H3><A> 3D Perspective Viewing and Objects </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="bobsled.png"><IMG width=512 src="bobsled.png"></A><BR>
</TD>
</TR>
<TR>
<TD >
Our game consists of 3D objects - mainly bobsleds, tracks, and obstacles. We provide perspective views of our scene using the command "gluPerspective". The camera follows the bobsled as it races, so it moves based on the motion of the bobsled.
<BR>
The main model for our gameplay is the bobsled model. The bobsled model is a struct defined in our scene that contains four separate mesh files -- a sled body, sled blades, helmets, and helmet masks. We created all of these models in Maya and exported them as .OBJ files. We modified our scene reader to support .OBJ files, also reading in texture coordinates. Each of these meshes is associated with its own material ID. Additionally, the bobsled contains a position and a velocity, which are updated according to the real time physical calculations, and 2 separate cameras. These cameras are a third and first person viewpoint, and they are transformed along with the sled. There are a few other fields used for tracking purposes.
<BR>
The other major models in our scenes are the track pieces. These were also modeled in Maya and exported. Each track piece consists of a polygonal semicircle that is extruded along a central axis. Each track piece stores information necessary for translating the sled. These include vectors pointing along the track, normals for the start and end, positions for the start and end, etc. There are 7 different types of tracks (straight, turns, approaches, and exits in each direction), and each could be tunneled. The bobsled can rotate all the way around a tunnel without falling off. The track was built by connecting a series of these track meshes and rotating them through space.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A>Lighting and Smooth Shading </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="lighting_0.png"><IMG width=256 src="lighting_0.png"></A><BR>
</TD>
<TD vAlign=top align=middle>
<A href="lighting_1.png"><IMG width=256 src="lighting_1.png"></A><BR>
</TD>
<TD vAlign=top align=middle>
<A href="lighting_2.png"><IMG width=256 src="lighting_2.png"></A><BR>
</TD>
</TR>
<TR>
<TD colspan=3>
Many objects in our scene are lit using OpenGL's lighting model. The bobsleds can be lit in this manner when they are not texture mapped. The helmets, ski masks, and obstacles are always lit using OpenGl's lighting model.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A>User Input </A></H3>
<TABLE>
<TBODY>
<TR>
<TD >
Our game allows players to control their bobsled by steering left and right using the arrow keys (left and right). In addition, players can switch between first and third person view using the 1 and 3 keys, respectively. Finally, players can control the level of detail in their game using the + and - keys.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A>Computer Control </A></H3>
<TABLE>
<TBODY>
<TR>
<TD >
Our game involves complex simulations of the physics that govern the motion of the bobsleds. It also includes various types of obstacles that aim at the bobsleds (for example, snowballs are dropped based on the location of the bobsled). These are discussed in greater detail below.
</TD>
</TR>
</TBODY>
</TABLE>
<hr><br>
<!------------------------------------------------------------------------>
<H2><A name="advancedfeatures"> Advanced Features </A></H2>
<!------------------------------------------------------------------------>
<H3><A > Simulated Dynamics </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="first_person.png"><IMG width=512 src="first_person.png"></A><BR>
<A >First Person View</A>
</TD>
<TD vAlign=top align=middle>
<A href="third_person.png"><IMG width=512 src="third_person.png"></A><BR>
<A >Third Person View</A>
</TD>
</TR>
<TR>
<TD colspan=2>
The forces that we calculate are the force of gravity, friction, and the normal force. The normal force is calculated using both the force of gravity and the centripital force cause from roation with in the track as well as the centripital caused by the tracks that are curved.
We set the new position of the bobsled in three different ways.
For the straight track we translate the bobsled by the amount of change in the along direction and then we rotate the position around the around based on the side movement of the bobsled.
For the curved tracks we set the forward position by rotating the bobsled around the pivot point of the track. To figure out what is the forward direction we also rotate the track's along vector at each point. We then rotate the bobsled around the along that was calculated by the change in side movement.
The last movement is when the bobsled is off the track. First the bobsled must check if it has fallen off. If it has then track->isFalling is set to true. Now the only force that is calculated is that of gravity. We then translte the bobsled along the vector of the velocity by the correct amount. we also set it to rotate by a certain amount for each step.
</TD>
</TR>
<TR>
<TD vAlign=top align=middle colspan=2>
<A href="snow.png"><IMG width=512 src="snow.png"></A><BR>
<A >Snow</A>
</TD>
</TR>
<TR>
<TD colspan=2>
Also, snow falls from the sky throughout our game. This is implemented using Ricky's implementation of particle systems.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A > Texture Mapping</A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="flag_texture.png"><IMG width=256 src="flag_texture.png"></A><BR>
<A >American Flag</A>
</TD>
<TD vAlign=top align=middle>
<A href="checker_texture.png"><IMG width=256 src="checker_texture.png"></A><BR>
<A >Checker</A>
</TD>
<TD vAlign=top align=middle>
<A href="jamaica_texture.png"><IMG width=256 src="jamaica_texture.png"></A><BR>
<A >Jamaican Flag</A>
</TD>
</TR>
<TR >
<TD colspan=3>
All of our models are in the obj format. This allows us to specify a mapping from object space to texture space in the meshes. When we parse a .obj file, we store texture mapping information in R3Mesh along with vertex and face information. Then during rendering, we use OpenGL texture mapping functions on this data to texture our models.
<BR/> <BR/>
Texture sources:<BR/>
Checker pattern: provided with Assignment 3<BR/>
American Flag: <A HREF="http://people.eku.edu/pedersonn/mongoliaFire/american-flag.gif">http://people.eku.edu/pedersonn/mongoliaFire/american-flag.gif</A> <BR/>
Jamaican Flag: <A HREF="http://upload.wikimedia.org/wikipedia/commons/0/0a/Flag_of_Jamaica.svg">http://upload.wikimedia.org/wikipedia/commons/0/0a/Flag_of_Jamaica.svg</A> <BR/>
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A > Multiple Views </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="first_person.png"><IMG width=512 src="first_person.png"></A><BR>
<A >First Person View</A>
</TD>
<TD vAlign=top align=middle>
<A href="third_person.png"><IMG width=512 src="third_person.png"></A><BR>
<A >Third Person View</A>
</TD>
</TR>
<TR>
<TD colspan=2>
Our game can be played using one of multiple different views. The default view is "third person" which places the camera at a fixed position relative to the bobsled (behind it and above). First person view is from the perspective of inside the helmet of the front bobsleder. Players can switch to first person view and back to third person view using the '1' and '3' keys. Both cameras are stored within the Bobsled object and are transformed whenever the bobsled moves.
We also tried splitting our screen and having two bobsleds running simultaneously to make the game multi-player. However, rendering the scene twice each frame cause it to slow down an unreasonable amount, so we limited our game to one player at a time.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A > On-Screen Control Panel </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="control_panel.png"><IMG width=512 src="control_panel.png"></A><BR>
</TD>
<TD vAlign=top align=middle>
<A href="winning.png"><IMG width=512 src="winning.png"></A><BR>
</TD>
</TR>
<TR>
<TD colspan=2 >
Our game includes an on-screen control panel. This control panel is generated by taking an orthographic projection of the track and bobsleds from above, using the command glOrtho. We also show the time in the control panel (how long the game has been running for). The time stops if/when you win or go off the edge of the track. It also announces "Player has Won!!" when a player completes the game.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A > Procedural and Physically-Based Modeling</A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="mountains.png"><IMG width=512 src="mountains.png"></A><BR>
</TD>
<TD>
<A href="mountains2.png"><IMG width=512 src="mountains2.png"></A><BR>
</TD>
</TR>
<TR>
<TD >
Mountains are shown here with faces hidden and edges rendered. This makes it easier to see all of the mountains which are rendered. The mountains are procedurally generated using the <A HREF="http://www.gameprogrammer.com/fractal.html">Diamond-Square algorithm</A> for terrain generation. We generate mountains randomly each time the game starts. Two sample mountain ranges are shown above. When we generate mountains, we create a two dimensional array, used as a height map. The polygons and normals used in rendering are then computed on the fly when needed. The mountains are rendered to intersect the ground plane so that the player can't see underneath them. The mountains thus appear to be very far in the distance.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A > View Frustum Culling </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="mountains.png"><IMG width=512 src="mountains.png"></A><BR>
</TD>
</TR>
<TR>
<TD>
The array created by mountain generation is of size 129 by 2049. Attempting to render all of these polygons for each frame causes the game to run very slowly, and most of the polygons are off screen anyway. To fix this, we do view frustrum culling on the mountains. To accomplish this, we first project the camera towards vector into the ground plane to determine which direction the camera is looking. Using the field of view of the camera, we then compute the edges of what the camera can see on the ground plane. These two points are used as the start and end point of the mountain range. We only render mountains in a line between these two points. We also compute the angle at which the camera is looking in order to determine which segment of the mountain range should be drawn. So as the camera rotates and translates, different parts of the mountain range are drawn.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A > Level of Detail Control </A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="high_detail.png"><IMG width=512 src="high_detail.png"></A><BR>
<A >High Level of Detail</A>
</TD>
<TD vAlign=top align=middle>
<A href="low_detail.png"><IMG width=512 src="low_detail.png"></A><BR>
<A >Low Level of Detail</A>
</TD>
</TR>
<TR>
<TD colspan=2>
Since the bobsled model has a large number of polygons, we decided to implement level of detail control on the bobsled model to help improve performance if the high resolution model is too slow. We have two bobsled models (although we have support for as many as desired) with differing levels of resolution. Both models are tracked during gameplay and the user can switch between the two at any time using the "=" key to increase polygon count and the "-" key to decrease polygon count.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A >Collision Detection</A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="rocks.png"><IMG width=512 src="rocks.png"></A><BR>
<A >Rocks</A>
</TD>
<TD vAlign=top align=middle>
<A href="snowballs.png"><IMG width=512 src="snowballs.png"></A><BR>
<A >Snowballs</A>
</TD>
</TR>
<TR>
<TD colspan=2>
There are two types of obstacles in our game - rocks and snowballs. Rocks are stationary on the floor of the track. If you hit rocks, your bobsled shakes violently side to side, and you will slow down. Snowballs are not stationary and fall from the sky. They fall vertically but their initial left-right position is determined by the left-right position of the bobsled when the snowball is created, so if you do not move sideways to avoid them, they will hit you. When a snowball hits your bobsled, you slow down. Collisions between obstacles and bobsleds are determined by bounding box intersections, in order to avoid calculating time-consuming intersections between meshes. Once snowballs have fallen through the track, they are deleted so that we no longer have to update their position, check for collisions with them, or consider rendering them.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A >Fog</A></H3>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top align=middle>
<A href="fog.png"><IMG width=512 src="fog.png"></A><BR>
<A >Lower Level of Fog</A>
</TD>
<TD vAlign=top align=middle>
<A href="fog_2.png"><IMG width=512 src="fog_2.png"></A><BR>
<A >Higher Level of Fog</A>
</TD>
</TR>
<TR>
<TD colspan=2>
Our game includes fog, which is implemented using GL_FOG (as described in our textbook). Each track segment is associated with a level of fog (where 0 indicates no fog). In our game, the fog fades in and then out again over several track segments.
</TD>
</TR>
</TBODY>
</TABLE>
<H3><A >Sound</A></H3>
<TABLE>
<TBODY>
<TR>
<TD >
We use OpenAL for sound effects. We also experimented with SDL for sound effects, but had trouble because SDL was creating its own OpenGL context. We initialize the required OpenAL data structures (device, context, listener, source and various buffers) when the game begins and start playing a song on loop. The song (Turn it on by Genesis) plays as long as the game is running. We also have a sound effect (a quote from the movie Cool Runnings, which inspired our game) that plays when the player dies (i.e. falls off the track).
</TD>
</TR>
</TBODY>
</TABLE>
<hr><br>
</BODY>
</HTML>