Computer Graphics Engine

2. Computer Graphics Engine • Daniel Richards • Richard Garcia • Leah Beal • Paul Cassatt • Mohammad Jehangiri

3. Original Design • Designed by Dr. Sinzinger • Used in 3D-Game Class • Written in C++ • Utilizes OpenGL, ANTLR, & SDL

4. Assigned Upgrades • BSP Trees • Visual Surface Determination • Texture Mapping • HUD • Collision Detection

6. BSP Trees • Back Culling • Design • Determine a single face in the list of faces • Determine all the faces on positive and negative side of the chosen face • Add coplanar faces to the current BSP node • Recurse steps 1-3 for the positive and negative face list

7. Visual Surface Determination • Implemented through BSP trees • Design • Determine the view frustrum • Recurse through the tree and determine the faces within the view frustrum

8. Texture Mapping • Virtually already coded, but not yet implemented or fully tested

9. Texture Mapping Cont. • We used a “floor” and “advertisement” texture from CS 4397 (ARCH 5352)

10. Texture Mapping Cont. • We then modified the VRML file to make the URL’s respective to the new texture images • Example from texture.wrl (floor texture located in graphics directory relative to the rendering executable):appearance Appearance { material Material { diffuseColor 0.5882 0.5882 0.5882 ambientIntensity 1.0 specularColor 0 0 0 shininess 0.145 transparency 0 } texture ImageTexture { url "graphics/floor.jpg" } }

11. Texture Mapping Cont. • To load the textured testing model, we added the following to the CS 4397 gameloop.cpp: CModel building("graphics/texture.wrl"); … building.initialize(); … building.openglRender(); • We also used another VRML file to test extensive references to the same texture.

12. Texture Mapping Results • We did thorough testing with multiple textures, as well as textures in various places and multiple references to the same texture in a file • We also tested the textures with Z-Buffering, BSP Trees, and VSD • All had tested successfully, though there were conflicts with BSP Trees at first

13. HUD Implementation • Display class supports three basic HUD types: • TIFF files with Alpha Transparency • BMP files with masking files • Raster text • Declared as follows:Display idenifier(type<DISPLAY_TIFF,DISPLAY_BMP,DISPLAY_TEXT>, x_position, y_position); • Initialized as follows: • TIFF’s: identifier.initialize(file_path); • BMP’s: identifier.initialize(file_path, mask_path); • Text: identifier.initialize(string_to_display);

14. HUD glRender Implementation • Rendered after the models with:identifier.glRender(); • HUD generally rendered as follows: • Push the 3D model and projection onto the stack • Change the projection to Ortho2D • Render HUD or text • Pop the 3D model and projection • Each type of HUD is rendered in a different manner.

15. HUD glRender Cont. • Text is rendered as follows:base = glGenLists(256); for(ch=0; ch<256; ch++){ glNewList(base+ch,GL_COMPILE); glutBitmapCharacter(GLUT_BITMAP_8_BY_13,ch); glEndList(); } glRasterPos2f(x_position,y_position); glListBase(base); glCallLists((GLint) strlen(string_to_display), GL_BYTE, string_to_display);

16. HUD glRender Cont. • BMP’s rendered using a masking image • glBlendFunc(GL_DST_COLOR,GL_ZERO); called before mapping the mask image • glBlendFunc(GL_ONE, GL_ONE); called before mapping the color image • Partial transparency implemented with grayscale pixels in the mask • Each image is mapped as follows: glBindTexture(GL_TEXTURE_2D, textureId); glBegin(GL_QUADS); glTexCoord2f(0.0f, 0.0f); glVertex2f(0.0,0.0); // Bottom Left glTexCoord2f(1.0f, 0.0f); glVertex2f(1.0,0.0); // Bottom Right glTexCoord2f(1.0f, 1.0f); glVertex2f(1.0,1.0); // Top Right glTexCoord2f(0.0f, 1.0f); glVertex2f(0.0,1.0); // Top Left glEnd();

17. HUD glRender Cont. • TIFF’s are rendered in similar way as BMP’s • No masking image necessary due to an inherent Alpha channel • Requires libtiff, libjpeg, and zlib libraries and support files to load the image • Once loaded into memory, the final mapping is the same as with BMP’s

18. HUD Testing and Results • BMP’s tested successfully with the current state of the engine • Text tested successfully in a standalone environment with projected success in engine • TIFF’s have loaded successfully, but have failed to blend correctly with the underlying projection, likely due to an incorrect blending function in the rendering code

19. More Texture/HUD References • Molofee, Jeff. “NeHe Productions Masking Tutorial”. http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=20. December 4th, 2002 • Opengl.org. “Using Sam Leffler's libtiff with OpenGL and GLUT”. http://www.opengl.org/developers/code/mjktips/libtiff/. April 10th, 2003 • Libtiff.org. “TIFF Software”. http://www.libtiff.org. April 10th, 2003

20. Collision Detection using BSP Trees • One of the most critical problems when creating a BSP-tree based 3D-engine is collision detection. It is not difficult to solve the collision problem, but, it is difficult to perform with great speed. • In most games, the processor time is consumed by performing the necessary collision detection algorithms. • BSP trees are efficient for geometry culling, we also get very efficient world-object collision almost for free. • This approach is powerful because it rejects a lot of geometry early, so in the end, we only test the collision detection against a small number of planes. (give an example)

21. Collision Detection Cont. • The easiest way to perform this check is to test whether all parts of the object are on the same side of the plane. • We can use the Cartesian plane equation, ax + by + cz + d = 0, to determine the side of the plane upon which the point lies. If the equation is satisfied, then our point lies on the plane. If ax + by + cz + d > 0, then the point is on the positive side the plane. If ax + by + cz + d < 0, then the point is on the negative side the plane. • So the collision detection algorithm is required to operate at great speed and accuracy. • The problem becomes much more complex when several objects and players interact during the time interval for each real time rendering of the frame.

22. Results • Integration problems. • Speed accuracy.

23. The End