FreeGameDev

This looks really impressive to me.

https://github.com/zauonlok/renderer

Frame rate is not great on PBR stuff when zoomed in, but even so, as a sheer programming feat, I find this thing to be *incredible*. Code looks really nice from what little poking around I've done. Runs on linux, mac, Windows. On linux, it uses xlib (no SDL or other esoteric dependencies that I saw). It's MIT licensed. Maybe I can work up the brainpower to finally look into PBR. Oh, it also does shadow mapping, (another thing that has so far eluded my grasp.)

(PBR == physically based rendering)

* It's a software renderer. The problem with software renderers is the fill rate. It wasn't an issue when everyone was running at 800x600 but now with 4K displays it's no longer practical.

* It's Blinn-Phong rather than GGX, which is fine but ehh...

I'm impressed by the concept. Not a fan of the Python or the idea of actually doing things this way however. Better starts on PBR would be learnopengl.com and especially the PBR book, which is now freely available as a website.

Trying to figure out WTF GGX means is not very satisfying.

As Shakespeare said, what's in a name?

smcameron {l Wrote}:Trying to figure out WTF GGX means is not very satisfying.

You may find this helpful

This is a GGX distribution function taken from [1]:

{l Code}: {l Select All Code}

float DGgx( float NoH, float roughness ){
   // Note: Generally sin2 + cos2 = 1
   // Also: Dgtr = c / (a * cos2 + sin2)
   // So...
   float Krough2 = roughness * roughness;
   float denom = 1.0 + NoH * NoH * ( Krough2 - 1.0 );
   return Krough2 / ( PI * denom * denom );
}

Where NoH is the dot product of the normal and the light angle (argh no not if it's image-based) and roughness is the value from the roughness texture, it returns...something. I understood the math a couple weeks ago before I switched to a 2D project and it's hard to return to this stuff. My point is that the metallic/roughness pipeline is standard, so when it comes to "glossy" and "tail" values you may not be going with current best practices. Generally the main parameters are metallic (the F0 from dielectric to mirror-like) and roughness (how rough the surface is). [2]

In most simple implementations, F0 (derived from the metallic texture) just interpolates from the fully-rough calculation to the fully-mirror-like calculation. In the case of image-based lighting, a pre-blur is usally applied to a copy of the environment map (though not in [2]; Trent likes to stay on the cutting edge). This is known as the split sum approximation; an approximation because the blur is omnidirectional and thus loses sharp grazing non-metallic specular reflections. So you have a couple of environment/cube maps for your shader to choose from depending on how diffuse light should be at any given point. The return value from the GGX function helps the shader determine exactly how diffuse the reflection should be at the fragment, from fully blurred to a perfect mirror.

As for what makes GGX different from Blinn-Phong and other older distribution functions, GGX just does more math and is better.