3D Graphics 1 Simulation Engines 2008 Chalmers University of - - PowerPoint PPT Presentation

08-11-17 Simulation Engines 2008, Markus Larsson 1

3D Graphics 1

Simulation Engines 2008 Chalmers University of Technology

Markus Larsson markus.larsson@slxgames.com

08-11-17 Simulation Engines 2008, Markus Larsson 2

3D Graphics

08-11-17 Simulation Engines 2008, Markus Larsson 3

Questions

?

08-11-17 Simulation Engines 2008, Markus Larsson 4

Once again...

 Real-time 3D graphics is all about triangles.  Properties of a renderable triangle.

 Vertices  Normals  Vertex order  (Tangents)  (Binormals/Bitangents)  (...)

 3D graphics is the art of coloring triangles.

08-11-17 Simulation Engines 2008, Markus Larsson 5

3D Graphics is also about...

 Vectors  Matrices  Quaternions  Loads and loads of mathematical operations on

the above.

 If you feel that you are shaky on vector algebra,

take a look in your old math books. You will thank yourself later.

08-11-17 Simulation Engines 2008, Markus Larsson 6

Categorization of 3D entities

 Static

 Objects that are immutable  Good candidates for extreme optimization

 Dynamic

 Moves or changes over time  Harder to optimize

 Animated

 Could be either static or dynamic  The vertex object can not be locked

08-11-17 Simulation Engines 2008, Markus Larsson 7

Spatial data structures

 Demands on real-time graphics grow rapidly.  Modern graphics hardware is:

 Fast  Programmable  Has plenty of memory

 However...

 ”The fastest polygon to render is the one never sent

down to the accelerator's pipeline.”

08-11-17 Simulation Engines 2008, Markus Larsson 8

Words of wisdom

"25k batches/s @ 100% 1GHz CPU" (i 60fps, 417 batches)

08-11-17 Simulation Engines 2008, Markus Larsson 9

Spatial data structures

 A spatial data structure:

 Orders geometric data by its location  Is often hierarchic, which allows O(log n) searches

and rapidly discarding irrelevant data.

 Spatial data structures can be expensive to

• construct. Construction is often preprocessed.

 Separate structures for static and dynamic data.

08-11-17 Simulation Engines 2008, Markus Larsson 10

Bounding volume hierarchies

 In general: better fit = more memory and more

expensive intersection algorithm.

 Axis-Aligned Bounding Boxes (AABB)

 The simplest type of bounding box.  Enclosed by a model's minimum and maximum

values along the x-, y- and z-axis.

 Ordinarily described by a center and the distance

from the center to the edge along each axis.

08-11-17 Simulation Engines 2008, Markus Larsson 11

Bounding volume hierarchies

 Oriented Bounding Boxes (OBB)  Similar to AABB's, but rotated to fit the model more

tightly.

 Ordinarily described by a center, three normalized

vectors and the distance from the center to the edges.

 Discrete Oriented Polytope (k-DOP)  Consists of k/2 normalized plane-normals associated

with two scalars. Together they describe the volume between the two planes:

 The k-DOP is the volume enclosed by all planes.

pii

min: ni⋅xdi min=0

pii

max: ni⋅xdi max=0

08-11-17 Simulation Engines 2008, Markus Larsson 12

Outdoor scenery

 Outdoor scenery is rarely represented in the

same fashion as indoor scenery

 The main problem is the scale of outdoor

scenery

 Outdoor scenery often needs special

considerations for optimization

 Continuous level of detail

08-11-17 Simulation Engines 2008, Markus Larsson 13

Heightfields

 The most common representation of a terrain  Generally stored in a grayscale 2D texture  Often divided into several smaller objects and

rendered as series of triangle strips

08-11-17 Simulation Engines 2008, Markus Larsson 14

Cracks in the terrain

 Beware of cracks in the terrain when rendering

with non-uniform tessellation

 Different levels of detail  Limited numerical accuracy in 3D card or API

 Can be avoided by drawing “skirts”  Multiple techniques for this...

08-11-17 Simulation Engines 2008, Markus Larsson 15

The ROAM algorithm



The Realtime Optimally Adapting Meshes algorithm was designed as a high-performance, flexible terrain rendering algorithm with continuous LOD



Uses a special data structure called a “triangle bintree” and two priority queues that drive the split and merge operations of patches in the height-field based on the location of the camera

08-11-17 Simulation Engines 2008, Markus Larsson 16

Trends in terrain rendering

 On modern hardware, algorithms like ROAM

use unnecessarily much CPU-power

 Fill rate and triangle-drawing capabilities on

modern 3D hardware are very good

 Nowadays, terrain rendering is mostly done by

grouping blocks of terrain patches into vertex buffer objects of just a few detail levels, and culled using only view frustum culling

08-11-17 Simulation Engines 2008, Markus Larsson 17

Volumetric terrain rendering

 Uses voxels (volume pixels)  Can be used with 3D scans  Can be used to render height-maps  Potentially very high resolution  Used in Comanche: Maximum overkill, 1992  No hardware support

08-11-17 Simulation Engines 2008, Markus Larsson 18

Skyboxes and skydomes



Used to render the background of 3D scenes

 Waste of resources to draw small background objects as meshes 

Drawn in the following way

 Clear depth and color buffers  Apply camera transformation  Disable the depth buffer test

and writes

 Draw the skybox or skydome  Enable depth buffer test and

writes

 Draw the rest of the scene

08-11-17 Simulation Engines 2008, Markus Larsson 19

Indoor scenery

 Data is organized in a very different manner

than for outdoor scenery

 Very different scales than for outdoor scenery  The existence of enclosing walls and ceilings

give excellent opportunities for culling

 Thanks to the smaller scale, requirements on

detail are much greater than outdoors

 Tim Sweeney estimates that we have a factor

• f 10.000 to 40.000 to go before we are able to

render photo-realistic indoor environments

08-11-17 Simulation Engines 2008, Markus Larsson 20

Uniform grids

 The world is split into uniformly

sized voxels (in 3D) or squares (in 2D).

 Very easy to implement.  Relatively efficient with ray-grid-

intersection tests, therefore often used for ray-tracing



http://www.cs.yorku.ca/~amana/research/grid.pdf

 Useful for dynamic data.

08-11-17 Simulation Engines 2008, Markus Larsson 21

Binary space partitioning trees

 Have been popular since they were used in

DOOM.

 Was originally designed to solve depth sorting

in the late 60's.

 Sorts geometry by splitting along planes.

 Axis-aligned

 Also known as KD-tree.  Ordinarily built by alternating the splitting axis.

 Polygon-aligned

 The most commonly used variant in games

08-11-17 Simulation Engines 2008, Markus Larsson 22

Quad trees

 Two-dimensional

representation.

 Similar to KD-trees, but

always split in the middle.

 Useful for representing

• utdoor environments which

are represented with height- maps.

08-11-17 Simulation Engines 2008, Markus Larsson 23

Octtrees

• Like quad trees, but in 3D.
• Efficient for large three-

dimensional spaces.

• Often have criteria for how

many children are needed in a voxel before splitting it as well as how many levels of hierarchy are allowed.

• Structures where the voxels do

not necessarily have the same size are called loose

• cttrees/quadtrees.

08-11-17 Simulation Engines 2008, Markus Larsson 24

Culling

 Culling is the act of removing polygons that do

not need to be rendered.

 Can be done by either the CPU or the GPU.  Culling on CPU generally saves bandwidth.  Culling on GPU (probably) saves CPU-time.  Modern hardware stores geometry in vertex

buffers, and encourages culling per object instead of per polygon, because that allows reusing of vertex buffer objects.

08-11-17 Simulation Engines 2008, Markus Larsson 25

Software vs. Hardware culling

GPU Viewport clipping Z-buffer testing Backface culling CPU View frustum culling Occlusion culling Backface culling

08-11-17 Simulation Engines 2008, Markus Larsson 26

Backface culling

 Ordinarily done in the

geometry stage of the

• pipeline. All data is sent to

the GPU, but only visible pixels are rasterized.

 A polygon is backfacing if

n·v < 0.

 The amount of rendered

triangles is normally reduced by 50%.

08-11-17 Simulation Engines 2008, Markus Larsson 27

View frustum culling

 Culls objects that are outside

• f the view frustum.

 The view frustum is volume

enclosed by six planes that is visible from the camera.

 Very efficient when used on a

hierarchic spatial data structure.

08-11-17 Simulation Engines 2008, Markus Larsson 28

Example: View frustum culling over an octtree

 The view frustum is represented by six planes

that point to the inside of the enclosed volume.

 Recurse over the following algorithm for voxels

in the octtree, beginning with the voxel that contains the entire tree:

 If the voxel is outside of any of the planes, do not

draw it.

 If the voxel is inside all of the planes, draw all of its

contents.

 If the voxel intersects any of the planes, perform

this test for all of its children.

08-11-17 Simulation Engines 2008, Markus Larsson 29

Occlusion culling

 Performed per pixel by the Z-buffer by the GPU.  View frustum culling does not discard objects

which are hidden behind other objects.

 With frustum culling and similar methods, data

structures overestimate the size of objects. With

• cclusion culling, silhouettes which

underestimate sizes are used.

 There are hardware extensions for occlusion

culling

08-11-17 Simulation Engines 2008, Markus Larsson 30

Portal culling

 A special case of occlusion culling.  Data is partitioned into rooms. Their

insides are only visible through portals (windows, doors, etc.).

 Frustum culling is recursively

performed on the volumes that are created between the camera and the portal.

 Ordinarily, engines use either portal- or

BSP-structures.

 Artist controlled.

08-11-17 Simulation Engines 2008, Markus Larsson 31

Antiportals

 Relatively modern technique.  Artist-controlled method of occlusion culling.  Antiportals are similar to portals, but instead of

revealing objects, data within the frustum between the camera and the antiportal is culled.

 Used by the Unreal Engine from UT2003 and

• nward.

08-11-17 Simulation Engines 2008, Markus Larsson 32

Level of detail

 LOD is based on the assumption that fewer

triangles are needed to visualize an object when it is further away from the camera.

 Two alternative ways:

 Static: several pre created alternative models are

used.

 Dynamic: a single model is altered in runtime.

 LOD is also applicable for materials.

08-11-17 Simulation Engines 2008, Markus Larsson 33

Static LOD

 One of several pre-created models is drawn

depending on the distance to it.

 Fast and simple but requires more memory and

more work with creating alternative models.

 Artifacts may arise when switching models. This

can be solved by blending between the models (preferably in a vertex program on the GPU).

 Be careful not to be counterproductive Too

many levels or distance functions may result in even more data being sent to the GPU.

08-11-17 Simulation Engines 2008, Markus Larsson 34

Dynamic LOD

 Less ”popping” than with LOD, but likely creates models

that look worse than those created by artists.

 Uses more CPU-time than static LOD.  Two popular methods:  Continuous Level of Detail (CLOD): Removes the edge

between two triangles when its two vertices are close to each other.

 Geomorph Level of Detail: Builds on CLOD, but

interpolates intermediate positions for corners before merging.

08-11-17 Simulation Engines 2008, Markus Larsson 35

Static objects

 Static objects in 3D have immutable geometry

and are only subject to affine transformations

 Possible optimizations

 Storage

 Since the geometry never changes, we only need one

copy of each object, even if we have multiple instances of it in our scene

 Rendering

 The static nature of the geometry allows for rendering

• ptimizations such as display lists and vertex arrays and

buffers

08-11-17 Simulation Engines 2008, Markus Larsson 36

Vertex arrays/objects/buffers

 The traditional OpenGL way of rendering consist of a

lot of glBegin, glEnd, glVertex, glNormal, etc.

 Unnecessary work  OpenGL introduced vertex arrays  Vertex buffers in Direct3D  Specifies a block of vertices for reuse  Thanks to hardware T&L and locking the vertex

array, the 3D card can perform most of this work without CPU intervention

 OpenGL uses VBOs nowadays

08-11-17 Simulation Engines 2008, Markus Larsson 37

Characters



Characters tend to be subject to vertex animation

 Vertex arrays can not be locked 

Often animated with use of skeletal animation

 Can be done almost entirely in

hardware, which allows for locked arrays



Morph targets

 Harder to do in hardware, but

• ptimizations can be done

08-11-17 Simulation Engines 2008, Markus Larsson 38

Data structures in Ogre



Ogre allows you to choose between multiple Scene Managers which use different data structures.

 Octtree  Terrain: Uses an octtree for objects and a grid for the

terrain.

 Nature Scene Manager (ogreaddons)  Paging Scene Manager (ogreaddons)  BSP Scene Manager: Certain legal problems.  Dot Scene Manager (ogreaddons): Recommended

instead of BSP in the documentation. Uses an

• cttree.

08-11-17 Simulation Engines 2008, Markus Larsson 39

Culling in Ogre



A few quotes from the forum:

 ”The scene manager culling method. This is customised

based on the scene manager being used; for example the BSP manager culls based on bsp leaves, the octree manager culls based on an octree etc. Normally these managers cull at a high level though, bounding boxes typically.”

 ”Frustum culling. Once the scene manager has identified

potentially visible chunks, a basic frustum cull is done based on the bounding box.”

 ”GPU culling. The GPU will eliminate backface triangles

(unless you change the culling mode in the .material) and

• ffscreen triangles will be discarded during primitive

assembly.”

08-11-17 Simulation Engines 2008, Markus Larsson 40

Ogre tips

 Read about the Ogre scene managers at:

http://www.ogre3d.org/wiki/index.php/SceneManagersFAQ

 Read about terrains in Ogre at:

http://www.ogre3d.org/wiki/index.php/TerrainHowto

 Siggraph papers can be read for free from Chalmers

computers at: http://portal.acm.org/portal.cfm

 Google-equivalent:

http://scholar.google.se/