Graphics Reference
In-Depth Information
GPU-Generated Quads
The algorithm used for generating the extents of a scissor rectangle can be trivially adapted
for use in a vertex shader or a geometry shader. This effectively offloads the computation
to the GPU, and removes the need for a state change before drawing each light source.
The removal of the state change allows multiple light sources to be batched together into a
single draw call, which can dramatically reduce CPU overhead for large numbers of lights.
See the light prepass sample for a demonstration of this approach.
Bounding Geometry
As mentioned in the previous section, it's possible to determine bounding geometry for
point and spot lights, based on their position and attenuation properties, for use with the
scissor test. It's possible to take this concept a step further, and create a triangle mesh repre-
senting a light's bounding volume and then render that, instead of using a full screen quad.
This frees us from the limitations of screen-space rectangles and also makes natural use of
the CPU's vertex processing and rasterization capabilities.
To generate the geometry, we do not need to take into account an individual light's
properties. Instead, we can generate a single sphere and a single cone to be used with all
lights, and then apply a world transform by calculating translation, rotation, and scale com-
ponents based on the light properties. For a point light, it is simplest to create the sphere
mesh with a radius of 1 and centered at the origin. Then our translation can be set to the
light's position, and the X, Y, and Z scales can all be set to the light's effective range. For a
spot light, a cone aligned with the Z axis (with the tip at the origin) and an angle of 45 de-
grees should be used. Then the translation and orientation can be set to the light's position
and orientation, and the Z scale can be set to the effective range. The X and Y scales can
then be set by determining the radius of the cone, which is done by calculating the tangent
of the spotlight angle and multiplying with the range.
When the bounding geometry is rendered, we must also choose whether the pixels
should be rendered with front-face or back-face culling. We can't simply disable culling,
because pixels would get lit twice. This decision must be carefully made, because if the
bounding geometry intersects with the near clipping plane or the far clipping plane of the
camera, some of the front-facing or back-facing triangles will not be rasterized. Thus, if
a bounding volume intersects with the near clipping plane, back-face culling should be
used. If it intersects with the far-clipping plane, back-face culling should be used. If it in-
tersects with both, this means the light is very large and should be rendered with a quad or
some other method. As an alternative to switching culling modes, the vertices can also be
clamped to the near and far clipping planes in the vertex shader. This can be useful if lights
need to be batched together into a single draw call.
Aside from also limiting pixel shading to the bounding volume's screen space projec-
tion, using bounding geometry also allows us to make use of hardware depth testing to cull
Search WWH ::




Custom Search