Here is a new experimental set of shaders with HDR.
I have looked into the implementation of HDR and one problem is that a floating point backbuffer has no limitations in a dynamic range but the image still needs to be "composed" to a range form 0.0 to 1.0 before it can be visualized on a screen.
One solution could be a normalization of a color:
out_color = color / max(1, max(color.r, max(color.g, color.b)));
This has at-least following benefits:
- No changes required to current textures or materials
- Perfectly linear
- Any bright pixel going above 1.0 will retain it's original color. No color shift towards white.
An other HDR related issue is a brightness difference between white lambertian surface and metallic surface. In a literature a BRDF's are usually defined as
F() = d/PI + s, where the diffuse term is divided by PI. For simplicity, I have multiplied the specular term by PI. Sun light intensity and specular multiplier can be defined from LightBlur.hlsl In the current implementation, Earth's atmospheric intensity does not go beyond 1.0 and no changes are being made there anytime soon.
So, is that actually fact ? White lambertian surface would reflect 1/PI less light than mirror to optimal direction ?
PHP:
// Other configurations ------------------------------------------------
//
#define fSunIntensity 1.0 // Sunlight intensity
#define fSunSpecular 3.14 // Specular multiplier
Also, the specular/reflection color has been changed from RGB to sRGB color space. It's approximately RGB = pow(sRGB, 2.2) however the current approximation pushes it little further down to RGB = pow(sRGB, 2.0) to reduce computation costs.
Based on how I have understood the concept of micro surface roughness, 1.0 = mirror smooth and 0.0 = lambertian surface (i.e. diffuse only). So, any roughness approaching to zero will also reduce specular/reflection color to zero. Also, Ward's BRDF doesn't work with very rough materials.
Martin mentioned a word "release candidate" in a beta thread and there is a new video published without "Beta" text in a splash screen. So, I guess it's better to start focusing building a stable release pretty soon. So, it's probably not a good idea to start pushing the HDR any further at this point. (i.e. beyond meshes and post processing)
I don't really like very large and complex shaders, so, it might be good idea to split the shaders to a basic shader (i.e. PBR.fx) and an advanced shader that would support more textures and features.
Rendering tasks for a basic PBR.fx:
* All non-textured objects
* Textured objects with
- Normal map (_norm)
- Roughness map (_rghn)
- Reflection map (_refl)
- Emission map (_emis)
For advanced shaders: (to be implemented later)
- Specular map (_spec)
- Translucence map (_transl)
- Transmittance map (_transm)
- Anisotropic roughness map (_anis)
The next thing to do is to implement local light sources in a per pixel basis. This would likely mean that:
- Number of active light sources per scene could increase to 16 or 32
- Number of active light sources per mesh or mesh group would reduce down to 8 or 4 based on performance settings.
EDIT: Also, since the taste of post processing seems to wary, we could have a combo-box selector in a launchpad from where to change the effect. Which would allow to distribute multiple variants with the client.
.