Jump to content

  • Log In with Google      Sign In   
  • Create Account

Krzysztof Narkowicz

Member Since 13 Aug 2010
Online Last Active Today, 09:55 AM

#5165357 OculusVR acquired and open sourced RakNet

Posted by Krzysztof Narkowicz on 07 July 2014 - 03:07 PM

OculusVR just open sourced RakNet - a C++ multiplatform network library used for example by Unity or Gamebryo. It's totally free even for commercial usage (BSD license and all patents granted). It's also a great reference for writing your own multiplayer transport layer.


#5165350 Grass Rendering Questions

Posted by Krzysztof Narkowicz on 07 July 2014 - 02:41 PM

You can use pixel shader input VFACE / SV_IsFrontFace / gl_FrontFacing to check if current pixel belongs to a front facing or to a back facing triangle. It it's back facing then just flip normal and shade as usually.

#5163632 UE4 IBL / shading confusion

Posted by Krzysztof Narkowicz on 29 June 2014 - 09:11 AM

Metallic works like Tessellator wrote, but it's also has an additional specular parameter (which is equal 0.5 by default). Mentioned specular parameter is driven by a cavity map (single channel).

BaseColor = Cavity * OldBaseColor
Specular = Cavity * 0.5

DiffuseColor = lerp( BaseColor, 0, Metallic )
SpecularColor = lerp( 0.08 * Specular, BaseColor, Metallic )




As for split sum aproximation try comparing with an reference shader, which takes hundreds of samples per pixel in real time.

#5156343 Doing local fog (again)

Posted by Krzysztof Narkowicz on 27 May 2014 - 02:47 PM

For an interesting general volumetric fog solution check out Assasin Creed 4 presentations by Bart Wroński: http://bartwronski.com/publications/

#5149932 IBL Problem with consistency using GGX / Anisotropy

Posted by Krzysztof Narkowicz on 27 April 2014 - 02:43 PM

The thing that I can't seem to figure out is how this direction of the pixel (L) is calculated ?

That depends how do you want to integrate:

1. If you want to calculate analytically (loop over all source cubemap texels), then calculate direction from cube map face ID and cube map texel coordinates. That direction is a vector from cubemap origin to current cubemap texel origin. For example for +X face:
dir = normalize( float3( 1, ( ( texelX + 0.5 ) / cubeMapSize ) * 2 - 1, ( ( texelY + 0.5 ) / cubeMapSize ) * 2 - 1 ) )
2. If you want to approximate, then just generate some random vectors by using texture lookup or some rand shader function.

First approach is a bit more complicated because you additionally need to weight samples by solid angle. Cube map corners have smaller solid angle and should influence the result less. Solid angle can be calculated by projecting texel onto unit sphere and then calculating it's area on the sphere. BTW this is something that AMD CubeMapGen does.

Does it even make sense to use importance sampling for an irradiance environment map because of the nature of it being very low frequency ?

Frequency doesn't matter here. The idea of importance sampling is to bias random distribution according to how much given sample influences result. For example we can skip l directions which are in different hemisphere ( dot( n, l ) <= 0 ) and we can bias towards directions with higher weight ( larger dot( n, l ) ).

#5149713 IBL Problem with consistency using GGX / Anisotropy

Posted by Krzysztof Narkowicz on 26 April 2014 - 03:23 PM

Correct way would be to compute integral mentioned in my previous post. You can also approximate it using Monte Carlo method in order to develop intuition how it works. Basically for every destination cubemap texel (which corresponds to some directional n) take x random directions, sample source env map and treat them like a directional light. This is very similar to GGX stuff you are already doing.

for every destination texel (direction n)
    sum = 0
    for x random directions l
        sum += saturate( dot( n, l ) ) * sampleEnvMap( l );
    sum = sum / ( x * PI )

For better quality you can use importance sampling by biasing random distribution. Some directions are more "important" - for example you don't care about random light vectors which are located in different hemisphere than current normal vector.


#5146978 where to start Physical based shading ?

Posted by Krzysztof Narkowicz on 14 April 2014 - 02:32 PM

It's very similar for Cook-Torrance. Check out great sample by MJP which implements various specular AA techniques with Cook-torrance: https://mjp.codeplex.com/releases/view/109905

#5146764 IBL Problem with consistency using GGX / Anisotropy

Posted by Krzysztof Narkowicz on 13 April 2014 - 02:30 PM

In layman's terms you need to treat cube map as a lookup table and precompute there some data by using a source cubemap. Let's start from simple Lambert diffuse to see how does it work.


For Lambert diffuse we want to precompute lighting per normal direction and store it in a cubemap. To do that we need to solve a simple integral: 


Which in our case means: for every texel of the destination cubemap, calculate some value E. E is calculated by iterating over all source cubemap texels and summing their irradiance E. Where E = SourceCubemap(l) * ( n dot l ) * SourceCubemapTexelSolidAngle. This operation is called cosine filter in AMD CubeMapGen.


For simple Phong model (no fresnel etc.) we can precompute reflection in a similar way and store it in a destination cubemap. Unfortunately even after just adding Fresnel or when using Blinn-Phong there are too many input variables and exact results don't fit into a single cubemap. It's time to do some kind of approximations, start using more storage or take more than one sample.

#5146380 IBL Problem with consistency using GGX / Anisotropy

Posted by Krzysztof Narkowicz on 11 April 2014 - 02:01 PM

Modified AMD CubeMapGen generates cubemaps using Phong shading model. For more complicated models check out Black Ops And UE4 presentations from Siggraph 2013:



#5076384 RPG Shadows, CSM, TSM, what else?

Posted by Krzysztof Narkowicz on 09 July 2013 - 11:53 AM

Sorry, I meant PSSM, not PSM. PSM/TSM and similar algorithms have a lot of temporal aliasing when camera moves. IMHO "normal" shadows look much better.


Yes, it's possible to implement SDSM on SM3.0. Just calculate depth range on GPU using pixel shaders and then read it on CPU. For read back use a few textures in round-robin fashion, so GPU won't be stalled by CPU. Results will be lagged by a frame or two, but it should look ok.

#5075965 RPG Shadows, CSM, TSM, what else?

Posted by Krzysztof Narkowicz on 07 July 2013 - 02:51 PM

For DX9 I would go with standard PSSM. For DX11 and more powerful GPUs I would try to use EVSM with SDSM. Of course for local lights (spotlights etc.) use a single cascade.

SDSM - ("Sample Distribution Shadow Maps") is an interesting PSSM extension, which provides optimal shadow map frustum.

EVSM (Chen, Tatarchuk - "Lighting Research at Bungie", SIGGRAPH09). It combines ESM and VSM in order to fix light bleeding issues.

#5054476 Spherical harmonics in pixel shader

Posted by Krzysztof Narkowicz on 18 April 2013 - 02:13 AM

Yes, you are on the right track. If you want to use normal maps, then you need to sample in pixel shader. You can find code for evaluating irradiance using given normal in the DXSDK samples (Samples\C++\Direct3D\IrradianceVolume/SHIrradianceEnvMap.fx).

#5012460 Software 3D Renderer - Do I really need Perspective Correction?

Posted by Krzysztof Narkowicz on 19 December 2012 - 09:22 AM

Depth should be also interpolated using perspective correction. Without it there will be some z-buffer artifacts in places where two triangles intersect / overlap. More or less visible, depending on triangle position and size.

BTW persp corr interpolation just for zbuffer is simple - just linearly interpolate 1/z in screen space.

#4987502 Gaussian specular in UnrealEngine4

Posted by Krzysztof Narkowicz on 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 .

#4943777 Suggestion on reducing jaggies edge for particular angle.

Posted by Krzysztof Narkowicz on 27 May 2012 - 01:46 PM

FXAA, MLAA or similar algorithms won't solve this kind of temporal aliasing of small details.

You can:
1. Use temporal AA (subpixel jitter camera every frame + blend current frame with previous). There is more info about it in crysis 2 presentations. This method has it's artifacts, especially when you target 30fps.
2. Use MSAA, FSAA or similar, which are quite GPU heavy.
3. Let the texture filtering handle it - draw big chunks of terrain with final mip-mapped texture (which contains already composed grass, asphalt, run way etc.). It will look nice, but also you will loose some runtime terrain composition flexibility.