Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/calinou/tesseract-renderer-design

Tesseract renderer design document, originally written by Lee "eihrul" Salzman
https://github.com/calinou/tesseract-renderer-design

cube2 cube2-engine deferred-rendering tesseract tesseract-game

Last synced: about 1 year ago
JSON representation

Tesseract renderer design document, originally written by Lee "eihrul" Salzman

Awesome Lists containing this project

README 

          
# The Tesseract Rendering Pipeline



**This article is a brief overview of the rendering pipeline in

[Tesseract](http://tesseract.gg), an open-source FPS game and level-creation

system.** It assumes basic knowledge of modern rendering techniques and is

meant to point out particular design decisions rather than explain in detail

how the renderer works.



## Platform



The Tesseract renderer ideally targets OpenGL 3.0 or greater, using only Core

profile functionality and extensions, as its graphics API and using SDL 2.0 as a

platform abstraction layer across Windows, Linux, BSD, and OS X. However, it

also functions on OpenGL 2.1 where extensions are available to emulate Core

profile functionality. Mobile GPUs with OpenGL ES are, at the moment, not

targeted. GLSL compatibility is provided across various incompatible versions

using a small preprocessor-based prelude of macros abstracting texture access

and attribute/interpolant/output specification that would otherwise be

incompatible across GLSL versions.



## Motivation



The main design goal of Tesseract is both to support high numbers of dynamically

shadowmapped omnidirectional point-lights and minimize the number of rendering

passes used with respect to its predecessor engine, Sauerbraten. While improved

visuals over Sauerbraten were somewhat desired, it was more important to make

the rendering process more dynamic with at least comparable visual fidelity

while still emphasizing performance/throughput, although at a higher baseline

than Sauerbraten required. So while other potential design choices might have

resulted in further visual improvements, they were ultimately discarded in the

service of more reasonable performance.



Sauerbraten made many redundant geometry passes per frame for effects such as

glow, reflections and refractions, and shadowing that multiplied the cost of

geometry intensive levels and complex material shaders. So, where possible,

Tesseract instead chooses methods that factor rendering costs, such as deferred

shading which allows complex material shaders to be evaluated only once per

lighting pass, or screen-space effects for things such as reflection that reuse

rendering results rather than require more subsequent rendering passes.



Further, Sauerbraten was reliant on precomputed lightmapping techniques to

handle lighting of the world. This approach posed several problems. Dynamic

entities in the world could not fully participate in lighting and so never

looked quite "right" due to mismatches between dynamic and static lighting

techniques. Lightmap generation took significant amounts of time, making light

placement a painful guess-and-check process for mappers, creating a mismatch

between the ease of instantly creating the level geometry and the

not-so-instant-process of lighting it. Finally, storage of these lightmaps

became a concern, so low-precision lightmaps were usually chosen, at the cost of

appearance to reduce storage requirements. Tesseract instead chooses to use a

fully dynamic lighting engine to resolve the mismatch between lighting of

dynamic and static entities while making better trade-offs between appearance

and storage requirements.



Certain features of Sauerbraten's renderer that were otherwise functional such

as occlusion culling, decal rendering, and particle rendering have mostly been

inherited from Sauerbraten and are not extensively detailed in this document, if

at all. For more information about Sauerbraten in general, see [Sauerbraten's

homepage](http://sauerbraten.org).



## Shadows



Tesseract's shadowing setup is built around observations originally made while

implementing omnidirectional shadowmapping in the

[DarkPlaces](http://icculus.org/twilight/darkplaces/) engine.



The first observation is that by use of the texture gather (a.k.a. fetch4)

feature of modern GPUs, it is possible to implement a weighted box PCF filter of

sufficient visual quality that generally performs better than all other

competing shadowmap filters while also requiring less bandwidth-hungry shadowmap

formats, especially if 16bpp depth formats are used. This is advantageous over

competing methods such as variance shadowmaps or exponential shadowmaps that

prefer high-precision floating-point texture formats or prefiltering with

separable blurs that can become quite costly when shadowmaps are atlased into a

larger texture as well as suffering from light bleeding artifacts that plain old

PCF does not have any problems with. A final benefit of relying only on plain

old depth textures and PCF is that depth-only renders are generally accelerated

on modern GPUs and so provide a speedup for rendering the shadowmaps in the

first place over other techniques before they are ever sampled.



For general information about PCF filters, see [this

page](http://www.gdcvault.com/play/10092/Efficient-PCF-Shadow-Map).



It was later discovered that this same weighted box filter could be approximated

with the native bilinear shadowmap filter (originally limited to Nvidia hardware

under the "UltraShadow" moniker, but now basically present on all DirectX 10

hardware when using a shadow sampler in combination with linear filtering) so

that no texture gather functionality is even required, and allowing further

performance enhancements. The particular approximation avoids use of

division/renormalizing blending weights while only causing a slight sharpening

of the filter result that is almost indistinguishable from the aforementioned

weighted box filter. This method in general, though, allows the (approximated)

NxN weighted box filters to be implemented in about (N+1)/2*(N+1)/2 taps. The

default shadowmap filter provides a 3×3 weighted box filter using only 4 native

bilinear taps, providing a good balance between performance and quality.



The final 3×3 filter utilizing native bilinear shadow taps contains some

non-obvious voodoo and was largely found by experimenting with fast

approximations for renormalizing filter weights in the weighted box filter.

Ultimately it was discovered that just the seed value for iteration via

[Newton's method](http://en.wikipedia.org/wiki/Newton's_method) was more than

sufficient to compute filter weights and did not significantly impact the look

of the result. Texture rectangles are also used where possible instead of

normalized 2D textures to avoid some extra texture coordinate math. The filter

(with the unoptimized yet more precise box filter in comments) is listed here

for posterity's sake:



```cpp

#define shadowval(center, xoff, yoff) float(shadow2DRect(shadowatlas, center + vec3(xoff, yoff, 0.0)))

float filtershadow(vec3 shadowtc)

{

    vec2 offset = fract(shadowtc.xy - 0.5);

    vec3 center = shadowtc;

    //center.xy -= offset;

    //vec4 size = vec4(offset + 1.0, 2.0 - offset), weight = vec4(2.0 - 1.0 / size.xy, 1.0 / size.zw - 1.0);

    //return (1.0/9.0) * dot(size.zxzx * size.wwyy,

    //    vec4(shadowval(center, weight.zw),

    //         shadowval(center, weight.xw),

    //         shadowval(center, weight.zy),

    //         shadowval(center, weight.xy)));

    center.xy -= offset*0.5;

    vec4 size = vec4(offset + 1.0, 2.0 - offset);

    return (1.0/9.0) * dot(size.zxzx * size.wwyy,

        vec4(shadowval(center, -0.5, -0.5),

                shadowval(center, 1.0, -0.5),

                shadowval(center, -0.5, 1.0),

                shadowval(center, 1.0, 1.0)));

}

```



This idea is extended to larger filter radiuses but is not shown here.



After experimenting with different projection setups for omnidirectional shadows

such as tetrahedral (4 faces) or dual-parabolic (2 faces), it was found that the

ordinary cubemap (6 faces) layout was best as the larger number of smaller

frustums actually provides better opportunities for culling and caching of faces

while providing the least amount of projection distortion. However, for

multi-tap shadowmap filters, the native cubemap format is insufficient for

easily computing the locations of neighboring taps. Also, despite texture arrays

allowing for batching of many shadowmaps during a single rendering pass, they do

not allow adequate control of sizing of individual shadowmaps and their

partitions.



For further information about the basics of rendering cubemap shadowmaps, see

page 42+ of [this

PDF](https://http.download.nvidia.com/developer/presentations/2004/GPU_Jackpot/Shadow_Mapping.pdf).



Both of these problems may be addressed by unrolled cubemaps, or rather, by

emulating cubemaps within a 2D texture by manually computing the offset of each

"cubemap" face within an atlas texture. The face offset needs only to be

computed once and then any number of filter taps can be cheaply computed based

on that offset. The perpective projection of each frustum must be slightly wider

than the necessary 90 degree field-of-view, to allow the filter taps to sample

some texels outside of the actual frustum bounds without crossing any face

boundaries. A filter with an N texel radius needs a face border of at least that

many texels to account for such out-of-bounds taps.



Further, it becomes trivial to support custom layouts based on modifying the

unrolled lookup algorithm, or to allow other types of shadowmap projections to

co-exist with the unrolled cubemaps in a single texture atlas. Yet another

advantage of the cubemap approach in general, not limited to unrolled cubemaps,

is that rather than sampling omnidirectional shadows frustum-by-frustum

(requiring as many as 6 frustums) as some other past engines do and needing

complicated multi-pass stenciling techniques limit overdraw, the omnidirectoinal

shadowmap may be sampled in a single draw pass over all affected pixels.



Initially, this emulation was done by use of a cubemap (known as a "Visual

Shadow Depth Cube Texture" or VSDCT) to implement the face offset lookup to

indirect into the texture atlas. Later, an equally efficient sequence of simple,

coherent branches was discovered that obviated the need for any lookup texture

and removed precision issues inherent in the lookup texture strategy. The lookup

function that provided the best balance of performance across Nvidia and AMD

GPUs is listed here:



```cpp

vec3 getshadowtc(vec3 dir, vec4 shadowparams, vec2 shadowoffset)

{

    vec3 adir = abs(dir);

    float m = max(adir.x, adir.y);

    vec2 mparams = shadowparams.xy / max(adir.z, m);

    vec4 proj;

    if(adir.x > adir.y) proj = vec4(dir.zyx, 0.0); else proj = vec4(dir.xzy, 1.0);

    if(adir.z > m) proj = vec4(dir, 2.0);

    return vec3(proj.xy * mparams.x + vec2(proj.w, step(proj.z, 0.0)) * shadowparams.z + shadowoffset, mparams.y + shadowparams.w);

}

```



This function overall maps a world-space light-to-surface vector to texture

coordinates within the shadowmap atlas. A useful trick is used in the first few

lines for computing a depth for the shadowmap comparison - the maximum linear

depth along the 3 axial projections is ultimately the linear depth for the

cubemap face that will be later selected - and allows the depth computation to

happen before the resulting projection is found via branching giving slightly

better pipelining here. Note that this lookup function assumes a slightly

non-standard orientation for the rendering of cubemap faces that avoids the need

to flip some coordinates relative to the native cubemap face orientations. It

otherwise lays out the faces in a 3×2 grid. Various math has been baked into

uniforms and passed into this function to transform to post-perspective depth

from linear depth for the later actual shadowmap test in the filtershadow

function. The function is only listed here to give an idea of the performance of

the unrolled cubemap lookup, so reader beware, it is not quite plug-and-play and

some investigation of the engine source code is required for more details. The

result of this lookup function is then passed into the filtershadow function

listed above. These two little functions are rather important and inspired

Tesseract's design; they represent its beating heart and make large numbers of

omnidirectional shadowed lights possible.



All of the shadowmaps affecting a single frame are further aggregated into one

giant shadowmap atlas, currently 4096×4096 using 16bpp depth texture format.

This better decouples the shadowmap generation and lighting phases and allows

lookups for any number of shadowmaps to be easily performed in a single batch or

many shading passes. Various types of shadowmaps are stored in the atlas:

unrolled cubemap shadowmaps for point lights, a simple perspective projection

for spotlights, and cascaded shadowmaps for directional sunlight.



For cascaded shadowmaps for sunlight, Tesseract uses an enhanced parallel-split

scheme with rotationally invariant world-space bounding boxes rounded to stable

coordinate increments for each split as originally detailed for Dice's Frostbite

engine. This allows for somewhat less waste of available shadowmap resolution

than the standard view-parallel split scheme as well as combats temporally

instability/shadow swim that would otherwise occur. For further information, see

[this page](https://web.archive.org/web/20121105134010/http://dice.se:80/publications/title-shadows-decals-d3d10-techniques-from-frostbite/).



"Caching is the new culling." Lights can often have large radiuses that pass

through walls and other such occluders, often making occlusion culling or

view-frustum culling of light volumes ineffective. As an alternative to never

the less greatly reduce shadowmap rendering costs for such lights, the shadowmap

atlas caches shadowmaps from frame to frame, down to the granularity of

individual cubemap faces, if no moving objects are present in the shadowmap.

Lights in Tesseract usually only affect static world geometry, at least when

individual cubemap faces are considered, so the majority of shadowmapped lights

are not more expensive than unshadowed lights, adding only the cost of the

shadowmap lookup and filtering itself. To further optimize the rendering of

shadows for static geometry, for each frustum of each light, an optimal mesh is

generated of all triangles contained only within that frustum and omitting all

backfacing triangles. To avoid moving textures around within the atlas, cached

shadowmaps attempt to retain their placement from the previous frame within the

atlas. To combat fragmentation, if the atlas becomes overly full, cached

shadowmaps are occasionally evicted from a quadrant window of the atlas that

progresses through the atlas from frame to frame.



## Deferred shading and the g-buffer



After evaluating many alternatives, given the small range of materials used in

Tesseract maps, it was decided that deferred shading, in contrast to competing

methods such as light pre-pass or light-indexed, was the most sensible method

for the actual shading/lighting step. Deferred shading provides other benefits

such as easy blending of materials in the g-buffer before the actual shading

step takes place.



Further, by use of tiled approaches to deferred shading, the cost of sampling

the g-buffer can be largely amortized, to the extent that Tesseract's renderer

is, in fact, compute bound by the cost of evaluating the actual per-light

lighting equation on lights that pass culling/rejection tests, rather than bound

by bandwidth or culling costs as other deferred renderers and related research

claim to be.



For further information about the trade-offs involved in various deferred

rendering schemes, see [this

page](http://c0de517e.blogspot.com/2011/01/mythbuster-deferred-rendering.html)

or [this

one](http://software.intel.com/en-us/articles/deferred-rendering-for-current-and-future-rendering-pipelines)

or [this one](http://aras-p.info/blog/2012/03/27/tiled-forward-shading-links/).



Tesseract breaks the screen up into a grid of 10x10 tiles aligned to pixel group

boundaries. Lights are then inserted into per-tile lists by computing a 2D

bounding box of affected tiles. Finally, lights are batched into groups of at

most 8 lights of equivalent type (shadowed or unshadowed, point or spot light)

which are then evaluated per-tile in a single draw call. As many calls to the

tile shader are made as necessary to exhaust all the lights in the per-tile

list. Other lighting effects such as sunlight, ambient lighting, or global

illumination is also optionally applied by the tile shader.



It was found that beyond coarse light culling and per-tile bucketing, more

complicated schemes in the fragment shader for culling lights, possibly

involving dynamic light lists, yield little to no actual speedups when measured

against simpler rejection tests that involve static uniforms. The bandwidth

costs of accessing dynamic light lists tend to actually exceed the costs of

accessing the g-buffer in a tiled renderer thus motivating a simpler tile

shader. As even using uniform buffers to store light parameters imposes a cost

similar to a texture access, it is strongly preferred to use statically indexed

uniforms to supply light parameters to minimize the cost of iterating through

light parameters in the tile shader.



For information about computing accurate screen-space bounding rectangles for

point light sources, see [this page](http://www.terathon.com/code/scissor.html).



The actual g-buffer is composed a depth24-stencil8 depth buffer, an RGBA8 with

diffuse/albedo in RGB and specular strength in A, an RGBA8 with world-space

normal in RGB and either a scalar glow value or an alpha transparency or a

multi-purpose anti-aliasing mask/depth hash value in A. When rendering

transparenct objects, an extra packed-HDR (or RGBA8 if required) texture is used

with additive/emissive light in RGB. On some platforms, a further RGBA8 texture

is used to store a piece-wise encoded linear depth where directly accessing from

the depth buffer texture is either slow or buggy. RGBA8 textures are used for

all layers of the g-buffer both to support older GPUs that can't accept multiple

render targets of varying formats and because RGBA8 textures provide a good

trade-off between size and encoding flexibility.



World-space RGB8 normals are chosen as they are both temporally stable (no

frame-to-frame jitter artifacts) and require almost no encode/decode costs like

other eye-space normal encodings might. The additive/emissive layer allows for

easy handling of environment maps or reflection effects. Overall, this layout

provides a reasonably compact g-buffer while handling the range of materials

used by Tesseract maps. For more information about g-buffer normal encodings,

see [this page](http://aras-p.info/texts/CompactNormalStorage.html).



## Mesh rendering



Where possible, Tesseract utilizes support for half-precision floating point in

modern GPUs to reduce the memory footprint of mesh vertex buffers. Instead of

the usual tangent and bitangent representation, Tesseract utilizes quaternion

tangent frames (QTangents) for compressed tangent-space specification of mesh

triangles, which combine well with the existing use of dual-quaternion skinning

for animated meshes. For more information about QTangents, see [this

page](http://www.crytek.com/cryengine/presentations/spherical-skinning-with-dual-quaternions-and-qtangents).



## Decal rendering



Before final shading, any decaling effects are applied to the scene by blending

into the g-buffer.



## Material shading/Light accumulation



The shading is evaluated into a light accumulation buffer, containing the final

shaded result, that preferably uses the R11G11B10F packed floating-point format.

When the GPU hardware does not support packed float format or is otherwise buggy

(as observed on some older AMD GPUs that do not properly implement blending of

packed float format render targets), a fallback RGB10 fixed-point format is used

that is scaled to a 0..2 range to allow some overbright lighting and still

provide somewhat better precision than an LDR RGB8 format. For more information

about the packed floating-point format and its limitations, see [this OpenGL

specification](http://www.opengl.org/registry/specs/EXT/packed_float.txt).



Linear-space lighting and sRGB textures have also been avoided here because,

during experimenting, it was found they unavoidably produce lighting values that

quantize poorly in these lower precision formats, and the bandwidth cost of

higher-precision formats was ultimately not worth the perceived benefits. The

gamma-space lighting curves and values are well understood by Sauerbraten

mappers, providing for better fill lighting due to softer/less harsh lighting

falloff, interoperating better with a wealth of pre-existing textures optimized

to look appealing under gamma-space lighting, and producing fewer banding

artifacts with lower-precision HDR texture formats.



While the lighting thus still happens in gamma-space, overbright lighting values

are never the less supported and utilized, motivating later tonemapping and

bloom steps.



For more information about the trade-offs involved in working in gamma-space vs.

linear-space, see [this page](http://filmicgames.com/archives/299).



## Screen-space ambient obscurance



To help break up the monotony of those indoor areas of a map that may rely on

ambient lighting and to help reduce the burden of requiring lots of point lights

to provide contrast in such places, Tesseract implements a form of SSAO.



After the g-buffer has been filled, but before the shading step, the depth

buffer is downscaled to half-resolution and SSAO is computed, utilizing both the

downscaled depth and the normal layer of the g-buffer, into a another buffer

packing both the noisy/unfiltered obscurance value and a copy of the depth in

each texel. This buffer is then bilaterally filtered, efficiently sampling both

the obscurance and depths in a single tap due to the aforementioned packing

scheme. The final resulting buffer is then used to affect sunlight and ambient

lighting in the deferred shading step.



In particular, Tesseract makes use of the Alchemy Screen-Space Ambient

Obscurance algorithm detailed here: [this

page](http://graphics.cs.williams.edu/papers/AlchemyHPG11/). Tesseract further

incorpates improvements to the algorithm suggested

[here](http://graphics.cs.williams.edu/papers/SAOHPG12/).



## Global illumination



One of the primary motivations for including global illumination in Tesseract

was not so much to increase visual quality, but instead to actually increase

performance. While Tesseract can support a large number of shadowed lights,

eventually mappers with the best of intentions can defeat the best of engines.

So having some form of indirect/bounced lighting allows for light to get to

normally dark corners in a map that would otherwise require a lot of "fill"

lights to brighten them up or otherwise rely on ugly/flat ambient lighting.

Tesseract provides a form of diffuse global illumination for the map's global,

directional sunlight that can thus help to brighten up maps, without requiring a

lot of point light entities, so long as a mapper is careful to allow sunlight

into the map interior.



Diffuse global illumination is computed only for sunlight using the Radiance

Hints algorithm, which is similar to but distinct from Light Propagation

Volumes. First, a reflective shadowmap is computed for the scene from the sun's

perspective, storing both the depth and reflected surface color for any surface

the sunlight directly hits. Then using a particular random sampling scheme, the

reflective shadowmap is gathered into a set of RGBA8 cascaded 3D textures

storing low-order spherical harmonics. 3D textures are used for both Radiance

Hints and LPV algorithms as they allow for cheap trilinear filtering of the

spherical harmonics. However, Radiance Hints still differs from the LPV approach

in that it gathers numerous samples from the reflective shadowmap in one shading

pass, rather than injecting seed values into a 3D grid and iteratively refining

it, offering some performance and simplicity advantages for the case of

single-bounce diffuse global illumination.



During this process, an ambient occlusion term is also computed beyond what is

detailed by the basic Radiance Hints algorithm. Where possible, these 3D

textures are cached from frame to frame. These cascaded 3D textures are then

sampled in the shading step to provide both the sunlight global illumination

effect as well as using the ambient obscurance term to implement an

atmospheric/skylight effect.



For further information on Radiance Hints, see "Real-Time Diffuse Global

Illumination Using Radiance Hints" at [this

PDF](http://graphics.cs.aueb.gr/graphics/docs/papers/RadianceHintsPreprint.pdf)

or [this page](http://graphics.cs.aueb.gr/graphics/research_illumination.html).



## Transparency, reflection, and refraction



Sauerbraten supported an efficient alpha material for world geometry, where

first only the depth of world geometry was rendered, and then finally shading of

the world geometry was rendered with alpha-blending enabled. This allowed only

the first layer, and optionally before that a back-facing layer, to be rendered

cheaply with no depth-sorting involved and is essentially a limited and cheaper

form of the more general-purpose depth-peeling approach. This was sufficient for

making props like windows or similar glass structures in levels by mappers.

Though there is the drawback that transparent layers can't be seen behind other

transparent layers, when used in moderation this drawback is not debilitating.



Tesseract expands upon this notion by shading transparent geometry in a separate

later pass from opaque geometry, though both are accumulated into the light

accumulation buffer. This has both the above-mentioned benefits, as well as

allowing transparencies to be easily shadowed and lit just like any other opaque

geometry and avoiding the need for a separate forward-renderer implementation.

Because transparent geometry is first rendered into the g-buffer as if it were

opaque, there is no need to do a prior depth-only rendering pass to isolate the

front-most transparency layer like in Sauerbraten. Careful stenciling and

scissoring is used to limit the actual shading step to only the necessary screen

pixels that will have transparent geometry blended over them. The A channel in

the normal layer of the g-buffer is used to store the alpha transparency value

to control the blending output of this shading step.



This separate shading pass for transparent geometry also allows the light

accumulation buffer from the previous opaque geometry pass to be easily

resampled for screen-space reflection and refraction effects on materials like

distorted glass or water, providing for a greater range of reflective and

refractive materials than Sauerbraten was previously capable of. The emissive

layer of the g-buffer is used for handling the refractive/reflective component

of a material's shading.



Refraction effects are done by sampling the light accumulation buffer with added

distortion, limited by a mask of refracting surfaces to control bleed-in of

things outside the refraction area. For more information about the refraction

mask technique, see

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter19.html



Reflection poses some difficulty since a separate render pass for every

reflecting plane was no longer desired and would anyway be too expensive given

the heavyweight deferred shading pipeline. A screen-space ray marching approach

is instead used that in a small number of fixed steps walks through the depth

buffer until it hits a surface and then samples the light accumulation buffer at

this location. Some care is needed to fade out the reflections when either

looking directly at the reflecting surface or when it might otherwise sample

outside of screen borders or valid reflection boundaries in general. This

approach has some potential artifacts when objects are floating above reflective

surfaces, but on the other hand allows any number of reflective objects in the

scene without requiring a separate render pass for every distinct reflection

plane in the scene. For materials where screen-space reflections are inadequate,

environment maps are instead used.



For further information on screen-space reflections, see

http://www.crytek.com/cryengine/presentations/secrets-of-cryengine-3-graphics-technology

or http://www.gamedev.net/blog/1323/entry-2254101-real-time-local-reflections/



## Particle rendering



Before the tonemapping step, Tesseract does particle rendering. Unlike in

Sauerbraten, the depth buffer and shading results are more easily available

without having to read back the frame buffer or using special-cased kluges to

avoid such read-backs, making effects like soft or refractive particles cheaper

and simpler to implement.



## Tonemapping and bloom



The light accumulation buffer is first quickly downscaled to approximately

512×512. A high-pass filter is run over this and then separably blurred to yield

a bloom buffer that will be added to the lighting. This downscaled buffer (the

non-blurred one) is also converted to luma values and iteratively reduced down

to 1×1 to compute an average luma for the scene. This average luma is slowly

accumulated into a further 1×1 texture that allows for the scene's brightness

key to gradually adjust to changing viewing conditions. This accumulated average

luma is fed back (via a vertex texture fetch in the tonemapping shader) into a

tonemapping pass which maps the lighting into a displayable range. Note that the

gamma-space lighting is converted temporarily into linear-space before

tonemapping is applied and then converted back to gamma-space.



To better preserve color tones and in contrast to tonemapping operators that

unfortunately tend to "greyify" a scene such as filmic tonemapping, Tesseract

uses a simpler "photographic" tonemapping operator suggested by Emil Persson

a.k.a. Humus, but applied to luma. See [this forum

topic](http://beyond3d.com/showthread.php?t=60907) or [this

one](http://beyond3d.com/showthread.php?t=52747).



For more information about the trade-offs involved in various tonemapping

operators, see [this page](http://filmicgames.com/archives/category/tonemapping)

or [this

page](http://mynameismjp.wordpress.com/2010/04/30/a-closer-look-at-tone-mapping/).



## Generic post-processing



Before the final anti-aliasing and/or upscale step, any generic post-processing

effects are applied. Currently this stage is not extensively utilized.



## Anti-aliasing



In contrast to Sauerbraten's forward renderer, Tesseract's performance is

strongly impacted by resolution. Many schemes were evaluated for reducing

shading costs, such as inferred lighting or interleaved rendering, but

ultimately they were more complicated and no more performant or visually

pleasing than simply rendering at reduced resolution and anti-aliasing the

result with a final upscale to desktop resolution. Since Tesseract relies upon

deferred shading, simply using MSAA by itself does not provide adequate

performance due to increasing memory bandwidth usage from large multisampled

g-buffer textures, though Tesseract does, in fact, implement stand-alone MSAA in

spite of deferred shading. To this end, Tesseract provides several forms of

post-processing-centric anti-aliasing, though mostly in the service of

implementing one particular post-process anti-aliasing algorithm, Enhanced

Subpixel Morphological Anti-Aliasing by Jorge Jiminez et al, otherwise known as

SMAA.



The baseline SMAA 1× algorithm provides morphological anti-aliasing utilizing

only the output color buffer. While this algorithm is an improvement over

competitors such as FXAA, it still suffers from some temporal instability

visible as frame-to-frame jitter/swim. To combat this, Tesseract implements

temporal anti-aliasing that combines with SMAA to provide the SMAA T2× mode. The

SMAA T2× mode, and temporal anti-aliasing in general, however, are often

inadequate when things move quickly on-screen. Temporal anti-aliasing reprojects

the rendering output of prior frames onto the current frame, and when the scene

changes quickly, this is often not possible, so the temporal anti-aliasing fails

to anti-alias in such cases. The A channel of the g-buffer's normal layer is

used to provide a mask of all pixels belonging to moving objects in the scene,

as distinguished from static world geometry, instead of requiring a more costly

velocity buffer. Ultimately, only static geometry that is subject only to

camera-relative movement participates in the temporal anti-aliasing which allows

cheap computation of per-pixel velocity vectors from the global camera

transforms without requiring storing object velocities.



To overcome the particular movement limitations of temporal anti-aliasing, SMAA

also provides several modes that combine with multisample anti-aliasing, SMAA

S2× and SMAA 4×, utilizing 2× spatial multisampling to provide temporal

stability. SMAA 4× further combines temporal anti-aliasing and 2× multisample

anti-aliasing with the baseline morphological anti-aliasing to provide a level

of post-process anti-aliasing that can rival MSAA 8× modes while using far less

bandwidth (only requiring 2× MSAA textures) and being much faster.



Overall, SMAA gracefully scales up and down both in terms of performance and

visual quality according to the user's tastes with its ability to incorporate

all these disparate anti-aliasing methods, and while still interacting well with

deferred shading. For more information about SMAA, see [this

page](http://www.iryoku.com/smaa/) and also for further improvements recently

suggested by Crytek see [this

page](http://www.crytek.com/cryengine/presentations/cryengine-3-graphic-gems).



Tesseract's deferred MSAA implementation renders into multisampled g-buffer and

light accumulation textures. Before shading, an edge detection pass is run using

information contained in the normal/depth hash layer of the g-buffer to fill the

stencil buffer with an edge mask. The depth hash value, stored in the A channel

of the normal layer of the g-buffer, is simply an 8 bit hash combining

information about linear depth and material id that when combined with the world

space normal stored in the RGB channels of this same texture provides reasonable

and cheap determination of pixels that only very occasionally mispredicts edges.

Single-sample shading is evaluated at internal/non-edge pixels, and multisample

shading is evaluated at edge pixels. The tonemapping pass is able to run before

the MSAA resolve to properly support the multisampled SMAA modes; however, this

is not done by default for stand-alone MSAA usage as it can decrease performance

for mostly imperceptible benefits in quality.



For more information about implementing MSAA in combination with deferred

shading, see [this

page](http://software.intel.com/en-us/articles/deferred-rendering-for-current-and-future-rendering-pipelines).



As a final low-quality but highly performant backup and comparison basis,

Tesseract provides an implementation of FXAA, though the baseline SMAA 1× is

ultimately preferred.



For higher quality upscaling of the anti-aliased result than the usual linear

filtering, Tesseract also provides a bicubic filter such as used for upscaling

video. This can alleviate some blurring a linear filter would otherwise cause.

For more information about fast bicubic filtering, see [this

page](http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter20.html).



## Further information



- **Homepage** - [Tesseract](http://tesseract.gg)

- **Developer** - [Lee Salzman](http://sauerbraten.org/lee/)



*Last revised November 7, 2013.*