Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!

Krzysztof Narkowicz

Member Since 13 Aug 2010
Online Last Active Today, 03:08 PM

Posts I've Made

In Topic: Calculate HDR exposure from luminance Histogram

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.

In Topic: Calculate HDR exposure from luminance Histogram

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.

In Topic: HDR lightmap compression

04 July 2015 - 09:41 AM

I'm stuck with DX9 api.  LogLUV did have artifact when bilinear filter is on.

Is LogLUV  only good at being a slim HDR color buffer?

Can I implement a HDR deferred shading pipeline,  while using LDR light map at the same time? 


LogLUV is also fine for lightmaps if filtering artifacts are acceptable. You could also filter manually in the shader, but without DX11 GatherX instructions this won't be too optimal. Another possibility is to use other encoding schemes like RGBE, RGBM, RGBK etc. All of them have different kind of artifacts, but maybe something will work better for your's content.


I wouldn't recommend doing a HDR rendering with LDR lightmaps. At least rescale lightmap LDR values to a ~[0;4] range, so there will be some additional range at the cost of worse precision.

In Topic: HDR lightmap compression

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.

In Topic: Automatic UV map generation: OpenNL LSCM doesnt work - why ?

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.