Jump to content

  • Log In with Google      Sign In   
  • Create Account

Krzysztof Narkowicz

Member Since 13 Aug 2010
Offline Last Active Today, 03:01 PM

#5275050 Diffuse IBL - Importance Sampling vs Spherical Harmonics

Posted by Krzysztof Narkowicz on 09 February 2016 - 03:56 PM

Most often HDR sky textures don't contain sun, as it's a separate analytic light source and you don't want to apply it twice to the scene. Therefore you usually don't have to deal with such extreme values and ~32-64 samples are enough for diffuse pre-integration using importance sampling. It's also pretty cheap, as 6x8x8 destination pixels are enough for low frequency data like diffuse. This of course doesn't yield perfect results, but errors are hard to notice in a real scene with textures.


If you are interested in diffuse pre-integration using SH, then check out this great post by Sébastien Lagarde (it also contains an example application with source code):


#5274732 [DX12] Constant Buffer Packing

Posted by Krzysztof Narkowicz on 07 February 2016 - 03:35 AM

Arrays in HLSL constant buffers are stored without any packing and every element is stored as float4. This way there in no extra overhead for array indexing in shader. If you want to pack arrayd more tightly then simply pass them as float4[] and cast to float2[] in shader.

#5274685 Questions on Baked GI Spherical Harmonics

Posted by Krzysztof Narkowicz on 06 February 2016 - 01:43 PM

There are two usual solutions for leaking. First one is to disable occluded probes at runtime, which may be a bit costly when using 3D textures. Second one is to replace occluded probes with correct ones by blending their unoccluded neighbors during an offline step.

#5273267 Lightmap theory and rendering

Posted by Krzysztof Narkowicz on 29 January 2016 - 02:45 PM

Shameles plug: a few years ago I wrote an article about lightmapping pipeline for a mobile game. It covers computing lighting on GPU, light probes, dynamic shadows, calculating UV charts for lightmapping and packing those UV charts into a single atlas. It's also full of references, so maybe you will something of interest.

#5240791 Calculate HDR exposure from luminance Histogram

Posted by Krzysztof Narkowicz on 16 July 2015 - 07:56 AM

This seems quite interesting, do you know the advantages of this method over a simple 1x1 downsample luminance average?


With a simple average a few very bright HDR pixels (sun, fire or weapon muzzle flash) can change average luminance and over darken the entire image, so it's a good idea to skip a few % of brightest pixels. Similarly if you don't ignore most dark areas then entire image can be too bright. See "Post Processing in the Orange Box" for an explanation with some images.


Also I still having problems to understand how to calculate exposure from luminance if the tone mapping operator does not take in count the exposure.


Exposure = some_constant / averageLuminance and then multiply every pixel by exposure just before the tonemapping operator.



To be physically plausible, Bloom/Glare/Glow should added before tonemapping since it simulates scattering due to diffraction effects in the eye/camera lens, which are wavelength but not intensity dependent.


Yes, You are perfectly right.

#5240512 Calculate HDR exposure from luminance Histogram

Posted by Krzysztof Narkowicz on 15 July 2015 - 10:12 AM



This code discards given percentage of lower part (minFractionSum) and higher part of the histogram (maxFractionSum). Resulting middle part of histogram is used to calculate an average luminance value for tonemapping.


Average luminance should be calculated before the glare effects, but god rays aren't glare effects and should be applied before histogram calculation.

#5238269 HDR lightmap compression

Posted by Krzysztof Narkowicz on 03 July 2015 - 04:45 PM

LogLUV will have artifacts because of hardware filtering. Storing luminance in BC4 and chrominance in BC5 won't work with HDR lightmaps. If you target new GPUs, then just use BC6H. It's a really great format for HDR data and depending on quality requirements you can even compress in real-time.

#5232141 Automatic UV map generation: OpenNL LSCM doesnt work - why ?

Posted by Krzysztof Narkowicz on 01 June 2015 - 06:48 AM

When doing automatic UV unwrap, cutting mesh into charts is actually a much harder problem than calculating UV for those charts. I would recommend UVAtlas (https://uvatlas.codeplex.com/) library. It's based on quite old algorithm (iso-charts), so you could do better nowadays. Still it's production proven (e.g. Halo 3 used it) and much better than LSCM -/+ XYZ cutting. It's weakest part is UV chart packing. Tetris packing was a good idea 10 years ago, but now it's better just to do a bruteforce. Simply test every possible UV chart position in the final atlas and N rotations per chart.

#5231145 Spherical Harmonics - analytical solution

Posted by Krzysztof Narkowicz on 26 May 2015 - 04:13 PM

Transfer function cos(phi) has no azimuthal dependency, so all terms for m != 0 will vanish after integration.

#5227846 Spherical Harmonics - analytical solution

Posted by Krzysztof Narkowicz on 07 May 2015 - 03:12 PM

Eq. 19 has a small error. Instead of n!/2 it should be (n/2)!. So:

For even n: An = 2*pi*((2n + 1)/(4*pi))^0.5*(((-1)^(n/2 - 1))/((n + 2)*(n - 1)))*(n!/(2^n*((n/2)!)^2))
LambdaL = (4*pi)/(2*l+1))^0.5

A0 * Lambda0 ~= 0.886227 * 3.54491 = 3.14159

#5227840 Spherical Harmonics - analytical solution

Posted by Krzysztof Narkowicz on 07 May 2015 - 02:12 PM

You should additionally multiply An by a normalization term (4*pi)/(2*l+1))^0.5. See eq. 23-24.

#5227364 Spherical Harmonics - analytical solution

Posted by Krzysztof Narkowicz on 05 May 2015 - 01:35 PM

For Lambertian BRDF transfer function is cos(theta) and directional light is projected by evaluating the SH basis function in the light's direction and scaling results by light's color. Those coefficients from the ShaderX3 article are derived from the spherical harmonic basis functions (Yml).

#5227251 Spherical Harmonics - analytical solution

Posted by Krzysztof Narkowicz on 05 May 2015 - 01:42 AM

Oliveira uses numerical integration, because in his tutorial he projects a light probe and shadowed lights into SH basis. Both usually don't have an analytical form, so he can't leverage orthogonality of SH basis and solve that analytically.

#5199320 Transparent shadow casters with 'Translucency Map'

Posted by Krzysztof Narkowicz on 20 December 2014 - 03:41 PM

Crytek's approach has only one drawback - transparent surfaces can't cast shadows onto other transparent surfaces.

It works as follows:
1. Draw opaque surfaces into shadowmap
2. Clear translucency map to white
3. Draw translucents into translucency map with opaque shadow map as depth buffer and depth writes disabled
4. In order to apply shadows sample shadow map and translucency map. Shadow = Min(ShadowMapDepthTest, TranslucencyMap).

So if translucent shadow caster is behind the opaque one it will be discarded by the depth test. In other case it will modify translucency map, but it won't matter as depth test result will override this value during shadow evaluation.

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