View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Gaussian specular in UnrealEngine4

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

9 replies to this topic

### #1lipsryme  Members

Posted 05 October 2012 - 07:13 AM

So I was reading in the unreal engine 4 siggraph paper about their usage of an empirical model for this.
If you haven't seen it it's on page 30 or so: http://www.unrealeng...mo_16x9_(2).pdf

Now the only thing I was wondering is this model as it is stated in the paper, is not normalized as it seems.
And as far as the code is concerned they only describe this factor for their area light sources.
Does anyone have an idea of what the correct normalization factor for this specific model would be for a regular punctual light source ?

Edited by lipsryme, 05 October 2012 - 07:20 AM.

### #2knarkowicz  Members

Posted 06 October 2012 - 02:50 PM

Unfortunately I couldn't solve it analytically (I doubt it's even solvable this way), but I came up with a simple aproximation: 0.17287429 + 0.01388682 * n. Where n is Blinn-Phong specular power. It's quite accurate for specular powers above 16. If you are interested I have posted some plots on my blog: http://kriscg.blogsp...n-specular.html .

### #3lipsryme  Members

Posted 07 October 2012 - 08:16 AM

Unfortunately I couldn't solve it analytically (I doubt it's even solvable this way), but I came up with a simple aproximation: 0.17287429 + 0.01388682 * n. Where n is Blinn-Phong specular power. It's quite accurate for specular powers above 16. If you are interested I have posted some plots on my blog: http://kriscg.blogsp...n-specular.html .

splendid!

### #4CryZe  Members

Posted 13 October 2012 - 09:17 AM

I've implemented it for Disney's BRDF Explorer and evaluated how closely it fits the Mitsubishi MERL BRDF database. I found out, that its shape is pretty unrealistic. Also, KriScg's approximation was off by about the factor 2.

Here's the better approximation of the NDF:

Also here's a plot of its shape compared to the more physically correct GGX distribution function:

It's actually even slower than GGX, so why would anyone want to use it anyway

Edited by CryZe, 13 October 2012 - 09:25 AM.

### #5MJP  Moderators

Posted 13 October 2012 - 02:58 PM

Yeah I've also been a bit confused as to why they're going with that BRDF. GGX is really nice, and I find it works well for a lot of materials.

Edited by MJP, 14 October 2012 - 09:56 PM.

### #6knarkowicz  Members

Posted 14 October 2012 - 02:14 PM

KriScg's approximation was off by about the factor 2.

I think it's because you are using wrong treshold 0.004 (it was 0.04 in the presentation).

### #7InvalidPointer  Members

Posted 16 October 2012 - 09:12 AM

Yeah I've also been a bit confused as to why they're going with that BRDF. GGX is really nice, and I find it works well for a lot of materials.

We're talking about the same Epic/Unreal engine, right? I can probably count on one hand the number of 'yes, *this* is a smart renderer design decision' moments in recent memory

I mean, look at the entire HDR pipeline in UE3.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

### #8CryZe  Members

Posted 16 October 2012 - 09:59 AM

KriScg's approximation was off by about the factor 2.

I think it's because you are using wrong treshold 0.004 (it was 0.04 in the presentation).

Oh wow, I didn't even realize that. I might fix my post, after I've tried the correct version.

Edit: Overall, nothing really much changed, except the fact, that the approximation is still off, but not by a factor of 2. The problem is, that you want the integral to evaluate to 1 and not to "<= 1".

Edited by CryZe, 16 October 2012 - 10:11 AM.

### #9knarkowicz  Members

Posted 16 October 2012 - 01:39 PM

The problem is, that you want the integral to evaluate to 1 and not to "<= 1".

I did solve it for integral = 1. I just wrote it as <= 1. Thanks for noticing.

I wrote a brdf for BRDF explorer with "Mittring" specular.

[source lang="plain"]analytic::begin parametersfloat n 1 1000 100bool normalized 1::end parameters::begin shadervec3 BRDF( vec3 L, vec3 V, vec3 N, vec3 X, vec3 Y ){ vec3 H = normalize( L + V ); float Dot = clamp( dot( N, H ), 0, 1 ); float Threshold = 0.04; float CosAngle = pow( Threshold, 1 / n ); float NormAngle = ( Dot - 1 ) / ( CosAngle - 1 ); float D = exp( -NormAngle * NormAngle ); if (normalized) { D *= 0.17287429 + 0.01388682 * n; //D *= 0.34574858 + 0.02777364 * n; } return vec3(D);}::end shader[/source]

Now when you use mine aprox, then max albedo in BRDF explorer correctly comes up as 1, but when using yours it's 2. This means, that in yours aprox sometimes outgoing energy is two times greater than incoming. I believe it's because you did integrate over full sphere, instead of just upper hemisphere.

Edited by Krzysztof Narkowicz, 16 October 2012 - 03:11 PM.

### #10MJP  Moderators

Posted 17 October 2012 - 12:07 AM

We're talking about the same Epic/Unreal engine, right? I can probably count on one hand the number of 'yes, *this* is a smart renderer design decision' moments in recent memory

I don't think that's particularly fair. They have plenty of good tech, and lots of people have made really good games with it.

Anyway I wasn't implying that they made the wrong decision with their choice, just that I didn't understand the motivation behind it.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.