Drag[en]gine Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>graphic pbr hdrr rendering}}
<WRAP youarehere>
[[:start|Start Page]] >> [[:gamedev|Game Development with the Drag[en]gine]] >> **Physically based Rendering**
</WRAP>

====== Physically based Rendering ======

For a much more in depth discussion about the topic of using physically based rendering in games see the [[http://renderwonk.com/publications/s2010-shading-course/|SIGGRAPH Course Notes]] especially the course notes and slides about //Physically-Based Shading Models in Film and Game Production//. Another source of information can be found in a blogg post about [[http://seblagarde.wordpress.com/2011/08/17/hello-world/|adopting a physically based shading model]]. This page here contains only the important parts to understand the PBR as used in the Drag[en]gine.

====== Rendering Methods ======

There exist various rendering models that can be used to render computer graphics. Nearly all of the rendering in games is using a sort of **ad-hoc rendering method**. These are rendering methods that contain parameters in the rendering equations that are **interlinked** and/or **unintuitive to use**. These game engines or rendering engines expose some kind of **specularity** value typically paired with some kind of **exponent** parameter. The specularity represents in these systems the strength of the specular reflections of light sources on a material. The expoonent on the other hand defines the shape of the specular reflection. A well known method is the Phong rendering in which the specular exponent is of a cosine form whereas the specularity is a percentage value between 0% and 100% of the light added as specular reflection. The main problem with these systems is that in reality the speculiarty and exponent values vary across the material for different **viewing directions** as well as different **lighting conditions**. One set of parameters tuned for one lighting condition does usually not work well at all for an entirely different lighting condition. This is due to the fact that for different lighting conditions these parameters have to adjusted. This is though neither feasible to do nor is it easy for the artist. What is the proper specular exponent to use for a model? And what is the correct specular reflection strength to use? Answering these questions for an artist is a problem in many cases. In the end these Ad-hoc rendering methods result in artificial renders and artists having to adjust lighting parameters whenever the lighting conditions change in a scene.

<WRAP center round tip 80%>
One of the important goals of Physically Based Rendering is to remove these problems from the production pipeline. For this **intuitive** and **physically based** parameters are introduced that are **robust under different lighting conditions** and easy to use for artists. The artist is supposed to be able to create materials without having to back-track into the game all the time. Furthermore Graphic Modules are allowed to use whatever rendering method they see fit.
</WRAP>


====== Microfacet BRDF ======
The basic idea is to replace the Phong style Ad-hoc rendering methods with a new method that is based on a **Microfacet BRDF**. BRDFs are coming from the ray-tracing domain and describe a distribution function that ensures as much light exits a point that enters it. Sounds logic but the violation of this simple rule is one of the main problems with Ad-hoc methods. The Microfacet BRDF is such a distribution function based on the model that a surface is broken down into **tiny mirror segments**. Each of these mirror segments is a **fully reflective mirror**. This allows to work with probability functions instead of having to figure out a function able to handle all kinds of materials. To put simple for a glassy object the probability of all mirrors to be aligned is very high while for a totally diffuse object the probability for mirrors to be aligned with the surface normal is next to zero. Obviously if the mirrors are misaligned the reflection is very blurry while for the aligned case it is sharp. For the killer math you can check out the links mentioned above. For an artist and game developer though it is only important to understand what all this boils down to in terms of rendering parameters.

====== Fresnel ======
<WRAP box 200px right :en>
{{ :gamedev:pbr_fresnel.png |Fresnel effect on grazing angles}}
<WRAP centeralign>Fresnel effect on grazing angles</WRAP>
</WRAP>
In the Ad-hoc methods lighting is typically split up into a **diffuse** and a **specular** term summed up. Diffuse lighting contribution usually comes from **Subsurface Reflectance** while specular reflections comes from **Surface Reflectance**. Whereas in Ad-hoc methods theres two quantities are not always summing up properly to 1 they do in the Microfacet BRDF case. This is required as otherwise the entering and exiting light would not be the same. To achieve this the Microfat BRDF uses the **fresnel effect**. If you look at a round object made of polished plastic you will notice how the reflection of the environment at a surface point pointing straight at your face is rather low while towards grazing angle the reflection is nearly mirror like. The proper use of this Fresnel Effect is important to ensure the correct distribution of light contribution between the Surface and the Subsurface Reflectance. All materials exhibit this Fresnel Effect at grazing angles even dull materials like concrete. The difference is only that the surface is so rough the reflection at grazing angle is too blurry to recognize it as what it truely is. Artists do not have to alter the fresnel parameters as there exist better parameters that offer more intuitive control. Messing with Fresnel Factors is only a source of problems.
<WRAP clear></WRAP>

====== Material Parameters ======
One of the interesting properties of the Microfacet BRDF is that the **individual functions** used to build up the entire BRDF can be **exchanged and mixed** from a large pool of existing functions. All of them though exhibit some sort of speculiarity and roughness parameter although their actual values do vary, To make the life of artists easy while still allowing Graphic Modules to choose whatever combination of BRDF function pieces they like three generic parameters have been defined: Color, Reflectivity and Roughness. These values are **decoupled** in contrary to the Ad-hoc version. Due to the decoupling the individual appearance properties can be modified while keeping the result **consistent across all kinds of lighting conditions**. The individidual texture properties linked to these parameters contain detailed information.

===== Color =====
represents the Subsurface Reflectance of a material. This is often called the **diffuse reflection**. The **[[gamedev:textureproperties:color|color]]** texture property represents this parameter and contains more information about it.

===== Reflectivity =====
represents the Surface Reflectance of a material at 0-degree angle or in other words for a surface point looking straight at you. In contrary to the color the viewing angle matters for the reflectivity. Towards grazing angles the reflectivity moves towards 1. The **[[gamedev:textureproperties:reflectivity|reflectivity]]** texture property represents this parameter and contains more information about it. 

===== Roughness =====
represents the alignment of mirrors on the surface. This determines hw sharp the reflections are and thus how broad the specular hightlight is. This parameter is the most complicated one because the different BRDF function possibilities for the Surface Reflectance have all kinds of roughness parameters going from 0 all the way up to infinity. For an artist this is not easy to use. For this reason a special definition has been created with a generic roughness parameter in the range from 0 (mirror) to 1 (fully diffuse) with a gradual change from mirror to diffuse. This way the Graphic Module can decide itself what BRDF function to use and maps the roughness parameter itself. The **[[gamedev:textureproperties:roughness|roughness]]** texture property represents this generic parameter and contains more information about it.

===== Dielectric and Metallic Materials =====
<WRAP box 150px right :en>
{{ :gamedev:textureproperties:reflectivity2.png |Gold reflection (metallic)}}
<WRAP centeralign>Gold reflection (metallic)</WRAP>
</WRAP>
<WRAP box 150px right :en>
{{ :gamedev:textureproperties:reflectivity.png |Paint reflection (dielectric)}}
<WRAP centeralign>Paint reflection (dielectric)</WRAP>
</WRAP>

In games materials can be classified roughly in two main categories: dielectric and metallic. Metals have the disticntive property that they have next to no Subsurface Reflectance (**[[gamedev:textureproperties:color|color]]**) but a rather high Surface reflectance (**[[gamedev:textureproperties:reflectivity|reflectivity]]**). On the other hand for all other materials including crystals that are dielectric the situation is vice versa. They have very little Surface Reflectance (**[[gamedev:textureproperties:reflectivity|reflectivity]]**) but instead all their glory is in the Subsurface Reflectance (**[[gamedev:textureproperties:color|color]]**).All these materials, no matter if dielectric or not, have in common that the component wise sum of the Surface (**[[gamedev:textureproperties:reflectivity|reflectivity]]**) and Subsurface Reflectance (**[[gamedev:textureproperties:color|color]]**) does not exceed 1. Also all these materials have at least 2% F0 reflectivity even if they are fully diffuse. This is a main difference towards Ad-hoc methods where most objects do not reflect their environment. With physically based rendering all objects even the most matte one have a slight environment reflection.

<WRAP center round important 80%>
Using these decoupled parameters the artist can alter the individual material properties in a way that it is consistent across various lighting conditions. Put simple the artists can create materials without requiring to know about what kind of lighting condition the game uses. He can create the material once and it will just work no matter if at night, at day or in a phychodelic dream world. The artist does not have to go back and forth testing his materials. This increases productivity and reduces frustration.
</WRAP>
<WRAP clear></WRAP>

===== Lesser and more intuitive Texture Maps =====
Another advantage of these texture parameters is the reduction in texture authoring work. With Ad-hoc methods one needs a color texture, a specular color texture, some kind of glossiness texture and potentially exponent, fresnel and other parameters to fix lighting problems. With the physically based rendering system an artist only really needs to create a color texture and a roughness texture since reflectivity is most of the time a constant for the same material. Physically based rendering makes the life of game developers and artists easier as changing lighting conditions won't break the created materials which is especially a pain if you have to redo all textures.

<WRAP center round important 80%>
The importance shifts thus from authoring two or more textures (specular color, glossiness, exponent) of unintuitive parameters working at only one lighting condition to one roughness texture with an intuitive parameter. If metallic and dielectric materials are mixed in the same texture an optional simple, lower resolution reflectivity texture can be created. This texture is quick to do and can be small. Furthermore the same roughness texture works even if the material shifts from being metallic to dielectric or if lighting conditions change. This is a net reduction in texture authoring time and disk space.
</WRAP>

====== But I'm not making a realistic game! ======
Some game developers or artists might now ask why they need a physically based rendering system if they want to make a non-realistic fanatasy game or sci-fi game. Physically based rendering is a system to define materials using realistic parameters. This does not prevent you from creating unrealistic and fantastic materials. Imagine a director on a movie set creating a fantasy movie. He needs now a box made of some fantasic material HabbleBabble. How does he communicate to his prop maker what this box looks like? Does he tell him it looks like HabbleBabble? Most probably not as this is not much of use. Instead he could tell the prop maker that the color looks like alge while having a glossy look like piece of chrome metal while being slightly irradiating a green glow in the darkness. As you can see he is using real world materials to describe what this HabbleBabble is supposed to look like. Physically based rendering is doing the very same. It provides artists with a set of parameters they can pull from the real world (using tables and charts from the texture properties for example). Thus if you can describe it using real world materials you can recreate it in the game without much problems.

<WRAP center round tip 80%>
Physically based rendering is thus foremost about **reducing the material parameters** artists and game developers have to deal with to a small set of **intuitive**, **stable** yet **versatile** parameters they can take from real world materials. This improves productvitiy and simplicity of material creation no matter what lighting conditions the material is used at later on. Physically based rendering makes the life of game developers and artists easier allowing them to better create their visions in less time.
</WRAP>

====== Example Materials ======
Images of some example materials can be found in the **[[gamedev:pbr:examplematerials|Example Materials Preview]]**.
Drag[en]gine Wiki

User Tools

Site Tools

Page Tools
