Antarctica: Technical Details

m (added category:antartica + formatting)
Line 1: Line 1:
-
This page concerns the new renderer (sometimes referred as Antartica engine or pipeline) used in STK.
+
This page describes the new renderer (sometimes referred as Antartica engine or pipeline) used in STK.
The new renderer is using (almost) exclusively function from the core GL 3.3+ spec in order to take advantage of modern hardware feature.
The new renderer is using (almost) exclusively function from the core GL 3.3+ spec in order to take advantage of modern hardware feature.
Line 8: Line 8:
-
The main features of our renderer are the following :
+
== The main features of our renderer ==
* Gamma correct rendering. Monitors apply a "gamma transformation" on every channel of color input : pow(., gamma) where gamma is monitor dépendent but usually close to 2.2. This is intended to mimic older CRT non-linear behavior where the color (128, 128, 128) was a much darker grey than the grey right between (0, 0, 0) and (255, 255, 255) (which in turn is mapped to (187, 187, 187)) because of voltage to pixel conversion. At the other end of the rendering chain, textures are stored with an inverse gamma applied to compensate this effect when displayed on screen. With such inputs and output bias light calculations become wrong and can lead to oversaturate picture. The new renderer is using texture and framebuffer format aware of this bias to make our light mathematically correct.
* Gamma correct rendering. Monitors apply a "gamma transformation" on every channel of color input : pow(., gamma) where gamma is monitor dépendent but usually close to 2.2. This is intended to mimic older CRT non-linear behavior where the color (128, 128, 128) was a much darker grey than the grey right between (0, 0, 0) and (255, 255, 255) (which in turn is mapped to (187, 187, 187)) because of voltage to pixel conversion. At the other end of the rendering chain, textures are stored with an inverse gamma applied to compensate this effect when displayed on screen. With such inputs and output bias light calculations become wrong and can lead to oversaturate picture. The new renderer is using texture and framebuffer format aware of this bias to make our light mathematically correct.
See here for more information http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html  
See here for more information http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html  
Line 25: Line 25:
-
Planned features
+
== Planned features ==
* Rectangular light. Point lights are quite non realistic and they have noticeable shortcomings : their radiance tend to go very high close to them, their diffuse component is a boring sphere and their specular reflexion is infinitely thin so you have to make everything ultra sharp to actually see them. Unfortunatly shadowing area light requires different algorithm than sunlight shadow and point light shadow (see http://www.crytek.com/download/Playing%20with%20Real-Time%20Shadows.pdf for an algorithm that uses voxellisation but produces great visual results)
* Rectangular light. Point lights are quite non realistic and they have noticeable shortcomings : their radiance tend to go very high close to them, their diffuse component is a boring sphere and their specular reflexion is infinitely thin so you have to make everything ultra sharp to actually see them. Unfortunatly shadowing area light requires different algorithm than sunlight shadow and point light shadow (see http://www.crytek.com/download/Playing%20with%20Real-Time%20Shadows.pdf for an algorithm that uses voxellisation but produces great visual results)
* Shadows (and maybe RSM ?) for point light.
* Shadows (and maybe RSM ?) for point light.

Revision as of 19:58, 9 December 2014

This page describes the new renderer (sometimes referred as Antartica engine or pipeline) used in STK.

The new renderer is using (almost) exclusively function from the core GL 3.3+ spec in order to take advantage of modern hardware feature. While it uses irrlicht graph traversal and irrlicht material manager to some extend, all meaningfull GL calls are done by this new renderer. Irrlicht's code is only used for context creation, framebuffer creation/binding, texture loading, and some offscreen rendering like minimap generation and kart selection viewer. It should be possible to completly handle the framebuffer creation and binding (it's already done for shadow map because of Irrlicht's lack of textures arrays), but texture loading requires some support from irrlicht, in order to be able to load our mesh.

It was decided to move from irrlicht OpenGL path when it appeared that Irrlicht wasn't designed to handle a light prepass renderer at all. Actually Irrlicht is designed to be compatible with a wide range of hardware and software combination (even unaccelerated rendering) and thus does not map very well to a full shader pipeline : for instance, there is no way to use custom vertex attributes in a shader, and texture/framebuffer are limited to GL_TEXTURE_2D. It turned out to be much easier to write a new renderer from scratch instead of patching our copy of Irrlicht (massive) codebase.


The main features of our renderer

See here for more information http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

First STK renders only normals (and soon glossiness) data to a single rendertarget. Light diffuse and specular are then computed used only this buffer, and then the second geometry pass occurs, provided with the diffuse and specular data. This kind of renderer (which is used in Cry Engine 3+) is similar to deffered shading (used in Unreal Engine 4 and Frostbite 2+) but with a different trade off : the bandwidth requirement is lowered as only a single intermediate render target is written to at the cost of an extra geometry pass.

See more information here http://seblagarde.wordpress.com/


Planned features

Links

Retrieved from "http://supertuxkart.sourceforge.net/Antarctica:_Technical_Details"

User Tools