Background

I've been developing a physically-based shader framework for Unity3D. I am using the Normalized Blinn Phong NDF, and an approximation to the Schlick visibility function. I am using an effective specular power range of [4,8192] for direct illumination. I have also developed a translucent shader that uses premultiplied alpha to only make the diffuse translucent while preserving the specular intensity based on fresnel.

For all my testing, I am doing everything in Linear HDR mode which affords me an FP16 render target for my camera.

Situation

So this is a highly contrived scenario, but my team's artist managed to make it happen. Basically he has a scene with a directional light whose intensity is effectively 1.0 (0.5 input for Unity) shining on a glass bottle surrounding a smooth metallic liquid. As a result, the two substances' highlights overlapped and their combined intensity seems to have exceeded the range of the FP16 render target. This resulted in weird artifacts where the the highest intensity color component went to black, while the other two just looked really bright. (see example image below).

Upon further testing, I found I could remove the artifact by making the surface more rough, thus reducing the intensity of the highlight. However, I still found it having this visual error for even relatively rough overlapping materials.

Questions

1.) Is there any way to prevent this from happening programmatically without having to clamp the light values to an upper limit or otherwise harm the visual quality?

2.) Is it just something that falls to the artist to avoid doing?

3.) Even so, this means that I can't have multiple overlapping translucent objects or have to be careful about what objects pass behind them. Am I missing something here?

4.) Just for future reference, what is the actual upper limit value of FP16?

Thanks for any help you can provide.

1) I just use this method - clamping to the max half-float value. Anything that bright is surely going to be mapped to white by your tone-mapper anyway, so you shouldn't actually lose any quality by doing this.

2) It's also the fault of your light sources. Point lights don't actually make any physical sense -- you try and work out the math and you end up with infinity radiance all over the place... A perfectly smooth surface lit by a point light is always going to behave a bit weird. In a perfectly realistic renderer, the artist would also be able to tweak the size of their 'point' (sphere) lights.

3) When light is passing through, from behind a translucent surface toward the camera, you should also take the fresnel/BRDF into account there -- some percentage of that background light is going to be reflected away and not make it to the camera.

We actually used to hit that problem all of time. We fixed it by clamping the output in the pixel shader, although clamping to the max fp16 value doesn't work since that can still overflow when summed with the render target contents in the ROPS. We ended up clamping to a value that was suitably large in order to map to white after tone mapping for all reasonable exposure ranges used in the game.

@MJP

Any chance you could tell me what that value was? Was it something relative to your tonemapping algorithm?

Actually, let me be more specific about my situation. In Unity, my tech can potentially be used in multipass light accumulation, single-pass translucent, and Light PrePass deferred. So knowing that:

1. What value would you recommend I clamp my illumination to to keep it from blowing out?
2. Should I be clamping at each light's output, or the final combined output for a given surface with all lighting?
3. If during the each light's output, then what should I do about LPP mode where the lights are accumulated without material colors?

Thanks.

Well I feel silly about this. It turns out that it was a bug unique to Unity3D because of code they want you to add when doing custom forward lighting. Basically, they have you put the luminance of the specular lighting in the alpha channel of the lighting function's color output. Apparently this breaks down if the specular lighting has a ridiculously high value. Once I removed this, it started working fine again.