1 / 36

Announcements

Announcements. Public playtesting starts this week! Look at the following 195n lecture for tips regarding good public playtesting : http ://cs.brown.edu/courses/cs195n/.archive/2012/lectures/10.pdf#page=34. Lecture 11. Particles. Will it blend?!. C++ Tip of the Week. Playtesting.

mave
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 • Public playtesting starts this week! • Look at the following 195n lecture for tips regarding good public playtesting:http://cs.brown.edu/courses/cs195n/.archive/2012/lectures/10.pdf#page=34

  2. Lecture 11 Particles Will it blend?! C++ Tip of the Week Playtesting Particles Advanced Graphics Advanced Graphics

  3. Modern Graphics • Today is a high-level survey of techniques • Focus: detail from shaders • Not detail from geometry, computation power increasing faster than fill rate • Old multipass algorithms make more sense now as a single pass • Modern techniques • Screen-space computation • Reuse other parts of the scene • Hybrid raytracing and rasterization • Best of both worlds

  4. Forward Shading • Forward Shading • Traditional rendering method • Discover any light interactions with every model • Render the model by looping over each light in the pixel shader • Problems • A light touching a small part of a model makes rendering the entire model more expensive • Light interactions potentially become O(n2), causing uneven performance

  5. Deferred Shading • Idea: decouple lighting and geometry • Render scene once into multiple buffers • Per pixel material, normal, depth, ... • Collectively called the G-buffer • Can render to multiple render targets at once with modern GPUs Material color Depth Surface normal

  6. Deferred Shading • Layer lighting onto scene by rendering light shapes (i.e. sphere for point light) • Each light only rendered to relevant pixels • Can recover 3D position from depth and pixel coordinate • Use additive blending Final render

  7. Deferred Shading • Benefits • Scales much better to large numbers of lights • Screen-space effects give consistent performance • Problems • Cannot handle transparency (G-buffer can only store information about one pixel) • Scenes with many material parameters need large G-buffers, memory bandwidth suffers • Cannot be used with hardware anti-aliasing, although modern post-processing edge-smoothing techniques help (MLAA)

  8. Volumetric Effects • Volumetric glow (fake scattering)

  9. Volumetric Effects • Volumetric glow (fake scattering) • Blend glow color over every pixel • Fade off using closest distance from light source to line segment starting from eye and ending at object under pixel • Requires deferred shading for position of object • Rendering to entire screen is expensive • Fade off to zero at some radius • Only need to draw pixels within that radius in world space, will be cheap for a far away effect

  10. Volumetric Effects • Real Time volumetric shadows • "Real Time Volumetric Shadows using Polygonal Light Volumes" (Billeter, Sintorn, Assarsson)

  11. Volumetric Effects • Real Time volumetric shadows • Measure shadow thickness using polygons enclosing shadow volumes • Render shadow on top of scene using shadow thickness map Shadow volume View ray Shadow volume

  12. Volumetric Effects • Real Time volumetric shadows • Need two floating-point render buffers, one for front faces and one for back faces • Abuse additive blending mode to compute thickness • Render depth of front volume faces to first buffer • Render depth of back volume faces to second buffer • Thickness is second buffer minus first buffer First buffer: d1 + d3 Second buffer: d2 + d4 Thickness: (d2 + d4) - (d1 - d3) d1 d2 View ray d3 d4

  13. Shadow Mapping • Need to test whether a pixel is in shadow • Render scene from light's point of view • Depth map stores closest point to light • Render the scene from the camera, projecting each point back into the light's view frustum • Shadow if depth of projected point > depth map

  14. Cascaded Shadow Maps • Shadow mapping has problems • Resolution varies across scene • One shadow map per object doesn't scale • Idea: fit several shadow maps to camera • Want uniform shadow map density in screen-space • Objects near eye require higher world-space density than objects far away • Use a cascade of 4 or 5 shadow maps • Each one is for a certain depth range of the scene • Used in almost all modern games

  15. Cascaded Shadow Maps • Use depth in shader to choose cascade • Can blend between two closest cascades to smooth out discontinuities Scene with a cascade of 3

  16. Relief Mapping • Make a 2D surface look 3D • Raytrace through surface along view ray in shader • Optionally also trace a shadow ray to light • Get detailed geometry with very few vertices • Automatic level of detail Normal map Depth map Flat surface lit by normal map Relief mapping with shadows

  17. Relief Mapping • Raytracing done using loop in shader • Take periodic samples and compare depth values, stop when inside surface (called raymarching) • Uses too many samples, also has stepping artifacts

  18. Relief Mapping • Different methods for faster raytracing • Linear search followed by binary search • Cone stepping • Each texel stores a cone containing no geometry • We know ray can safely move to edge of cone

  19. Screen-Space Ambient Occlusion • Darken ambient term in occluded areas • Approximates indirect lighting

  20. Screen-Space Ambient Occlusion • Calculating occlusion • Probe nearby geometry using raycasting • Shoot rays in a hemisphere out of surface • Objects in close proximity cause darkening • Idea: per-pixel occlusion approximation • Flatten raycasting to 2D in the image plane • Sample the depth of 8 to 32 neighboring pixels (requires deferred shading) • Don't count off-image samples as occlusions • Compare neighbor depth to 3D sample depth • If neighbor is in front, occlusion may be occurring

  21. Screen-Space Ambient Occlusion • Occlusion falloff function • Blockers closer to the sample should occlude more • Blockers far from the sample don’t occlude at all • Blockers behind don’t occlude at all D < 0 D > 0 Small epsilon with no occlusion D = 0 D = sample depth - neighbor depth

  22. Depth of Field • Out of focus blur in real cameras • Only one depth where objects are in focus • Focal blur increases in both directions away from that depth

  23. Depth of Field • Model with post-process blur • Vary blur radius based on scene depth: slow • Interpolate between 3 images blurred with different radii: fast

  24. Depth of Field • Discontinuities are problematic (halos) • Don't use sharp objects in background blur • Blur over sharp objects for foreground objects Background blur should not use in-focus pixels Blurry background Sharp in-focus object Blurry foreground object Blurry foreground objects should contribute to sharp objects

  25. Lecture 11 Particles Also covered in 123! C++ Tip of the Week Playtesting Advanced Graphics

  26. Particles • Simulation of volumetric effects • Often undergo forces / damping / collisions • Parametric equations or force integration • Each particle has randomized properties • Particles achieve a global effect together

  27. Type 1: Billboarded particles • Oriented to always face the camera • Can read camera parameters directly from OpenGL • Good for: smoke, fog, glow, ... float m[16]; glGetFloatv(GL_MODELVIEW_MATRIX, m); Vector3 dx = Vector3(m[0], m[4], m[8]); // left-right Vector3dy = Vector3(m[1], m[5], m[9]); // up-down Vector3dz = Vector3(m[2], m[6], m[10]); // front-back glBegin(GL_QUADS); glVertex3f(-dx.x, -dx.y, -dx.z); glVertex3f(-dy.x, -dy.y, -dy.z); glVertex3f(dx.x,dx.y, dx.z); glVertex3f(dy.x, dy.y, dy.z); glEnd();

  28. Type 2: Axis-oriented particles • Rotates around an axis to face the camera • Use cross product to orient particle • Good for: lasers, sparks, trails, ... Vector3 a, b; // the end points of the axis Vector3 eye; // the eye of the camera Vector3 d = (b - a).cross(eye - a).unit(); glBegin(GL_QUADS); glVertex3fv((a - d).xyz); glVertex3fv((a + d).xyz); glVertex3fv((b + d).xyz); glVertex3fv((b - d).xyz); glEnd();

  29. Type 3: Soft particles • Higher quality billboarded particles • Removes sharp line where particle intersects geometry • Implemented in a shader • Reads from the depth buffer (needs separate pass)

  30. Type 3: Soft particles • Linearly interpolate alpha from front to back • alpha = (depth - front) / (back - front) Particle geometry Volume of effect Scene geometry Back depth Front depth Depth buffer value

  31. Type 3: Soft particles • Linearly interpolate alpha from front to back float depth; // value from depth buffer float front, back; // front and back particle depths float alpha = clamp((min(back, depth) - max(0.0, front)) / (back - front), 0.0, 1.0);

  32. Rendering particles • Sorting necessary if using non-associative blend mode • Overdrawing impacts performance • Number of times a pixel is rendered to • Use fewer, richer particles • e.g. animate a texture on one particle • Render particles onto a half-screen-resolution buffer and draw upscaled on top of screen • Need to be careful about depth discontinuities • Use opaque particles (don’t disable depth buffer modification) • Pixels behind opaque particles will be skipped

  33. Lecture 11 C++ Tip of the Week Your best friend! Particles Playtesting Advanced Graphics

  34. C++ tip of the week • The friend keyword • Grants another class or function public access to the private and protected members of this class • More powerful than Java’s package-protection • Finer-grained • Good for granting shared access only to classes that need it (when it shouldn’t be public or protected)

  35. C++ tip of the week classFoo { friendclassBar; friendvoid editFoo(Foo& f); friendvoidBaz::changeSecret(); private: intsecret; public: Foo() : secret(0) {} }; void editFoo(Foo& f) {f.secret = 0;} // error voidstrangerDanger(Foo& f) {f.secret = 0;} classBar{ private: Foo& f; public: Bar(Foo& f) f(f) {f.secret= 5;} voidchangeSecret() {f.secret= 1;} }; classBaz { private: Foo& f; public: // error Baz(Foo& f) f(f) {f.secret= 5;} // okay voidchangeSecret() {f.secret= 1;} }

  36. Lecture 11 C++ Tip of the Week Now with goals! Particles Playtesting Playtesting C++ Tip of the Week Advanced Graphics

More Related