Jump to content

  • Log In with Google      Sign In   
  • Create Account


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.

  • You cannot reply to this topic
9 replies to this topic

#1 lipsryme   Members   -  Reputation: 1001

Like
0Likes
Like

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.


Sponsor:

#2 Krzysztof Narkowicz   Members   -  Reputation: 1100

Like
2Likes
Like

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 .

blog | twitter | "Don't have any friends? Still a virgin? Programming is for you!"


#3 lipsryme   Members   -  Reputation: 1001

Like
0Likes
Like

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! :)

#4 CryZe   Members   -  Reputation: 768

Like
0Likes
Like

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:
Posted Image

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

Posted Image

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

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


#5 MJP   Moderators   -  Reputation: 10526

Like
0Likes
Like

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.


#6 Krzysztof Narkowicz   Members   -  Reputation: 1100

Like
0Likes
Like

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).

blog | twitter | "Don't have any friends? Still a virgin? Programming is for you!"


#7 InvalidPointer   Members   -  Reputation: 1396

Like
0Likes
Like

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.

#8 CryZe   Members   -  Reputation: 768

Like
0Likes
Like

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.


#9 Krzysztof Narkowicz   Members   -  Reputation: 1100

Like
0Likes
Like

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.

blog | twitter | "Don't have any friends? Still a virgin? Programming is for you!"


#10 MJP   Moderators   -  Reputation: 10526

Like
0Likes
Like

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 Posted Image


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.



PARTNERS