Tasharen Entertainment Forum

Games => Dev Blog => Topic started by: ArenMook on April 17, 2016, 08:02:20 PM

Title: Apr 17, 2016 - Once Upon a BRDF...
Post by: ArenMook on April 17, 2016, 08:02:20 PM
As I predicted in my previous post (http://www.tasharen.com/forum/index.php?topic=14118.0) this week was spent texturing the planetary terrain. Little did I expect to delve as deeply into Unity's graphics as I did though. It was a classic example of "one thing leads to another"...

The week started with me simply writing code to generate cylindrical mapping UVs alongside the vertices in order to get the basic texture stretched over the terrain to see how it looks. It wasn't bad per say, but it wasn't quite good either:

(http://www.tasharen.com/misc/dev70.jpg)

(http://www.tasharen.com/misc/dev71.jpg)

The shadows were way too dark, which makes perfect sense really: there was no ambient lighting aside from the one coming from the milkyway skybox. It was most noticeable during sunset/sunrise. Take the following image for example:

(http://www.tasharen.com/misc/dev73.jpg)

As you can see, the entire terrain is just a black blob. The sky is still fairly well lit, meaning there should be plenty of indirect illumination coming from it that should light the terrain. So the question was, how to address it? Simple solution would be to change the ambient lighting from the space skybox to a color instead, but this approach wouldn't work well because it would give everything a flat, uniform color.

Another approach within Unity is to specify a gradient. This would work well, wouldn't it? Sure would, if the terrain was flat. Perhaps I'm wrong, but I saw no matrix in there that could be set in order to actually transform the direction of the gradient. In other words, since there is no way to choose an "up" vector, this approach wouldn't work either.

The same problem prevented me from using Unity's "default skybox" also. There is simply no way to change the "up" vector.

This leaves just the static cubemap skybox-based approach that I was already using. If only there was a way to update the contents of this skybox in real-time based on what's around the player, right? Well, turns out there is. The legacy approach, which I started with first, was to just render into a cubemap and then use this cubemap in the shader somewhere. It was promising, but unfortunately cubemaps rendered this way don't have mip-maps, meaning LOD downsampling wasn't working. In case you wonder why this is necessary... think of indirect lighting as a very blurry 360 degree photo. If you don't blur it, then you will be able to see reflections of the world instead of soft ambient lighting. In fact, it's that last part -- reflections -- that triggered a thought within my head: what about reflection probes?

Unity now has a feature called reflection probes that you can sprinkle liberally throughout your scene in order to get much more realistic looking reflections on objects in your scene. The way it works is by rendering cubemaps at multiple points in the scene, and then simply blending between them in order to apply more realistic reflections to objects moving through the scene. There is something called "light probe group" as well, but it didn't seem to actually do anything when I tried to use it, and in any case based on what I've read it seems they are geared more toward static scenes.

Reflection probes though -- they are most certainly not limited to being static. In fact, simply adding a probe to a blank scene immediately changes how objects using the Standard shader looks (assuming the material is smooth). Better still, it was possible to sample the reflection probe's cubemap at reduced LOD levels, thus getting that blurry ambient lighting cubemap I was looking for! So that's when I thought to myself: why not just have a real-time reflection probe follow the main camera around, rendering only the really big objects into it, such as the planet (using a simple sphere), its atmosphere, and the skybox itself? The result was immediately promising:

(http://www.tasharen.com/misc/dev75.jpg)

(http://www.tasharen.com/misc/dev76.jpg)

Unfortunately as I quickly learned, there were downsides that ultimately forced to me to write a custom BRDF. In technical terms, BRDF stands for "Bidirectional Reflectance Distribution Function". In more common terms, it's just a function that accepts various parameters related to the material and light and spits out the final color the material should have. Unity 5 started using them and there are 3 different versions available. I tried all 3, but neither had the look I was looking for. The default BRDF was most promising for well-lit scenes, but its handling of specular lighting was just flat out weird. Take this picture for example:

(http://www.tasharen.com/misc/dev78.jpg)

The tops of those hills are all uniform greyish color. In fact, as the sun's angle gets more and more shallow and the specular grazing angle increases, the material becomes more and more washed out and there is no way to turn this off. Take the following 100% black sphere as another example. Albedo and specular are both pure black, and yet when you look at it from a shallow angle to the light, starts becoming brighter and brighter:

(http://www.tasharen.com/misc/dev7d.jpg)

Where is that color coming from? The light -- its specular contribution. But why isn't there any way to get rid of it? Not every material has such strong specular reflections. What about materials like vantablack (https://en.wikipedia.org/wiki/Vantablack) when it's time to create stealth coating? Or the more common case, just to eliminate specular highlights from terrain while leaving them intact on the water like this:

(http://www.tasharen.com/misc/dev7e.jpg)

Worse still, the standard BRDF's ambient lighting comes from what seems to be a static source. That is, if the light moves creating different lighting conditions at run-time, the standard shader-lit materials don't seem to benefit. Take the following sphere placed in a blank scene with the default skybox and a reflection probe set to render only that skybox, for example. I simply hit Play then changed the angle of the light to that of a sunset:

(http://www.tasharen.com/misc/dev7g.jpg)

(http://www.tasharen.com/misc/dev7h.jpg)

The sphere is still lit like it was day time! That's obviously completely unacceptable. Playing around with the settings reveals that the reflections come from the reflection probe and look proper, but the global illumination term seems to come from a static texture of some kind, and as such doesn't change at run-time.

But hey, the best part about the new rendering pipeline is that it's fully exposed to be modified, so I got started on my own custom lighting path. The first thing I did was to simply scrap the "ShadeSHPerPixel" call in my copy of the UnityGI_Base function found in UnityGlobalIllumination.cginc with a call to sample the reflection probe's cubemap. Since I only have one reflection probe and don't plan on having more, I didn't need to do any blending and only sampled the first one:
  1. #if UNITY_SHOULD_SAMPLE_SH
  2.         // BUG: This flat out doesn't work when a skybox-based ambient lighting is used with the skybox updated at run-time
  3.         //gi.indirect.diffuse = ShadeSHPerPixel (normalWorld, data.ambient);
  4.  
  5.         // This gives similar results and also happens to work properly
  6.         float4 diffuse = UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, normalWorld, 0.8 * UNITY_SPECCUBE_LOD_STEPS);
  7.         gi.indirect.diffuse = DecodeHDR(diffuse, unity_SpecCube0_HDR).rgb;
  8. #endif
This gave nice enough results, but just to make it extra blurry and eliminate the visible corners in the cubemap, I wrote code to do instant blurring:
  1. // Fast, imprecise version:
  2. //float4 diffuse = UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, normalWorld, 0.8 * UNITY_SPECCUBE_LOD_STEPS).rgb;
  3. //gi.indirect.diffuse = DecodeHDR(diffuse, unity_SpecCube0_HDR).rgb;
  4.  
  5. // Smoother but slower version:
  6. float3 right = normalize(cross(float3(0.0, 1.0, 0.0), normalWorld));
  7. float3 up = normalize(cross(normalWorld, right));
  8. const float sampleFactor = 0.9 * UNITY_SPECCUBE_LOD_STEPS;
  9. const float jitterFactor = 0.3;
  10.        
  11. float4 diffuse = (UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, normalWorld, sampleFactor) +
  12.         UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, lerp(normalWorld,  up, jitterFactor), sampleFactor) +
  13.         UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, lerp(normalWorld, -up, jitterFactor), sampleFactor) +
  14.         UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, lerp(normalWorld,  right, jitterFactor), sampleFactor) +
  15.         UNITY_SAMPLE_TEXCUBE_LOD(unity_SpecCube0, lerp(normalWorld, -right, jitterFactor), sampleFactor)) * 0.2;
  16.  
  17. gi.indirect.diffuse = DecodeHDR(diffuse, unity_SpecCube0_HDR).rgb;
With the global illumination taken care of, it was time to tackle the specular issues. I took care of that by creating a custom BRDF and extending the output struct's specular color to be a half4 instead of 3 -- that is, I simply wanted to take advantage of its unused alpha channel. In the last part of the BRDF function I made good use of it:
  1.         specularTerm = max(0, specularTerm * specColor.a * specColor.a * nl);
  2.  
  3.         half diffuseTerm = disneyDiffuse * nl;
  4.         half grazingTerm = saturate(oneMinusRoughness * specColor.a + (1.0 - oneMinusReflectivity));
  5.     return half4(diffColor * (gi.diffuse + light.color * diffuseTerm) +
  6.                 light.color * FresnelTerm (specColor.rgb, lh) * specularTerm +
  7.                 surfaceReduction * gi.specular * FresnelLerp (specColor.rgb, grazingTerm, nv) * specColor.a, 1.0);
In simple terms, what this is doing is merely attenuates the specular's strength by the specular color's alpha, thus making it possible to get rid of it completely. It's merely based on tweaking observation to get the results I want. Now, with a simple custom specular shader that uses the texture's alpha channel to control what should be affected by specular highlights and what shouldn't, I was able to get the "custom" results in the screenshots above and below.

The last thing I did was to write a custom fog version that also sampled the same exact diffuse term in order to have the fog be colored by the ambient lighting as well. This created a colored fog that blends much better with the environment around it.

(http://www.tasharen.com/misc/dev7i.jpg)

(http://www.tasharen.com/misc/dev7j.jpg)

I'm attaching the BRDF + specular shader for those that need it.

(http://www.tasharen.com/misc/dev79.jpg)
Title: Re: Apr 17, 2016 - Once Upon a BRDF...
Post by: Bradamante3D on May 02, 2016, 04:13:49 PM
Did you try compiling this under GL Core? Just throwing both files into the Editor on OSX the Console complaines:

  1. Shader error in 'Tasharen/Specular': undeclared identifier 'samplerunity_SpecCube1' at Assets/Shader/Tasharen.cginc(158) (on glcore)
  2.  
  3. Compiling Vertex program with DIRECTIONAL SHADOWS_OFF LIGHTMAP_OFF DIRLIGHTMAP_OFF DYNAMICLIGHTMAP_OFF
  4. Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING SHADER_API_DESKTOP

P.S. If you're on a mission to make those already good looking Forge3D Planets look even better, then please let them now, so that we all benefit :) (I bought them too)
Title: Re: Apr 17, 2016 - Once Upon a BRDF...
Post by: ArenMook on May 03, 2016, 01:41:54 PM
I didn't specifically target anything. I am targeting PC, and I saw no errors with the shader on my end.

unity_SpecCube1 is defined by Unity in UnityShaderVariables.cginc as
  1. UNITY_DECLARE_TEXCUBE(unity_SpecCube1);
Perhaps gl core doesn't include something? I'll leave it up to you to investigate. :)

P.S. As for the Forge3D planets, I don't plan on using them. Everything there is static, defined by textures -- both for the planet's surface and for the atmospheres. Even the day/night transition is done as a gradient. It's fine if you have lots of texture memory to spare and only plan on looking at planets from the outside -- more than fine really since they look fantastic... but it's not suitable for what I had in mind.