Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Oct 2006
Offline Last Active Sep 28 2014 08:20 AM

Posts I've Made

In Topic: [SOLVED] Area Light, Representative Point, Blinn-Phong

07 September 2014 - 01:05 PM

Okay, I've sort of solved it myself. Basically, I found a way to apply Beckmann roughness to Blinn Phong. This modifies the normalization term to be the way the Epic described in their paper for GGX, so I suspect the same trick they used should now apply. For anyone who is interested, here is where I found my answer:

In Topic: [SOLVED] HDR PBR, exceeded FP16 range

11 January 2014 - 11:20 AM

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. 

In Topic: [SOLVED] HDR PBR, exceeded FP16 range

10 January 2014 - 11:32 AM

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?


In Topic: [SOLVED] HDR PBR, exceeded FP16 range

10 January 2014 - 05:38 AM


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

In Topic: [SOLVED] For Physical BRDFs, why use such high specular powers (eg. 8192)?

24 December 2013 - 10:29 PM


Well one thing I discovered was that I made the faulty assumption that my team's artist added a tonemapper at all. Needless to say, adding that helped a lot. I am just using the Bloom and tonemappers that ship with Unity. The 1.0 cutoff just means anything above 1.0 in intensity contributes to bloom. And we are using the "Photographic" setting for the tonemapper. 



Yeah, I figured it was probably mostly because of aliasing, but I was reluctant to go down that path so soon since Unity has absolutely awful support for custom mipmaps. I did manage to get it to work, and it helped a lot. 



So yeah, I now understand the point of such high spec powers for up close smoothness. At a distance, the precomputed specular AA makes it appropriately more rough.