330 likes | 447 Views
Computergraphik 2 & 3 LU 1. Repetitorium. http://www.cg.tuwien.ac.at/courses/CG23/LU.html. Smart Pointers. 2 ways to create objects in C++ int myVar(5); // same as: int myVar = 5; int* myVar = new int(5); objects created with new must be delete d! delete myVar;
E N D
Computergraphik 2 & 3 LU1. Repetitorium http://www.cg.tuwien.ac.at/courses/CG23/LU.html
Smart Pointers • 2 ways to create objects in C++ • int myVar(5); // same as: int myVar = 5; • int* myVar = new int(5); • objects created with new must be deleted! • delete myVar; • problem: what part of the code is responsible for deleting objects? - solution: smart pointers • www.boost.org/libs/smart_ptr/smart_ptr.htm • ...or roll your own: • Handle<int> myVar = new int(5);
Handle<> Template Class • in handle.h template<class T> class Handle { T* pointer; int* count; public: Handle(T* t) : pointer(t), count(new int(1)) {} Handle(const Handle& copy) : pointer(copy.pointer), count(copy.count) { ++*count; } //...
Handle<> Template Class • to access the handled object‘s members T& operator*() const { if (pointer) return *pointer; throw runtime_error("unbound Handle"); } T* operator->() const { if (pointer) return pointer; throw runtime_error("unbound Handle"); } //...
Handle<> Template Class • even more operator overloading Handle<T>& operator=(const Handle& assign) { ++*assign.count; if (--*count == 0) { delete count; delete pointer; } count = assign.count; pointer = assign.pointer; return *this; } //...
Handle<> Template Class • we‘re almost done... operator bool() const { return pointer; } ~Handle() { if (--*count == 0) { delete count; delete pointer; } } } // class Handle
STL • the STL (standard template library) provides: • a string class (std::string) • container templates: • linked lists (std::list) • resizable arrays (std::vector) • maps (std::map) • hash tables (stdext::hash_map in VS.net 2003) • docs: http://www.sgi.com/tech/stl/
Using the STL • keeping track of game entities typedef std::vector<Handle<Entity> > entityVec; entityVec weapons; // ... we add a new gun to the container Handle<Entity> gun = new Railgun; weapons.push_back(gun); // ... at some point we may want to render the weapons for (entityVec::iterator iter = weapons.begin(); iter < weapons.end(); ++iter) (*iter)->render();
OpenGL Extensions • on Windows: • to access features of OpenGL >1.1 • to access vendor specific features • to access very new features • OpenGL Extension Registry • http://oss.sgi.com/projects/ogl-sample/registry/ • description of functions and how to use them
OpenGL Extensions: GLEW • OpenGL Extension Wrangler Library • http://glew.sourceforge.net/ #include <GL/glew.h> #include <GL/glut.h> // initialization glutInit(&argc, argv); glutCreateWindow("GLEW Test"); GLenum err = glewInit(); if (err != GLEW_OK) { cerr << "GLEW Error: " << glewGetErrorString(err); exit(1); }
OpenGL Extensions: GLEW • usage: if (GLEW_ARB_vertex_program) { // it is safe to use the ARB_vertex_program here glGenProgramsARB(...); } // checking with strings if (glewIsSupported("GL_VERSION_1_4 GL_ARB_point_sprite")) { // great, we have OpenGL 1.4 + point sprites }
Querying OpenGL Errors • at least once after each iteration of the game loop: GLenum err = glGetError(); if (err != GL_NO_ERROR) cerr << "GL Error: " << gluErrorString(err) << endl;
Querying OpenGL Errors • querying the GLSL info log: GLint logLength; glGetObjectParameterivARB(programObject, GL_OBJECT_INFO_LOG_LENGTH_ARB, &logLength); if (logLength > 1) { GLcharARB* logString = new GLcharARB[logLength]; glGetInfoLogARB(programObject, logLength, NULL, logString); cout << "GLSL Info: " << logString << endl; delete[] logString; }
Low-Level Data Structures • Vector class to ease the use of cross product, dot-product... • Matrix class to simplify matrix-matrix multiplications, matrix-vector multiplications, matrix inversions... • Plane/Line class for • Intersection/distance • Ray casting
Low-Level Data Structures • Bounding spheres/boxes • Faster collision and visibility calculations • Axis aligned bounding box • Oriented bounding box • Frustum class for view-frustum calculations • List/stack of bounding planes • View-frustum culling • Portals
Basic Rendering • View-frustum culling • What we do not see, we do not render. • Test Bounding Volume of each object against view-frustum. • Make it hierarchical for faster execution
Basic Rendering • Backface culling • Removes half the triangles • Done by HW glEnable(GL_CULL_FACE)..
Basic Rendering • Simple „scene graph“ - a list of objects • For each object do view-frustum culling with its bounding volume • If visible render it • Set state (activate texture, transformation, color...) • Draw geometry • Make it hierarchical • From list to bounding volume tree • From list to state tree
Camera • Position • Orientation, some possibilities: • Store angles around different axes • Incremental multiplication (e.g. each frame) • Depends on the game type and the DOF needed • Transformations: Treat cameras like objects!
Collision Detection • The best tests are those never executed! • Depends on the scenario / game genre • General: • Broadphase: Bounding Volumes, spatial coherence, sweep-and-prune • Narrowphase: Bounding Volume Hierarchies, Polyhedra, Triangles • Depending on game type: • Bounding sphere / AABB / OBB often will suffice
Collision Detection - 2 • Different types: • Spheres (simple; efficient testing; not very accurate) • Axis-aligned Bounding Boxes (simple; efficient testing, but slower than spheres) • Oriented Bounding Boxes (very accurate; construction is a non-trivial task for complex objects) • Bounding Volume Hierarchies: • A parent contains/bounds his leaves • Each leave bounds a primitive
Collision Detection - 3 If Bounding Volumes collide: • One step down the hierarchy • E.g. triangle vs. triangle • Depends on the scene / game type • http://www.realtimerendering.com/int/ • Contains about every intersection-routine ever developed ;) • 2. Hand-In: Bounding Volume tests sufficient
Terrain Rendering - 1 • Regular Grids • use triangle strips! • Height Maps • color encodes height at (x, y) • Space Partitioning • Each block 1 efficient triangle strip • Geometry splitting along block borders
Terrain Rendering - 2 • Advanced Techniques • Occlusion Culling • Levels of Detail (adapt complexity dynamically) • But: efficient preparation for hardware more important than LOD! • Heightmaps • Draw manually • Use tools (Terragen) • Generate (fractals/midpoint displacement, …)
Space Partitioning - 1 • Needed for various culling/visibility techniques • Reduces amount of calculations needed • Quadtrees, Octrees, BSP Trees, … • Beware of memory requirements • Balance tree height VS geometry per partition (empirically) • View Frustum Culling • Fast approach with false positives better than slower, accurate approach (for games) • Make use of hierarchical data structure!
Space Partitioning - 2 • Traverse Tree (DFS) • Discard blocks as big as possible as soon as possible, example: • A visible • A1, A2, A3, A4 visible • B invisible • C visible • C1 invisible • C2 visible • C3, C4 invisible • D invisible • → render A1, A2, A3, A4, C2
Efficient OpenGL - Geometry • Use OpenGL vertex arrays for • Normals • Texture-coordinates • Vertex-coordinates • Use indexed geometry • Saves memory (re-use of vertices) • Index-array: provide it when calling glDrawElements(…) or bind it before when using vertex buffer objects
Efficient OpenGL – Geometry 2 • Indexed Geometry • Not always best/applicable(e.g. cube: no shared vertices!) • Good for highly tessellated, curved surfaces (e.g. cylinder) • Shared vertices also have to share • Normals • Texture-coordinates • Color
Efficient OpenGL – Geometry 3 • Today’s hardware: • able to transform up to 100 million triangles per second • One million triangles per frame at 100 fps! • Special requirements: • Complex objects(many triangles per render-call) • Appropriate conditioned objects(triangle strips, many shared vertices) • Use of extensions(avoids unnecessary copy operations, …)
Efficient OpenGL – Extensions • Some useful extensions: • GL_ARB_vertex_buffer_object • GL_SGIS_generate_mipmap (OpenGL 1.4) • GL_ARB_texture_compression • Vertex Buffer Objects • Allows for storing vertex data in video memory • Further information (strongly recommended!): • http://developer.nvidia.com/object/using_VBOs.html • http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
Efficient OpenGL – Extensions • SGI Mipmapping • Uses hardware to generate mipmaps automatically • Faster than gluBuild2DMipmaps(…) • Further information: • http://developer.nvidia.com/object/gdc2001_automatic_mipmap.html • http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt
Efficient OpenGL – Extensions • Texture compression • Reduces traffic on memory bus • Decreases load-time when stored compressed on hard-disk • Further information: • http://developer.nvidia.com/object/texture_compression_OpenGL.html • http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt