hi everyone,
when it comes to writing a standard shader, i personally think of having just one single shader as a true Phong replacement. Of course this means no shadows, no fancy post fx, just a pure implementation of a physically based BRDF (in this case with a GGX normal distribution function, see patches below).
The main differences to the Phong implementation:
PBR doesn’t really make sense, if you only have one light source (unless you light your objects from environment maps). So we have ONE buffer for all different light types, but instead of introducing a new DX11 buffer, i decided to use the already existing DynamicBuffer(SpotLights) for all lights. This could be a little misleading, but its layout fits our needs in this case.
There is an option to output the result in gamma or in linear color space for further post fx.
I consider normal mapping as very important in a PBR shader, since it might be tightly bound to roughness in many cases.
For anisotropic specular reflections (e.g. on brushed metals), you have to tell the shader, whether your geometry has tangents and bitangents. This also might be a good example for the usage of preprocessor directives.
For the diffuse BRDF you can switch between Lambert and a modified version of the Disney diffuse BRDF. This modification is adopted from the already mentioned “Frostbite”-paper. (Woei posted a link above).
There are still a few comments in the patches, which i consider as important for people who are new to PBR.
Thats’s just my two cents! Anything to add, or even leave out?
ok, i just tested it on 2 different setups, both with b35.8x64 and dx11-1.1 pack:
gtx 980m, win 8.1
gtx 970m, win 10
…and everything works fine on both. The only thing i can think of is, that anything gets messed up with the constant registers, since i use the SIZEOF semantic to get the lightbuffer size. In the patches below i switched to the GetDimensions function. Maybe that helps… otherwise i can’t reproduce this issue right now.
One more thing: I also just noticed, that i can’t load any geometry with the 32-bit vvvversion. GeometryFile (Dx11.Geometry Assimp) stays red. But this might be an issue with the Dx11 pack…