Jump to content

  • Log In with Google      Sign In   
  • Create Account

Krzysztof Narkowicz

Member Since 13 Aug 2010
Offline Last Active Yesterday, 08:26 AM

#5311809 Question about Epic's course notes about Physically based rendering.

Posted by on 21 September 2016 - 01:55 PM



It's impractical to use SH for high freq IBL, as you need a crazy amount of terms. Additionally, Brian's split sum approximation splits the radiance integral into two parts - one which can be stored in a cube map and second which can be stored in a small 2D texture (this is why there is no L(i) term in the second equation). Anyway, I'm not sure what are you trying to calculate here, as your equations look quite strange - e.g. f(l,v) term is missing.

#5308545 Some HDR, tonemapping and bloom questions

Posted by on 29 August 2016 - 02:31 PM

Right now I use DXGI_FORMAT_R16G16B16A16_UNORM for my "light accumulation" or HDR-buffer. I guess then I should use DXGI_FORMAT_R16G16B16A16_FLOAT instead?


You could use RGB16_UNORM by manually scaling shader outputs and inputs, but RGB16_Float render target is more convenient and precise (you want a lot of precision for the low values and not too much for the very high ones).


Right now I perform my gamma-correction by simply doing a fullscreen pass and rendering the DXGI_FORMAT_R16G16B16A16_UNORM texture into the DXGI_FORMAT_R8G8B8A8_UNORM_SRGB backbuffer texel-by-texel. I guess this works fine since both are in the [0, 1] range. Do these tonemapping alghorithms (like Reinhard) also bring the values > 1.0 into the [0,1] range or is it "just about averaging/smoothing the light intensity"? i.e will I possibly end up with > 1.0 values after tonemapping?  :)


Tonemapping is about reducing color range for the final display, so yes a common tonemapper (one designed for LDR displays) will bring image to the [0;1] range.


EDIT: also, what happens when you write > 1.0 valus into a UNORM texture? I assume they jsut get clamped to 1.0?


Yes. Output values will be clamped to [0;1] range.


EDIT2: another question, I suppose FXAA is to be applied AFTER tonemapping? and bloom BEFORE tonemapping?


Yes. You want bloom before tonemapping (so it works with linear HDR values) and FXAA after tonemapping (so edge blending works "correcly"). 

#5275050 Diffuse IBL - Importance Sampling vs Spherical Harmonics

Posted by 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 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 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 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 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 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 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 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 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 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 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 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 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.