• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By lucky6969b
      I want to calculate the position of the camera, but I always get a vector of zeros.

      D3DXMATRIX viewMat; pDev->GetTransform(D3DTS_VIEW, &viewMat); D3DXMatrixInverse(&viewMat, NULL, &viewMat); D3DXVECTOR3 camPos(viewMat._41, viewMat._42, viewMat._43); log->Write( L"Camera Position: %f %f %f\n", camPos.x, camPos.y, camPos.z);

      Could anyone please shed some lights on this?
    • By xiaohan wen
      If you have CROWDFUNDED the development of your game, which of the following statements do you agree with?
      1. I went out of my way to try to launch my game by the estimated delivery date
      2. I made an effort to launch my game by the estimated delivery date
      3. I was not at all concerned about launching my game by the estimated delivery date
      Hi there! I am an academician doing research on both funding success and video game development success.
      For those who have CROWDFUNDED your game development, it would be extremely helpful if you could fill out a very short survey (click the Qualtrics link below) about your experiences.
      The survey would just take 5 minutes and I’ll be happy to share my findings of what leads to crowdfunding success and how it affects game development based on an examination of 350 Kickstarter projects on game development in return.
      This is an anonymous survey and your personal information will not be recorded.
      Thank you very much in advance!
    • By bsudheer
      Leap Leap Leap! is a fast-paced, endless running game where you leap from rooftop to rooftop in a computer simulated world.

      This is a free run game and get excited by this fabulous computer simulated world of skyscrapers and surreal colors in parallax effect. On your way, collect cubes and revival points as many as you can to make a long run.

      Features of Leap Leap Leap:
      -Option of two themes: Black or White.
      -Simple one touch gameplay.
      -Attractive art.
      -Effective use of parallax.
      To Download the game:
      Playstore: https://play.google.com/store/apps/details?id=com.avakaigames.leap
      Appstore: https://itunes.apple.com/us/app/leap-leap-leap/id683764406?mt=8

    • By isu diss
      I'm following rastertek tutorial 14 (http://rastertek.com/tertut14.html). The problem is, slope based texturing doesn't work in my application. There are plenty of slopes in my terrain. None of them get slope color.
      float4 PSMAIN(DS_OUTPUT Input) : SV_Target { float4 grassColor; float4 slopeColor; float4 rockColor; float slope; float blendAmount; float4 textureColor; grassColor = txTerGrassy.Sample(SSTerrain, Input.TextureCoords); slopeColor = txTerMossRocky.Sample(SSTerrain, Input.TextureCoords); rockColor = txTerRocky.Sample(SSTerrain, Input.TextureCoords); // Calculate the slope of this point. slope = (1.0f - Input.LSNormal.y); if(slope < 0.2) { blendAmount = slope / 0.2f; textureColor = lerp(grassColor, slopeColor, blendAmount); } if((slope < 0.7) && (slope >= 0.2f)) { blendAmount = (slope - 0.2f) * (1.0f / (0.7f - 0.2f)); textureColor = lerp(slopeColor, rockColor, blendAmount); } if(slope >= 0.7) { textureColor = rockColor; } return float4(textureColor.rgb, 1); } Can anyone help me? Thanks.

    • By elect
      ok, so, we are having problems with our current mirror reflection implementation.
      At the moment we are doing it very simple, so for the i-th frame, we calculate the reflection vectors given the viewPoint and some predefined points on the mirror surface (position and normal).
      Then, using the least squared algorithm, we find the point that has the minimum distance from all these reflections vectors. This is going to be our virtual viewPoint (with the right orientation).
      After that, we render offscreen to a texture by setting the OpenGL camera on the virtual viewPoint.
      And finally we use the rendered texture on the mirror surface.
      So far this has always been fine, but now we are having some more strong constraints on accuracy.
      What are our best options given that:
      - we have a dynamic scene, the mirror and parts of the scene can change continuously from frame to frame
      - we have about 3k points (with normals) per mirror, calculated offline using some cad program (such as Catia)
      - all the mirror are always perfectly spherical (with different radius vertically and horizontally) and they are always convex
      - a scene can have up to 10 mirror
      - it should be fast enough also for vr (Htc Vive) on fastest gpus (only desktops)

      Looking around, some papers talk about calculating some caustic surface derivation offline, but I don't know if this suits my case
      Also, another paper, used some acceleration structures to detect the intersection between the reflection vectors and the scene, and then adjust the corresponding texture coordinate. This looks the most accurate but also very heavy from a computational point of view.

      Other than that, I couldn't find anything updated/exhaustive around, can you help me?
      Thanks in advance
  • Advertisement
  • Advertisement
Sign in to follow this  

R&D [PBR] Renormalize Lambert

Recommended Posts

Hello, I'd like to ask your take on Lagarde's renormalization of the Disney BRDF for the diffuse term, but applied to Lambert. Let me explain.
In this document:
(page 10, listing 1) we see that he uses 1/1.51 * percetualRoughness as a factor to renormalize the diffuse part of the lighting function. Ok.

Now let's take Karis's assertion at the beginning of his famous document:
Page 2, diffuse BRDF: 


any more sophisticated diffuse model would be difficult to use efficiently with image-based or spherical harmonic lighting

I think his premise applies and is enough reason to use Lambert (at least in my case).

But from Lagarde's document page 11 figure 10, we see that Lambert looks frankly equivalent to Disney.

From that observation, the question that naturally comes up is, if Disney needs renormalization, doesn't Lambert too ?
And I'm not talking about 1/π (this one is obvious), but that roughness related factor.

A wild guess would tell me that because there is no Schlick in Lambert. and no dependence on roughness, and as long as 1/π is there, in all cases Lambert albedo is inferior to 1, so it shouldn't need further renormalization. So then, where does that extra energy appear in Disney ? According to the graph, it's high view angle and high roughness zone, so that would mean, here: (cf image)


This is super small of a difference. This certainly doesn't justify in my eyes the need for the huge darkening introduced by the 1/1.51 factor that enters in effect on a much wider range of the function. But this could be perceptual, or just my stupidity.

Looking forward to be educated :)

Edited by Lightness1024
slightly clearer distinction between usual factor and further factor

Share this post

Link to post
Share on other sites

The entire point of renormalisation is to ensure energy conservation. 

When you integrate Lambert over the hemisphere, you get Pi. 1 unit goes in Pi units go out... Oops, we tripled the energy in the scene! So you divide Lambert by Pi so that 1 unit goes in and 1 unit comes out.

Apparently if you integrate Disney over the hemisphere you get 1/1.51*r... So you need to divide by this constant to make sure that energy isn't just summoned up from the ether in violation of conservation of energy. 

You can multiply your Lambert with 1/1.51*r, but this won't be "normalisation" - it will just be a hack to make Lambert respond to roughness in some way. If that's what you're after, there's a lot of "approximate Oren Nayer" Lambert hacks floating around that you can use instead. 

The phenomenological goal of such hacks is to make rough surfaces more flat (brdf of k/pi/dot(n,l)) while also adding a retroreflectice (view dependant) term, but to leave smooth surfaces alone (brdf of k/pi) as Lambert is correct for smooth surfaces. I'll post mine when I'm at my PC ;)

Share this post

Link to post
Share on other sites

Aye, Hodgman has the right of it. My personal favorite diffuse term comes from Respawn and Titanfall 2. They got the diffuse to not only be energy conserving, but reciprocal to GGX, as well as heightfield corellated and blah blah blah reference tested physically based etc.

Take a looksie http://www.gdcvault.com/play/1024478/PBR-Diffuse-Lighting-for-GGX

Share this post

Link to post
Share on other sites

@FreneticPonE are you talking about this:


I've never seen this magic, seems interesting though.

This is just further confusing me unfortunately. Let's say I chose a lambert for diffuse and cook torrance for speculars, am I supposed to just add the two ? Lambert doesn't even depend on roughness so mirror surfaces are going to look half diffuse half reflective if just adding both. How one would properly combine a lambert diffuse and a pbr specular ?

Share this post

Link to post
Share on other sites

well apparently disney is not complexed by just adding both:


but still it appears to be a subject of pondering:

This nice paper, from paragraph 5.1 speaks of exactly what I'm concerned with:
And they propose an equation (equation 5) one page later that looks quite different from disney's naive (as it seems to me) approach.

Edited by Lightness1024
rephrase slightly

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement