CS 450: COMPUTER GRAPHICS REVIEW: INTRODUCTION TO COMPUTER GRAPHICS – PART 2 SPRING 2015 DR. MICHAEL J. REALE

DEFINITIONS Graphics Rendering Pipeline Generates (or renders) a 2D image given a 3D scene AKA the “pipeline” A 3D scene contains: A virtual camera 3D Objects Light sources Textures/Materials Etc. GPU = graphics processing unit (i.e., your graphics card) We’ve got this… …and we want this

PIPELINE STAGES The Graphics Rendering Pipeline can be divided into 3 broad stages: Application Completely controlled by programmer Runs on CPU Must send geometry to next stage Geometry – rendering primitives, like points, lines, triangles, polygons, etc. Geometry Performs majority of per-polygon and per-vertex operations (like transformations, projections, etc.) Typically runs on GPU (used to run on CPU) Must send transformed and projected vertices to next stage Also sends other per-vertex information, like color and normals Rasterizer Renders final image and performs per-pixel computations (if desired) Runs on GPU Each of these stages can also be pipelines themselves

PIPELINE SPEEDS Like any pipeline, only runs as fast as slowest stage Slowest stage (bottleneck)  determines rendering speed Rendering speed usually expressed in: Frames per second (fps) Hertz (1/seconds) Rendering speed  called throughput in other pipeline contexts

DEFINING 3D OBJECTS Vertex = point Most basic geometric primitives: Points (1 vertex) Lines(2 vertices) Triangles(3 vertices) MOST of the time, an object/model is defined as a triangle mesh

DEFINING 3D OBJECTS Why triangles? Simple Fits in single plane Can define any polygon in terms of triangles At minimum, a triangle mesh includes: Vertex positions (x,y,z) Face definitions (for each triangle, list of vertex indices)

DEFINING 3D OBJECTS Other geometric primitives: Polygons Circles, ellipses, and other curves Splines Sphere 3D “primitives”: Cube Sphere Torus Cylinder Cone Utah or Newell teapot

RIGHT-HAND RULE OpenGL (and other systems) use the right-hand rule Point right hand toward X, with palm up towards Y  thumb points toward Z

GEOMETRY STAGE Model and View Transform Model coordinates (relative to model)  MODEL TRANSFORM  World coordinates Instance = copy of original model with its own model transform World coordinates  VIEW TRANSFORM  Camera (Eye) Coordinates Virtual camera now starts at (0,0,0) looking down NEGATIVE Z axis X = right, Y = up Vertex Shading = shading calculations using vertex information; programmable Shading – determining the effect of a light (or lights) on a material

GEOMETRY STAGE Projection = transforms view volume into a unit cube  (-1,-1,-1) to (1,1,1) in OpenGL View volume – area inside camera’s view that contains the objects we must render World Coordinates  PROJECTION  normalized device coordinates (x,y,z) Simplifies clipping later Two most common projections: Orthographic (or parallel) View volume = rectangular box Parallel lines remain parallel Perspective View volume = truncated pyramid with rectangular base  called view frustum Things look smaller when farther away

GEOMETRY STAGE Clipping Completely inside  draw Completely outside  don’t draw Partially inside  clip against view volume and only draw part inside view volume  adds new vertices Screen Mapping = map to display window (x,y) of normalized device coordinates  SCREEN MAPPING  (x’, y’) screen coordinates (also device coordinates) z coordinates unchanged (x’,y’,z) = window coordinates = screen coordinates + z Window coordinates passed to rasterizer stage Origin = lower-left corner in OpenGL Center of pixel (0,0) = (0.5, 0.5) in OpenGL

RASTERIZER STAGE Primary goal  rasterization (or scan conversion) Computing and setting colors for pixels covered by the objects Convert 2D vertices + z value + shading info  pixels on screen Has four basic stages: Triangle setup Triangle traversal Finds which samples/pixels are inside each triangle Generates a fragment for each part of a pixel covered by a triangle Fragment properties  interpolated from triangle vertices Pixel shading = per-pixel shading calculations Outputs one or more colors per pixel (one for each fragment) Programmable Merging = combine each fragment color with color current stored in color buffer Color buffer  stores color for each pixel Uses Z-buffer to determine fragment visibility

FRAGMENT DEFINITION Fragment = data necessary to shade/color a pixel due to a primitive covering or partially covering that pixel Data can include color, depth, texture coordinates, normal, etc. Values are interpolated from primitive’s vertices Can have multiple fragments per pixel Final pixel color will either be one of the fragments (i.e., z-buffer chooses nearest one) or combination of fragments (e.g., alpha blending)

RASTERIZER STAGE: MERGING AND Z- BUFFER Z-buffer algorithm Check z value of incoming fragment If closer to camera than previous value in Z-buffer  override color in color buffer and update z value Advantages: O(n)  n = number of primitives Simple Can draw OPAQUE objects in any order Disadvantages: Transparent objects more complicated

RASTERIZER STAGE: MERGING AND BUFFERS Frame buffer Means all buffers on system (but sometimes just refers to color + Z-buffer) To prevent the user from seeing the buffer while it’s being updated  use double-buffering Two buffers, one visible and one invisible Draw on invisible buffer  swap buffers

FIXED-FUNCTION VS. PROGRAMMABLE Fixed-function pipeline stages Elements are set up in hardware a specify way Usually can only turn things on or off or change options (defined by hardware and graphics API) Programmable pipeline stages Vertex shading and pixel (fragment) shading Have direct control over what is done at given stage

DEFINITIONS Computer-graphics application programming interfaces (CG API) Common CG APIs: GL, OpenGL, DirectX, VRML, Java 2D, Java 3D, etc. Interface between programming language and hardware

GL AND OPENGL GL (Graphics Library) Developed by Silicon Graphics, Inc. (SGI) for their graphics workstations Became de facto graphics standard Fast, real-time rendering Proprietary system OpenGL Developed as hardware-independent version of GL in 1990’s Specification Now maintained by Khronos Group Designed for efficient 3D rendering, but also handles 2D (just set z = 0) Stable; new features added as extensions SGI O2 workstation: