Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware

Transcription

1 White Paper Intel Software Solutions Group David Bookout Satheesh G. Subramanian Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware This white paper describes techniques to generate shadows on mainstream graphics hardware in realtime. Shadows make a 3D scene more realistic and while Shadow Maps suffer from anti-aliasing artifacts due to low-precision textures, Shadow Volumes avoid this problem by creating physically accurate shadows. However, if there are many dynamic shadow-generating objects or if there are a lot of moving light sources, this technique could severely affect performance. This paper describes how shadow volumes generated on the CPU using a multithreaded approach could free up the graphics hardware from this bottleneck-creating task. November 2007 Intel Corporation

2 Contents 1 Introduction Overview Implementation Threading Additional Considerations References and Related Articles References Related Articles About the Authors Figures 1-1 Scene Rendered Without and With Shadows Representation of Shadow Optics Representation of Shadow Volume Example of a Silhouette Edge New Quad Created from the Silhouette Edge to Form the Shadow Polygon A Simple Example of the Z-Pass Stencil Buffer Counting Technique The Z-Pass Technique is Incorrect when the View is Inside of a Shadow Volume Example of Capping of Convex Shadow Volumes Rendering the Shadow Volume Created Low Resolution Geometry Results in Low Resolution Shadows

3 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 1 Introduction Shadows are an important part of our perception of the world. We interpret them to give ourselves more information about the objects we see in the world. The position and shape tell us about the surface on which a shadow is cast, the shape of the object, and the relative position of the light (Error! Reference source not found.). For 3D graphics, they also provide a more realistic feel to scenes. A viewer can easily detect a computer-generated image by incorrect shadows. Figure 1-1. Scene Rendered Without and With Shadows This paper discusses: A detailed implementation using shadow volumes on mainstream graphics hardware based on the Intel G965 Express Chipset that support hardware vertex processing with the lastest drivers (Chipset driver version 14.31, Graphics driver version ) A multi-threaded solution for handling moving objects and light sources. An implementation (code sample) of shadow maps that is based on the EmptyProject example from the Microsoft DirectX* 9.0 SDK The shadow provides the viewer with information about the position of the light source and the distance from the torus to the back plane. 3

4 4 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper

5 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 2 Overview Shadows are produced when light from a light source is blocked by an object (the occluder) before it reaches a second object (the receiver). The darkest area of the shadow on the receiver is called the umbra. Because lights usually have a significant volume, there is an area around the edge of the shadow where some, but not all, of the light from the light source reaches the receiver. This area, called the penumbra, blends the edge of the shadow to the fully lit section of the receiver. Real-time graphics relies on a number of simplifications to the lighting system that make accurate shadows difficult. The most significant is the point light source; point lights do not generate a penumbra on the receiver because the light is either fully occluded or not. Point light sources will make our calculations much easier, but they result in unrealistic hard shadows. Light sources that occupy a volume in space create soft shadows where the receiver is partially lit by the light source (Error! Reference source not found.). In this sample, we consider the light source to be a point light source and hence you would see hard shadows. Figure 2-1. Representation of Shadow Optics In Error! Reference source not found., a light source sampled from only one point creates a hard shadow. Sampling from the entire source creates the penumbra and an umbra that is smaller than the hard shadow. The shadow volume algorithm uses the volume of space defined by the light source and an occluder. Anything inside the shadow volume is in shadow, and anything outside of the volume is lit. The shape of the volume is determined by the silhouette edges of the occluder relative to the light source. The shadow volume is the collection of silhouette edges projected away from the light to infinity. When lighting a scene, we must first determine the silhouette edges of the occluders and generate the appropriate shadow volumes. Once we have the volumes we must determine what geometry is in shadow and what is not. Then we must perform the lighting calculations. 5

6 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper Figure 2-2. Representation of Shadow Volume 6

7 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 3 Implementation Silhouette Edge Detection One of the most important aspects of using shadow volumes is the choice of algorithms for determining the silhouette edges of the occluder. Once the boundaries of the shadow volume are known, determining the lighting of a scene is reasonably straightforward. Silhouette edge detection algorithms vary in running time, conceptual complexity, and robustness. When choosing an algorithm, consider the models that you will use. If the models are simple, a simple algorithm will suffice. For our implementation, we chose a simple algorithm that relies on a closed mesh, and each edge in the mesh is used by exactly two faces. The algorithm does not require any additional restrictions and runs in O(n2 log n) complexity. Algorithm: Start with an empty list of silhouette edges For each face if the face is front facing for each edge of the face if the edge is in the silhouette edge list remove the edge from the list else add the edge to the silhouette edge list endif endfor endif endfor The algorithm simply iterates over each triangle. If the triangle faces the light, check to see if the edges are shared with another triangle that faces the light. The test to check if the triangle faces the light is a simple dot product between the triangle normal and the light vector incident on the triangle surface. If the dot product is ve the triangle is not facing the light and if it is positive, it is facing the light. If an edge is not shared with another triangle edge facing the light, then it is a silhouette edge. The included sample code contains an implementation (function: GenerateShadowVolume) of the above algorithm that generates the edge list for an ID3DXMesh using the vertex buffer and index buffer. 7

8 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper Figure 3-1. Example of a Silhouette Edge Figure 3-1 shows a silhouette edge that is shared by a face that points toward the light and a face that points away from the light. Create the Shadow Volume Now that we know the silhouette edges of the model, we must create a new mesh for the shadow volume. We create a new quad for each silhouette edge and use the vertex positions. For each position in the silhouette edges, we create two vertices: one that will be the vertex near the light source, and the other that will be the vertex projected away from the light source. We use a texture coordinate value to pass this information to the vertex shadier. When we create the quad, we must maintain the winding order of the original mesh so that we know if we are entering or leaving a shadow volume. Figure 3-2 shows the new quad created has two new vertices that will be projected away from the light to form the shadow polygon Figure 3-2. New Quad Created from the Silhouette Edge to Form the Shadow Polygon 8

9 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware Count in the Stencil Buffer There are two ways to use the stencil buffer and shadow volumes to determine if a point is in shadow. The simplest is the Z-Pass approach. First, render the scene with only ambient light. Then, render the shadow volumes. When we render the shadow volumes, we update the stencil buffer only if the shadow volume is closer than the point stored in the Z-Buffer from the ambient render pass, and we do not update the depth buffer. We increment the stencil buffer for each front-facing polygon, and decrement for each backfacing polygon. Then render the scene with diffuse light, and only update the render target where the stencil buffer is 0. Figure 3-3. A Simple Example of the Z-Pass Stencil Buffer Counting Technique Figure 3-4. The Z-Pass Technique is Incorrect when the View is Inside of a Shadow Volume The basic idea of Z-Pass is make sure that a ray cast from the viewer to a point in the scene exits as many shadow volumes as it enters before it reaches that point [2]. Unfortunately, if the view is inside of a shadow volume, because we do not keep track of entering and leaving specific shadow volumes, the count is off by one. The Z-Fail, or Carmack s Reverse, avoids this problem by counting all of the shadows that are farther away. To use Z-Fail, render the scene with ambient light. Then, without modifying the 9

10 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper depth or color buffers, render the shadow volume polygons, but now update the stencil buffer only when the depth test fails. The Z-Fail technique works well, but requires that the shadow volumes be closed to maintain the correct count in the stencil buffer. We must generate caps for the shadow volumes to maintain the correct count in the stencil buffer for cases where the shadow volume is clipped by the view frustum and the volume. For simple convex shapes, capping is straightforward, but shapes that are more complex must be handled carefully. Figure 3-5. Example of Capping of Convex Shadow Volumes Figure 3-5 shows how simple convex shadow volumes could be capped. However, these do not apply to more complicated shapes, such as holes). The following code shows the rendering flags setup for rendering the shadow volume using the Z-fail technique: technique RenderShadowVolume { pass P0 { // For front facing polygons VertexShader = compile vs_1_1 VertexShadowVolume(); PixelShader = compile ps_1_1 PixelShadowVolume(); CullMode = None; // Render both sides TwoSidedStencilMode = true; // but treat them differently, when defining stencil values // Disable writing to the frame buffer AlphaBlendEnable = true; SrcBlend = Zero; DestBlend = One; // Disable writing to depth buffer ColorWriteEnable = 0x0; ZWriteEnable = false; ZFunc = Less; 10

11 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware // Setup stencil states StencilEnable = true; StencilRef = 1; StencilMask = 0xFFFFFFFF; StencilWriteMask = 0xFFFFFFFF; // Enable stencil // For front-facing polygons, decrement the stencil buffer StencilFunc = Always; StencilZFail = Keep; StencilPass = Decr; } } // For back-facing polygons, increase the stencil buffer Ccw_StencilFunc = Always; Ccw_StencilZFail = Keep; Ccw_StencilPass = Incr; Now that we have the proper render state, we can actually draw the shadow volume polygons. The vertex shader examines the vertices passed to it, and projects some of the vertices away from the light source. When creating the shadow volume mesh, we marked some of the vertices with a texture coordinate value of 0; these vertices will remain where they are. All of the others will be transformed here. void VertexShowShadowVolume(float4 iposition : POSITION, float4 inormal : NORMAL, float3 ishadowproject : TEXCOORD0, out float4 oposition : POSITION, out float4 ocolor : COLOR) { // just check the value stored in ishadowproject. If it is larger than 1.0f, it should be projected away from the light source to create the shadow volume polygon. if(ishadowproject.x > 1.0f) { // Restrict the size of the projected volume iposition = iposition f * normalize(iposition - g_vlight0pos); } oposition = mul(iposition, g_mworldviewprojection); ocolor = 1.0f; } Figure 3-6 shows the shadow volume for the simple scene that we have created in the sample application: 11

12 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper Figure 3-6. Rendering the Shadow Volume Created 12

13 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 4 Threading Shadow volumes present an excellent opportunity for parallel execution. Each occluder/light-source pair is independent of all the other pairs. The silhouette edge detection algorithm can be executed on a separate thread from the main rendering and other edge detection routines when the edge detection is performed on the CPU. An update manager can monitor the relative positions of light sources and occluders and update the shadow volumes when an occluder or light source moves. The shadow volumes are then regenerated on a separate thread. In the sample code, we have created an oscillating light source and hence require doing the shadow volume generation for every frame. We initialize a thread to compute the new shadow volumes. We generate shadow volumes for both the box and the torus in the same thread. Depending on the complexity of the scene, we could potentially separate them into multiple threads. In this implementation, we have created a mutex object that synchronizes the read/write accesses on the shadow volume mesh between the rendering thread and the shadow volume generating thread. // Create the threads. After the initial shadow volume creation, // subsequent writes into the shadow volume meshes happen in the thread. g_hrendermutex = CreateMutex(NULL, FALSE, NULL); g_hshadowthread = (HANDLE) _beginthreadex( NULL, 0, GenShadowVolumeThreadFunc, (void*) pd3ddevice, 0, (unsigned int*)&g_hshadowthreadid ); Note: Before generating the shadow volumes using the GenerateShadowVolume function, we need to transform the light into the object coordinate space. The following function is called in the thread to compute the shadow volumes. // Thread that handles creation of shadow volumes unsigned stdcall GenShadowVolumeThreadFunc(LPVOID lpparam) { IDirect3DDevice9* pd3ddevice = (IDirect3DDevice9*)(lpParam); while (1) { D3DXVECTOR4 vtoruslightpos, vboxlightpos; D3DXMATRIXA16 mtorusworldinv, mboxworldinv; D3DXMatrixInverse(&mBoxWorldInv, NULL, &g_mboxworld); D3DXMatrixInverse(&mTorusWorldInv, NULL, &g_mtorusworld); // NOTE: This step would have to be done every time the light or object // coordinates change. // We could compute the silhouettes in a separate thread for each // object-light combination. // Transform the light position in the torus's object coordinates to // compute silhouettes D3DXVec4Transform(&vTorusLightPos, &g_vworldlightpos, &mtorusworldinv); 13

14 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper D3DXVec4Transform(&vBoxLightPos, &g_vworldlightpos, &mboxworldinv); GenerateShadowVolume(pd3dDevice, g_ptorusmesh, (D3DXVECTOR3)vTorusLightPos, &g_ptorusvolumemesh); GenerateShadowVolume(pd3dDevice, g_pboxmesh, (D3DXVECTOR3)vBoxLightPos, &g_pboxvolumemesh); // Signal to the main thread that this thread has completed its work, but not shutdown the thread _endthreadex(0); } } return 0; To get access to the information about the model that we need, we must lock the vertex buffer and the index buffer using the LockVertexBuffer and LockIndexBuffer methods provided by the ID3DXMesh interface. The lock method allows you to specify the type of lock needed; here we just need a read-only lock that does not block the rendering of the model. // use the D3DLOCK_READONLY flag so that we do not block any other reads. V(pCloneMesh->LockVertexBuffer(D3DLOCK_READONLY, (LPVOID*)&pVertexData);) V(pCloneMesh->LockIndexBuffer(D3DLOCK_READONLY, (LPVOID*)&pIndexData);) To ensure that all shadow volumes are up to date for the scene and to simplify synchronization issues, we can start threads to regenerate any necessary shadow volumes and draw the scene with ambient light at the same time. After the first pass of rendering, we render the shadow volumes, then, the scene is rendered again with diffuse light. Typically in a game, we would have objects identified as generating shadows and those that do not generate shadows. We would have to compute the shadow volumes for only those objects that generate shadows. In addition we could identify some light sources to be creating shadows, though in the ideal world all light sources would create shadows. The number of light sources and objects that are shadow generating could be varied depending on the complexity of the objects, the overall complexity of the scene and the number of cores on the processor. 14

15 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 5 Additional Considerations Shadow volumes provide you with more control over the shadows in the scene. Because only the geometry we specify as an occluder can act as an occluder, we can limit the number of occluders in a scene to help improve system performance. Unfortunately, we must also keep track of more information about the scene, so that we can regenerate any volumes associated with geometry or a light that has moved. While shadow maps suffer aliasing on the shadow boundaries because the lighting is determined in light space (a perspective projection from the light), all shadow volume lighting is determined in view space. Visual artifacts remain a problem because the geometry casting the shadow must be of appropriate detail or the resulting shadow volume may appear too rough. Non-manifold, non-closed, and other inconsistencies within the geometry may present additional visual artifacts in the rendered scene. Figure 5-1. Low Resolution Geometry Results in Low Resolution Shadows Because shadow volumes rely on the repeated drawing of many possibly large and overlapping polygons that make up the volume, the fill rate of the graphics system can be the ultimate bottleneck [3]. Shadows are very useful in real-time graphics because they provide needed realism and important visual cues. The shadow volume technique is particularly good because it allows a high degree of control concerning which lights and occluders require attention. The technique also allows for a wide range of implementations from very simple to very sophisticated, depending on the situation. Shadow volumes also present an excellent opportunity for parallel computation that can greatly improve performance. 15

16 16 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper

17 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 6 References and Related Articles 6.1 References [1] F. Crow Shadow Algorithms for Computer Graphics, Computer Graphics (Proc. SIGGRAPH), Vol. 11, No. 3, Aug 1977, pp ) [2] C. Everitt and M. J. Kilgard, Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering, developer.nvidia.com. [3] T. Akenine-Moller and E. Haines. Real-Time Rendering. A K Peters Ltd, 2 nd edition, Related Articles A good introduction to the different techniques for generating shadows: A. Woo, P. Poulin, A. Fournier, A Survey of Shadow Algorithms, IEEE Computer Graphics and Applications, vol. 10, no. 6, November, 1990, pp Most of the new work with real-time shadow volumes concerns creating soft shadows. For an excellent overview of soft shadows with shadow volumes and shadow maps see: J.-M. Hassenfratz, M. Lapierre, N. Holzshuch, and F.X. Sillion, A Survey of Real- Time Soft Shadows Algorithms, EuroGraphics, For a better silhouette detection algorithm see: G. Aldridge and E. Woods, Robust, Geometry-Independent Shadow Volumes, GRAPHITE '04: Proceedings of the 2nd international conference of Computer graphics and interactive techniques in Australia and South East Asia,

18 18 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper

19 White Paper Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware 7 About the Authors David Bookout is a software engineer who has worked in 3D graphics for several years. He has three previous publications with Intel Software Network. While at Intel, he worked on Shockwave3D* writing custom pixel and vertex shaders in the Intel Architecture Labs. Dave was a graduate student in computer science at OGI at the time of this work. He also has a BA in English from Purdue University. Satheesh G Subramanian is a Senior Applications Engineer in the Software Solutions Group at Intel Corporation currently working on graphics and gaming technology enabling. Prior to this role, he had worked on developing proprietary VLSI CAD solutions for the Intel Microprocessor Teams. He has a Masters in Computer Science from the University of Illinois at Chicago, specializing in virtual reality and collaborative immersive environments in the CAVE* virtual environments and has presented in various technical conferences including SIGGRAPH and GDC. He is currently pursuing an MBA in entrepreneurship and entertainment management from the UCLA Anderson School of Management. 19

20 Multi-Threaded Shadow Volumes on Mainstream Graphics Hardware White Paper INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. This white paper, as well as the software described in it, is furnished under license and may only be used or copied in accordance with the terms of the license. The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Intel Corporation. Intel Corporation assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document. Intel processor numbers are not a measure of performance. Processor numbers differentiate features within each processor family, not across different processor families. See for details. The Intel processor/chipset families may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request. Copies of documents, which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling , or by visiting Intel's Web Site. Intel and the Intel Logo are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Copyright 2007, Intel Corporation. All rights reserved. 20