1) you can also use normalized-blinn-phong instead of GGX for the D term.
Yes, both produce values higher than 1. The D term deals with energy *density*, not energy, so it's valid range is 0 to infinity.

It's very unintuitive and confusing when dealing with point lights... When dealing with IBL/hemishphere/area lights it makes a lot more sense.
The "mirror" D term would be a "dirac delta function" - an infinitely thin and high peak at one point on thr graph (the reflection direction) and zero everywhere else. When you integrate this over the hemisphere, that infinity goes away and magically turns into a 1.0.

So yes, high numbers are normal here. Integrating over the hemisphere turns those high *density values* back into intuitive values.


As for reference, substance painter has a GLSL implementation, and I guess Unreal4 does too.

2) try making you lights brighter and playing with your tonemapper. If there's super-bright sunlight shining on your face, it will cause a visible reflection of the F0=0.04 floor... But if your face is being lit by a 60W bulb, that reflection will be overpowered by the other lights in the room.

4) to do IBL correctly you need to sample every pixel in the probe (no mipmaps!), treat them all as a directional light source, and integrate the results.
Or more optimally, importance sample (16-64 samples is ok) the probe and do the same.

To optimize this down to a single sample plus a lookup table, read the Unreal 4 (Brian Karis?) course notes on lighting.

4) yes, *pure/clean* metals have no diffuse. Any absorbed light is converted to heat, instead of being reemitted.

If you have dirty metals (grime, rust, etc), then those non-metal contaminants will cause some diffuse.
If using the "metalness" workflow, a greyscale metalness mask allows for this.

As for brightness again, what kind of tonemapper are you using?

Can't say one method looked better than the other, it's just *different* -and therefore confusing!. But since I'm reading GGX is becoming more and more standard, I wonder why one would chose one method over the other...? It sounds a bit weird to me that reflected light becomes stronger, read multiplies with a value higher than 100%.

If you look at the NDF lobe you can see that GGX has a broader "tail" aka falloff which makes it more realistic than your regular blinn-phong.

Take a look at the disney brdf explorer: http://www.disneyanimation.com/technology/brdf.html

This is a comparison taken from a disney paper: (left GGX, right beckmann)

Not sure what you mean by the second part...

If both are properly normalized they should behave the same in the following sense:

Let's say you have X amount of energy hitting the surface. If you have an optically flat surface most of the light is going to be focused on (or around) a small location because it didn't scatter. If you take the same amount of energy but let it hit a very rough surface it means that most of the light is going to be spread about the surface but the amount of energy reflected is still the same. So in that way it makes sense that if you take lots of energy that is spread out and put it together you get a stronger single highlight (However no difference in energy!)

3. to do IBL correctly you need to sample every pixel in the probe (no mipmaps!), treat them all as a directional light source

Importance sampling is a technique that tries to reduce the amount of samples needed by placing random samples in an area (or direction) that is most likely to contain the most important samples. So in the case of IBL you evaluate the probability density function (pdf) of your NDF using a certain roughness value which gives you a direction where the peak of the lobe is located at. But since you're using AMD cubemapgen to generate your IBL probes it should be fine.

Someone correct me if I said something wrong

4. yes, *pure/clean* metals have no diffuse.
All right. And for non-metals, it basically boils down to using 97% (1 - 0.03) of the diffuse (Lambert) light? It's little effort, but I'd say this reduction is barely noticable, right? Just asking to see if I'm thinking straight.

Well it's a cheap approximation for trying to energy conserve your diffuse and specular terms. In most cases it won't be very noticable but you should still do it.

In my experience it can be more difficult dealing with too strong diffuse light (especially with organic materials like skin) than specular so you want to decrease it to make the specular a tad more prominent.

Hah, sounds I'm not too far away from getting the right picture then, though it probably still takes some messing around to get used to Cook Torrance, Energy Conservation, Importance Sampling, and whatsoever.

So blurred (mipmapped) probes for rougher reflections or convoluted probes (both made with AMD CubeMapGen - and the modified version) would allow to do the trick with a single sample? Or a just a few (I found that better looking in the case of blurry/"grainy" reflections)? Either how, one or multiple samples, I should still treat them as incoming point lights right? Thus using the reflected vector or surface normal as the "incoming lightDir" that goes into the Cook Torrance / BRDF calculation.

Having the probes in HDR already fixed some of the problems. I first saved them as DDS - DXT3, but unless I'm mistaking, that gives only 8 bits per pixel. Anyhow, either the whole room reflected like mad, or there was barely any reflection. Which made me wondering about the Fresnel, Specular calculations, and how to get a better degree of "artistic control". Everything can be made as parameters of course, but it's a bit against the PBR way of working, plus my G-Buffers only allow a few parameters.

But since I want DXT compression for the probes nevertheless (otherwise a single 256x256 cubeMap already eats a couple of MB) I ended up using a maximum of "4 (x 256)" as a maximum, and divided the pixels colors with 4. Less accurate of course, but its probably acceptable due the blur and everything. A more precise option could be using the alpha channel as a multiplier, but I'm already using that for other purposes.

The Tonemapper might need some improvement as well. Another issue I had was the skybox, which was about 30 times brighter than the indoor-part of the room. Thus either a very dark room, and/or bloom all over the place via the window. Now the skybox can't exceed a value of 4 either. Still too bright/blurry for a cloudy sky, plus I wonder if I'm not reducing way too far, compared to real-life light intensity values.

Thanks!

3. to do IBL correctly you need to sample every pixel in the probe (no mipmaps!), treat them all as a directional light source
Holy Macaroni. Sounds expensive. Especially when sampling from 2 IBL's at the point they start overlapping.

I'm not familiar with Importance Sampling, but would that mean I'll take a bunch of samples into a certain direction, and base the "spread" factor on the surface roughness (narrow beam of rays for smooth surfaces, scattered beam for rough)?

Yeah, but this is not a realtime technique This is more of a "ground truth" technique that you can use to validate that your realtime approximations are pretty close to being correct.
In my engine, I can switch from "realtime specular" to importance sampling, to compare how well my shaders are performing compared to a more accurate result (but the framerate falls through the floor when you turn this mode on!).

Monte-carlo sampling is where you pick directions completely at random (or at the extreme, pick every direction/pixel in your cubemap!), treat them all as a directional light, and then average all the results together. This gives you the true answer, but is impractically slow.
Importance sampling is where you get a bit smarter when picking sampling directions -- yep, a tight cone for smooth surfaces and a wider cone for rougher surfaces (this cone math is based on your probability density function, which is based on your D term). Instead of simply averaging all the results though, you need to do a weighted average, where each sample's weight is it's probability density. If done correctly, this will also give you the true answer, but with less samples.

Either how, one or multiple samples, I should still treat them as incoming point lights right? Thus using the reflected vector or surface normal as the "incoming lightDir" that goes into the Cook Torrance / BRDF calculation.

No. This will give you the wrong answer.
When doing one of the many-samples algorithms, each and every ray/sample as a different result for D, F and G.
e.g. For rough surfaces at glancing angles, the samples are in a wide cone, so while some rays will have F=100%, it's impossible for every ray to have F=100%. This means that when averaging together the lighting results from all your different rays, you can't get super bright glancing/Fresnel highlights on rough surfaces, as the average ray will have F<100%.

If you only compute a single ray, but still run it through the whole Cook Torrance (DFG) formula, then your results will be completely out of whack -- e.g. it's possible that F=100%, even though as above, this is impossible for a rough surface.
Also, even though the D term can be >1, when averaging together many many rays from different directions, the D term will average out to something much closer to 1. This averaging is basically integration, a.k.a. finding the area under the curve.

That's what I meant before that a mirror can have D=Infinity, yet still only reflect 100% of it's input brightness. If you integrate a "delta function" (a function that is zero everywhere, except one point, where it is infinity), you can get a nice sensible result such as 1.0!
Likewise, if your specular function is a bell-curve with a peak of 60000, if you integrate that curve over the domain of the funciton, you might find that the area under the curve is 1.0.
Basically -- if you pick a single "representative" direction for env-map lighting (IBL), and then use that single direction in the Cook Torrence function, your result could be 10000 times too bright!

So, what Unreal does is -- when pre-blurring their cube-map into the mip-maps, they evaluate the D term at that point in time. The D function actually just becomes the weights for their blurring function! This represents pre-integrating the lighting using the D function. This is what CubeMapGen and Lys do for you.
They then build a 2D look-up-table that contains the results for the F and G functions (based on view direction, roughness).

At runtime, they then take a single sample from the cubemap (mip based on roughness), and a single sample from their look-up-table, and the result is a pretty good approximation for the true DFG result (where "true" == "the actual average of lots of rays").
At runtime, they only use the actual Cook Torrence / DFG math when evaluating analytical lights (point/spot/etc); everything is pre-computed for image based lights.

But since I want DXT compression for the probes nevertheless (otherwise a single 256x256 cubeMap already eats a couple of MB) I ended up using a maximum of "4 (x 256)" as a maximum, and divided the pixels colors with 4.

You can also try using a power funciton to compress HDR into 8bits
e.g.
decoded = pow(cubeSample, a) * b;
encoded = pow(original / b, 1/a);

I first saved them as DDS - DXT3, but unless I'm mistaking, that gives only 8 bits per pixel

You should make sure to keep your HDR data in tact as much as possible. I capture my scene as R16G16B16A16 and store it using BC6H_UF16 (unsigned), which is compressed half precision float 16bit hdr format.

https://msdn.microsoft.com/en-us/library/windows/desktop/hh308952(v=vs.85).aspx

You can use the DirectXTex library to do that for you: https://directxtex.codeplex.com/

@Hodgman

Thanks again man, gonna try your advices tonight or tomorrow!

@Lipsryme

The compression sucks indeed, but I'm afraid I don't have much of a choice with OpenGL (afaik, it only supports DXT1 / 3 / 5). It's either huge files or compressed stuff. Then on the other hand, since most reflections are pretty blurry or distorted due normalMapping, you won't notice that quickly. Maybe like Hodgman said, using a pow instead of a multiplier gives a bit more detail in the (more common) lower color ranges.

@Frenetic Pony

Thanks for the papers. Don't know if its due pointlights, bad input from the HDR probes, faulty normals in the G-Buffer, or remaining bugs in the Cook Torrance code, but indeed my head sometimes explode when taking a look at glancing angles, or giving a look at a badguy pixel.

I probably got stuck in the past with ancient shader-code, but with a pointlight, you mean all light comes from a single (infinite small) point in space right? Thus, feeding your formula with a single position. Which is what I do for omnilights ("point lights" in my dictionary) & spotlights. Didn't read the papers yet, but do they suggest to sample from multiple points, or make adjustments in the formula? I mean, we should be able to using omniLights right?

afaik, it only supports DXT1 / 3 / 5

DXT1/3/5 are also known as BC1/2/3. To access BC4/5/6/7, you can use ARB_texture_compression_rgtc and ARB_texture_compression_bptc.
Or alternatively, just don't compress your HDR probes

all light comes from a single (infinite small) point in space right?

If you have access to it, the "Real Time Rendering" book has a good chapter on lighting and radiometry and the BRDF. The way they explain it, you see that it only makes sense when talking about areas and cones (not infinitely small rays and points). If you have any amount of energy contained in an infinitely thin ray, then you end up with infinite energy-density and your rendering code explodes
But... as you know, traditional game lights have always been infinitely small points! It turns out that we've been using a dodgy work-around... an approximation of the real math that gives us somewhat sensible results when dealing with physical impossibilities, such as point lights
I personally found it very enlightening to learn how to do realistic area lighting first (with the full integration), and then take the next step of simplifying that real math down to the point lights approximation myself... to basically re-learn how to do point lights, but this time coming from a physics starting point.