1 / 36

Announcements

Announcements. We’re moving to CIT 506 next week permanently yo Always email the cs195utas@cs.brown.edu alias rather than one of us directly for anything course-related Better for TAs (know what’s going on, can discuss before responding) Better for you (faster response time)

erol
Download Presentation

Announcements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Announcements • We’re moving to CIT 506 next week permanently yo • Always email the cs195utas@cs.brown.edu alias rather than one of us directly for anything course-related • Better for TAs (know what’s going on, can discuss before responding) • Better for you (faster response time) • Exception: grade questions • BGD meeting Saturday 3:30 PM in CIT 345 • Test your handins on department machines! • If you didn’t have to do LIBS += -lGLU in your .pro file and #include <GL/glu.h> to use GLU, you used the wrong Qt version • Windows doesn’t have case sensitive filenames, Linux does • #include <GL/glu.h>, NOT #include <GL/GLU.h>, NOT #include <gl/glu.h>

  2. Lecture 1 Not the U.N.! Spatial Organization Warmup Weeklies Tips for Minecraft 1 World Representation

  3. Ideal 3D game environment • Easy to generate • Algorithm/world-editing tools • Dynamic • Easy, inexpensive to modify • Accurate collision detection • Beautiful, high detail • Inexpensive to render • Compact representation • Faster to load from disk or network • AI can easily navigate all areas

  4. The harsh reality • Tradeoffs between detail and object count • Choices depend on platform, game mechanics • Much higher detail where player is likely to focus • Examples • Car models vs. background trees in racing games • Dynamic MMO worlds do not have compact representations

  5. World representation • Design goals determine the best representation to use • Easy to generate • Some data structures better for algorithms/editors than others • Dynamic • How much rebuilding must be done when the world is modified? • Accurate collision detection • Optimize for fewer, more detailed models vs. many low detail models • Compact representation • Space vs. time tradeoff

  6. Basic world representation • Polygon soup • Most basic representation • Unordered collection of polygons (no connectivity/hierarchy) • Easy to generate • Difficult for collision detection (hard to tell where solid objects are) • Polygon mesh • Polygons share vertices • Ensures closed mesh • Good for representing world • Not good for game objects (usually need simpler representation)

  7. Lecture 1 Octreerific! Spatial Organization Warmup Weeklies Tips for Minecraft 1 World Representation

  8. Spatial organization • Standard collision detection is O(n2) • Too slow for large game worlds • Solution: spatially organize to discard far-away data • Other game objects • Pieces of static geometry • Many approaches • Bounding volumes • Bounding volume hierarchy • Uniform grid • Hierarchical grid • kd tree • Portal-based environment

  9. Bounding volumes • Wrap objects in simple geometry (bounding volumes) to speed up collisions • If objects are far apart, their bounding volumes won’t collide, and the detailed test is not needed • Doesn’t solve O(n2) runtime alone

  10. Bounding volume hierarchy (BVH) • Parent volumes contain child volumes • Sibling volumes may overlap (not spatial partitioning) • Speeds up collisions between dynamic entities • Also speeds up rendering

  11. Uniform grid • Speeds up collisions between dynamic entities • Axis-aligned cube cells (voxels) • Each cell has list of objects • May be dense (array) or sparse (hash-based) • Each frame: update cells for objects that moved

  12. Uniform grid • Pros • Simple to generate and modify • Good for static and dynamic objects • O(1) access to neighbors • Cons • Not appropriate for objects of greatly varying sizes • Dense representation wastes memory in empty regions

  13. Hierarchical grid • Hierarchy of differently-sized uniform grids • N levels, cells at top level are big enough to cover bounding box of largest game object • Each sub-level’s cells are half the scale • Inserting objects • Find the level where cells are big enough to fit it fully • In that level, insert into the cell that contains its center • 1D example on right A B C D E F

  14. Hierarchical grid queries • Traverse over all levels • Test cells containing object’s bounding box and neighboring cells • 1D example: colliding object E A B C D E F

  15. kd tree • Generalization of octree • Partitions are different sizes • Pros: • More balanced if constructed properly • Cons • More complex both in implementation and use

  16. Portal-based environment • Models empty space, carves world up into non-overlapping convex polyhedra • Shared faces between two polyhedra are “portals” • Appropriate for indoor environments • The key: no obstruction from any point to any other point inside a polyhedron Room with portals marked Convex polyhedra

  17. Portal ray traversal method • Start in one polyhedron • Trace ray to face • If solid, stop • If portal, continue in neighbor 5 4 3 2 1

  18. Dynamic visibility set w/portals • Determine set of objects visible from within each polyhedron on the fly • Recursively clip against portal bounds

  19. Portal-based rendering example • Draw room 1 • Contains player • Draw room 2 • Seen from portal 1 • Draw room 3 • Seen from portal 2 • Don’t draw room 4 • Not seen from portal 3 Player 1 2 4 3 View frustum

  20. Portal pros and cons • Pros • Easy collision detection and raytracing • Can be used for dynamic objects • Portals can point to non-adjacent polyhedra • Mirrors, teleportation, changes in size • Cons • Implementation is complex • Hardware can do visible surface determination better now • Hierarchical z-buffer occlusion culling

  21. Case study: Descent engine • One of the first actually 3D games • Fly with 6 degrees of freedom through tight hallways • Used deformed cubes as polyhedra • Easy to edit, manipulate empty space directly • Portal-based render led to super-efficient software rendering

  22. Lecture 1 Minecraft-tastic! Spatial Organization Warmup Weeklies Tips for Minecraft 1 World Representation

  23. Overview • First major project, three checkpoints • Week 1 • Build a world with textures and terrain • Week 2 • Make rendering more efficient and scalable • Add a player with collision detection and response • Week 3 • Add simplistic enemies • Also ability to add and remove blocks • Stream in chunks as the player moves • Beyond… • Play your own version of Minecraft!

  24. Minecraft world format • Two-layer hierarchical grid • 1x1x1 blocks grouped into chunks • Class project: 32x32x32-block chunks • The real game: 32x128x32-block chunks • Huge number of blocks, memory usage is problematic • Each block holds one byte specifying its type • Determine textures, transparency, etc. from type • Original game uses a second byte for lighting data

  25. Minecraft world representation • Each chunk should contain a 32x32x32 array of blocks • Fastest lookup, contiguous memory • Will be “easier” to convert to VBOs next week • Chunks can be stored in a dynamic data structure • Will need to move chunks around in week 3

  26. Terrain generation • Noise function mapping 2D point in plane to terrain height • Why is rand() a bad idea? • Terrain will be too noisy; completely disjoint • Octave noise: sum layers of interpolated noise at different scales • For true 3D noise (overhangs, caves, etc.), just use a 3D noise function

  27. Perlin noise • Popular octave noise generation method • Can be easily extended to 2D, 3D, 4D, etc • http://freespace.virgin.net/hugo.elias/models/m_perlin.htm

  28. Noise function • The noise function should be deterministic • Value of noise at a coordinate should always be the same • Example: noise(int x){ x = (x << 13) ^ x; return 1.0 – ( (x*(x*x*15731 + 789221) + 1376312589) & 7fffffff )/1073728932.0; } • You can find other primes online to replace some of these numbers

  29. Smoothed noise • Interpolate between neighboring noise points smoothed_noise(int x){ return noise(x)/2 + noise(x – 1)/4 + noise(x + 1)/4; }

  30. Interpolated smooth noise • Interpolate between smoothed integer noise points interp_noise(float x){ v1 = smoothed_noise(int(x)); v2 = smoothed_noise(int(x) + 1); return interp(v1, v2, x – int(x)); } • interp() is an interpolation function of your choice

  31. Putting it together • Sum up interpolated smoothed noise of different scales perlin(float x){ total = 0; for i=0:octaves freq = 2^i; amp = persistence^i; total += interp_noise(x*freq)*amp; } • persistencecontrols how rough the terrain is

  32. Rendering • Only draw faces that neighbor an empty cell • Use a glBegin()/glEnd() block to draw the faces as textured quads • Like last week • Rendering will still be slow with lots of blocks • Next week, you will learn how to make the rendering much faster with VBOs!

  33. C++ tip of the week • Struct alignment • On a 32-bit machine, a Foo instance will occupy 12 bytes • By default, struct data members are word-aligned • Reading/writing aligned memory is faster • What if we want to reduce memory usage? structFoo { char m1; char m2; short m3; };

  34. C++ tip of the week • C++ compilers allow you to pack structs • Useful for network buffers and large data sets • We strongly recommend using this for your Minecraft chunk structure // gcc structFoo { ... } __attribute__((packed)); // msvc #pragma pack(push, 1) structFoo { ... }; #pragma pack(pop)

  35. Lecture 1 So much excitement! Spatial Organization Warmup Weeklies Tips for Minecraft 1 World Representation

  36. Examples of things you can talk about • YOUR NAME • Anything extra you did on top of requirements • Any interesting choices or design decisions you made • Any unusual problems you encountered • Bugs that you can’t seem to track down

More Related