About Me

Hi. I'm Josh Ols. Lead Graphics Developer for RUST LTD.

Contact:
crunchy.bytes.blog[at]gmail[dot]com

View Joshua Ols's profile on LinkedIn

Meta

Entries in Physical BRDFs (5)

Sunday
Feb262012

Physical Glass/Gem Prototype

UPDATE:

I figured I should be nice and at least give you guys some details. This technique is SM3.0 compatible, and doesn't use alpha blending. :)

Original:

I just wanted to show off a test shot from my new physically-based material system that takes full advantage of Unity 3.5's features (ie. Linear HDR pipeline, Directional Lightmaps, Light Probes). 

The particular focus of this shot is my experimental physically-based glass/gem shader. In this scene, you can see two dynamic lights on all the objects, plus baked lighting to fill out the rest of the scene. Please forgive the programmer art, as this is still early and experimental. 

Hope you enjoy it! ;)


Prototype Physically-based Glass Shader

PS. I will give a proper breakdown of the technique in the future, after my team's game project has released.

Saturday
Aug272011

Dice Poker Game (CANCELLED)

[Unity3D, RSRM] Dice Poker prototype

Unity3D Web Demo

Art and game behavior courtesy of Anton Hand.

 

Instructions:

Click ring to drop dice in box.

Click chips around box to chuck chips in center.

Click button in upper left to reset ring.

 

UPDATE:

This demo will only work for SM3.0 level GPUs. If you attempt to use it on an earlier generation GPU, you will just see black on all the geometry that is using the RSRM shader.

 

Situation:

If you were wondering why I haven't posted much lately then please allow me to fill you in on the details. Recently, I tried getting my Physically-Based Rendering (PBR) tech into Unity3D, with surprising success. Having gotten this working in a prototype, my artist friend set out to build a game using this new tech. Sadly, the project encountered some complications, and ultimately had to be cancelled.

 

Despite this, the prototype is in a state where the basic functionality is working. So I have decided to re-purpose it as a tech demo, which you can access via the above link. Please check it out and leave some feedback about the visuals in the comments section. ;)

 

Results:

The prototype shader used for this demo was single-pass forward rendered using two fake directional lights and a Radially Symmetric Reflection Map (RSRM). The scene itself also has SSAO, Bloom, and FXAA just to top it off.

 

The results are slightly incorrect due to my misunderstanding of the need to plug the BRDFs into the Punctual Light Equation and cancel some terms out. As a result, the specular ended up too bright, and fresnel for RSRM gives too much rim for rough surfaces. So while it is significantly better than the current standard of Phong & Blinn Phong lighting models, it still falls short of what I wanted to achieve.

 

Currently, I am working on an improved version that will correctly integrate with Unity3D's forward multipass lighting system. It will correctly accumulate the lighting in an FP16 target in linear space, then receive tonemapping before being passed to the rest of the pipeline. I will also being improving upon the built-in Bloom, SSAO, and Depth of Field effects to really sell the effect.

 

Keep your eyes peeled for future updates! ;)

 

Other Updates:

Other than this, I am currently working on a revised RSRM article, to centralize all I have learned in an easy to reference article. It will also detail the PBR BRDF I have chosen for my project, including strengths and weaknesses. Finally, this will provide a good opportunity for me to clear up some incomplete and flat out wrong information from my old articles.

 

Other than that, I've also made a small update to my Partial Derivative Normal Map (PDN) article. Basically, I found an optimization to use a MADD to save an assignment, shaving off another instruction from the recovery equations.

 

Hope you will find them useful. :)

Tuesday
Jan252011

SSAO & RSRMs

Now that I've got Radially Symmetric Reflection Maps (RSRMs) figured out, it's time to tackle the rest of my ambient lighting solution. So the next logical step for improving lighting quality is to introduce Ambient Occlusion (AO). As my plan is to go the route of deferred shading, the natural choice for getting the best visuals is Screen-Space Ambient Occlusion (SSAO).

 

SSAO:

My long-time readers might recall that I have touched on this topic before, getting acceptable results for the time. However, I recently came across a new implementation that is both cheaper and more visually pleasing than my previous choice. For implementation details, check out the gamedev.net article "A Simple and Practical Approach to SSAO".

 

Here you can see the results I got when I combined this technique with RSRMs. In each shot, the AO is correctly applied to just the ambient diffuse & specular contributions. The direct lighting is currently unshadowed, so it is not as good as it could be.

 

Implementations:

[RSRM, SSAO] ssao only [SSAO] ssao, old implementation

Figure 1. 1, New; 2, Old

(Model by Ben Mathis)

 

Results:

[RSRM, SSAO] Ambient diffuse w [RSRM, SSAO] Ambient diffuse wo [RSRM, SSAO] Ambient specular w [RSRM, SSAO] Ambient specular wo [RSRM, SSAO] composite w [RSRM, SSAO] composite wo

Figure 2. 1, Diffuse w; 2, wo; 3, Specular w; 4, wo; 5, Composite material w; 6, wo

(Model by Ben Mathis)

 

Future Plans:

As nice as SSAO can look, even the cheapest implementation can still be a performance hog even on newer hardware. So for older GPUs I will likely be using a textured AO fallback, with min blending to combine model and detail AO maps. It may not look as good, but AO in any form is still a huge step up from no AO at all.

 

Sorry for the delay folks. That "real life" thing has a habit of getting in the way of my leisure activities. :p

Sunday
Nov072010

Radially-Symmetric Reflection Maps

Update 1:

I decided to add some extra screenshots to illustrate how the raw diffuse and specular components map to the complex model used for the material tests. Please note, they use a slightly different RSRM, but the results are consistent with one used for the original article.

 

Update 2:

For any late readers, I've since added an article expanding on this topic (RSRM Enhancements).

 

Original:

After much deliberation, I have decided to drop Lighting Volumes from my renderer in favor of a more dynamic lighting system. In fact, I have opted to use a piece of tech I tried to implement ages ago, but only recently got working. I am of course refering to Radially-Symmetric Reflection Maps (RSRMs), the Image-Based Lighting (IBL) technology used by the game Brütal Legend.

 

So, just what are they? Well, I can't tell you all the details, since the official document & video are only available by purchasing them from ACM. What I can tell you is that they combine Chrome Mapping with Prefiltered IBL, and hope that you can figure out the rest. However, simply knowing how to make and use them is only half the problem. Using them requires a fundamental shift in your thinking about lighting towards a Physically-based Shading paradigm.

 

Physically-Based BRDFs:

Following the presentations linked in my prior post, I found out that traditional ad-hoc shading models have been getting it wrong for a long time now. Things like diffuse lighting being too bright, specular lighting being too dark, specular color being completely incorrect, etc. In order to make my lighting and materials mesh well with prefiltered IBL of any kind, I had to make a few changes.

 

Firstly, my analytical lights' diffuse term needs to use the Lambertian BRDF, which effectively boils down to multiplying it by 1/PI. This may not seem like much, but it make a big difference. The most common symptom of getting this wrong is that most materials' albedo textures end up being much darker to get good looking results.

 

Secondly, my analytical lights' specular term needs to use Normalized Phong. This ensures that the specular highlight's intensity gets darker/brighter as its distribution increases/decreases. The typical consequence of this being wrong is that specular color maps have to modify intensity in a way that corresponds to specular power. Often, this can require that the specular color map have multipliers to exceed the range [0,1].

 

Thirdly, specular color itself is a farse, and doesn't match up with reality at all. Instead, materials need per-pixel, per-RGB fresnel cooefficients that determine the substance of the material. Then specular power maps, more correctly called smoothness maps, can control the distribution of a specular highlight to make it more blurred/sharp. By doing it this way, artists can use real-world fresnel values to define the substance of a material, then adjust the smoothness without changing that substance.

 

Finally, just a few little concerns, like ensuring that my albedo & fresnel data produces energy conserving materials. Also, ensuring that metals and semiconductors have an albedo of zero since they absorb all diffuse lighting. If you want to learn more, please refer to the presentation links in my prior post.

 

Having taken all that into account, let's see what we get with RSRMs!

 

Lighting:

By itself, an RSRM's diffuse contribution looks like a Hemisphere Light, but having more color variation toward the center of the sphere. Once we add a Directional Light, it suddently gains more detail and becomes a passable source of illumination. As for the specular lighting, again it is essentially Chrome Mapping with more variation. It may not sound like much, but let's see how it looks in practice.

 

What follows are a series of example materials, including one that uses per-pixel albedo, fresnel, and smoothness data to have metal embeded inside plastic.

 

Maps:

[RSRM] Input[RSRM] linear  

Figure 1. 1, Input; 2, Output

 

Shading Components:

[RSRM] _diffuse (map)[RSRM] _diffuse (map+drectional)[RSRM] _specular (m=2)[RSRM] _specular (m=10)[RSRM] _specular (m=50)[RSRM] _specular (m=100)

Figure 2. 1, Ambient; 2, Ambient +Directional; 3, Specular (m=2); 4, Specular (m=10); 5, Specular (m=50); 6, Specular (m=100)

 

[RSRM] Hebes (diffuse, map)[RSRM] Hebes (diffuse, map+directional)[RSRM] Hebes (specular, m= 10)

Figure 2.5. 1, Ambient; 2, Ambient +Directional; 3, Specular (m=6)

 

Materials:

[RSRM] Hebes (plastic, m=6)[RSRM] Hebes (glass coating, m=255)[RSRM] Hebes (silicon, m=6)[RSRM] Hebes (iron, m=6)[RSRM] Hebes (copper, m=6)[RSRM] Hebes (gold, m=6)[RSRM] Hebes (aluminum, m=6)[RSRM] Hebes (silver, m=6)

Figure 3. 1, Plastic; 2, Glass Coating; 3, Silicon; 4, Iron; 5, Copper; 6, Gold; 7, Aluminum; 8, Silver

 

Per-pixel Fresnel & Smoothness:

[RSRM] Agusturinn [front][RSRM] Agusturinn [left][RSRM] Agusturinn [back][RSRM] Agusturinn [right]

Figure 3. 1, Front; 2 Left; 3 Back; 4 Right

(Model by Ben Mathis)

 

Conclusions:

Despite the simplicity of the technique, the results are surprisingly good. RSRMs are efficient to author and bake, and require little in the way of storage. Since I do not require photorealism, they produce excellent IBL results that will work well as my ambient lighting solution. Now I just need to add translucent sun shadows and SSAO to really improve the results. ;)

Sunday
Oct102010

Deferred Physical Shading

This year's SIGGRAPH had an interesting segment covering Physically-based BRDFs, that offered some sobering insights into the problems of traditional realtime lighting models. Particularly, how current models not only produce less believable results, but force artists to waste time and effort compensating for their definciencies. Naturally, they explained how to derive better lighting models that behave more realistically, and offered some insights into the behavior of real-world materials.

 

Links:

[1] SIGGRAPH '10: Physically-Based Shading Models in Films and Games

[2] Practical Implementation of Physically-Based Shading Models

[3] Crafting Physically Motivated Shading Models for Games

 

Implications for Deferred Shading:

The difference that concerns me most is that the Physically-Based BRDFs rely on Fresnel terms for both their diffuse & specular calculations. Specifically, how these Fresnel terms require the per-light Light Direction & Half Angle vectors. So in a Deferred Renderer, each object's material's Fresnel coefficients must be stored in the G-Buffer so that they can be available for the lighting phase. Also, for materials that use per-RGB Fresnel coefficients, I would need to be able to accumulate colored specular lighting.

 

These conditions present problems for trying to integrate such a system into a Light Pre-Pass (LPP) renderer. At a minimum, I would need to add single or per-RGB Fresnel coefficients to the already overcrowded G-Buffer. So I really have no choice but to add another render target to the G-Buffer. Then per-RGB fresnel would force me to have a dedicated specular light accumulation buffer, rather than using the approximation trick.

 

Conclusions:

Ultimately, these changes would make the LPP renderer more bloated than a standard Deferred Renderer. So if I wanted to start using a Physically-based BRDF, I would have to make the switch. Now I'm at an impasse, because my initial tests have demonstrated enough of a visual improvement to peak my interest. This has left me with much to consider before I can proceed.