Computer Graphics
COMP3421/9415 2021 Term 3 Lecture 13
What did we learn last lecture?
¡ñ A complete algorithm
¡ñ Ambient, Diffuse and Specular Lighting
¡ñ Working with different light types
¡ñ And with multiple lights
What are we covering today?
Advanced Lighting
¡ñ What can we add to ?
¡ñ Colour Perception and Gamma Correction
¡ñ Lightmapping
¡ñ HDR
¡ñ Blinn- Lighting
Let’s look at some places we could improve it
¡ñ Multiple Lights are inefficient
¡ð Is there a way to render some of our lights beforehand, so they’re not taking up frame
time?
¡ñ Light values are clamped to 0.0-1.0
¡ð can add more than 1.0 light, what do we do with that? ¡ñ Dot Products are clamped to 0.0-1.0
¡ð What happens when a dot product could be negative like in reflected light? ¡ñ There are no shadows
¡ð We’re going to need to learn a few other techniques before we can take this on!
Gamma Correction
The Perception of Colour and Light
Human Perception vs Numerical Output
¡ñ A scale of brightness from 0.0 to 1.0
¡ñ Unfortunately, we perceive brightness differently to how our monitors
display it
¡ñ Old CRT monitors used to display colour similarly to our perception
¡ð An exponential rather than linear scale of light per voltage
¡ð Known as the monitor’s Gamma
¡ñ Current monitors replicate the same Gamma curve
Image credit: learnopengl.com
RGB Values vs Actual Output
Our basic lighting is all 0.0 – 1.0 scale
¡ñ We’ve assumed linear colour and light scale
¡ñ But our output is not linear!
¡ñ RGB (0.2,0.2,0.2) does not output twice as
many photons as (0.1,0.1,0.1)
¡ñ We need to correct our Gamma!
Gamma Correction
Counteracting the gamma curve
¡ñ If we intended our RGB values to be linear . . .
¡ñ And our monitor’s output is non-linear
¡ñ We should change our RGB values
¡ñ Gamma corrected values negate the monitor’s
gamma curve
¡ñ The most common gamma curve is 2.2 (based on
CRT monitors)
A graph of RGB values to actual output Image credit: learnopengl.com
OpenGL Gamma Correction
sRGB
¡ñ sRGB is a colour space that automatically corrects a gamma of 2.2
¡ñ We can use a sRGB framebuffer that converts RGB values as we write to it
¡ñ or
¡ñ We can adjust values as we finalise fragment colours
¡ñ Games often allow us to manually adjust gamma in case we’re not exactly
on a 2.2 gamma
Gamma complications
If all of our monitor output is skewed . . .
¡ñ Is it ok if we make art (like textures) with the gamma curve
¡ñ Then display it with roughly the same curve?
¡ñ Sadly not!
¡ñ Our lighting calculations are all linear
¡ñ So we’re going to correct gamma in our output
¡ñ Which means we might need our artists to create content using corrected
gamma also!
Differences with Gamma Correction
Image credit: learnopengl.com, taken from Wolfire Games Blog
Lightmapping
Ambient
Ambient lighting is a very rough guess
¡ñ just assumes ambient lighting
¡ñ It’s consistent and reaches every surface equally
¡ñ We touched on , a very accurate global illumination technique
¡ñ But very time/performance consuming
¡ñ What if we could “pre-bake” our global illumination?
Lightmapping
Difficult and Complex lighting is calculated in advance
¡ñ Not just
¡ñ Any illumination technique can be calculated in advance
¡ñ Lighting is calculated then “baked” into a lightmap
¡ñ A lightmap is a buffer of all the lighting in a scene
¡ñ Works ok for static objects and static lights
¡ñ Doesn’t work for dynamic objects and lights
Lightmap Example
An example of the lighting in a scene being baked into a 2D buffer
Image credit: Wikipedia user Narpas
Creating Lightmaps
Creation
¡ñ Any lighting can be pre-baked
¡ñ Historically used for unchanging lights like the Sun
¡ñ and unchanging environments like buildings etc
¡ñ Lighting is calculated in advance and saved to a buffer
¡ñ Usually this is a specific light buffer that vertices map to (just like a
texture)
Using Light maps
What the realtime lighting shaders do
¡ñ When a light map exists:
¡ñ Instead of using the Ambient light equation
¡ñ We’d read lighting from the light map just like a texture
¡ñ This means the vertices of any static geometry would have a light map
coordinate mapping to “lumels” in the light map
This method is as old as Quake (1996)
¡ñ They also used multiple light maps for the same area to simulate things like flickering lights by switching light maps
Break Time
We’re getting closer to actual games now
¡ñ Some things, like lightmapping are used extensively (especially in older games)
¡ñ You may have heard of Ambient Occlusion (calculation of micro shadows in realtime)
¡ñ Gamma Correction is something that you will have probably seen!
¡ñ The more we learn in this course, the more you will understand how the
visuals in the games we play are made
HDR
Clamping Light values
What’s the range of our light values?
¡ñ RGB from 0.0-1.0 in our previous lighting calculations
¡ñ What happens in regions of bright light?
¡ð > 1.0 is clamped to 1.0
¡ñ Loss of contrast between colours ¡ð Leads to a loss of detail
Image credit: learnopengl.com
High Dynamic Range
Originally a concept from Photography
¡ñ Multiple photographs taken at different exposure levels
¡ñ High Exposure to capture detail in dark areas
¡ñ Low Exposure to capture detail in brighter areas
¡ñ Combined into a single photo
¡ñ Captures detail in both bright and dark areas
HDR Photography
Images credit: of Processing multiple HDR images with “Natural Tone Mapping”
Image credit:
HDR in OpenGL
How do we implement HDR in realtime graphics?
¡ñ Remove the clamping on light values
¡ñ Transform the new unclamped light values back into 0.0-1.0
¡ñ Write the final information into the framebuffer
In OpenGL
¡ñ Create an intermediate frame buffer that stores floating point RGB values
¡ñ Use a Tone Mapping algorithm to convert those values to 0.0-1.0
Frame Buffers
A new concept . . . a buffer that stores “pixels”
¡ñ We can create buffers in OpenGL
¡ñ We can create a buffer that is exactly the same size as the screen
¡ñ Each element of the buffer maps to a screen/window pixel
¡ñ Each element can contain RGB values for example
¡ð In HDR, we’d use floats instead of 0.0-1.0 clamped values
¡ñ A buffer like this is very similar to a texture!
¡ñ This is not the last time we’ll be using these!
Tone Mapping
An algorithm to convert exposure levels to Low Dynamic Range
¡ñ A simple idea would be to divide HDR values by their maximum ¡ð Resulting in 0.0-1.0
¡ñ But much more complex algorithms exist that:
¡ð Maintain contrast in local areas
¡ð Treat bright and dark areas differently
¡ñ We can also dynamically change our HDR algorithm
¡ð Like indoors vs outdoors as we walk in between areas
Blinn- our ‘ve been using dot products to work with angles
¡ñ Dot products allow us to go from vectors to angles easily
¡ñ Also means we have simple maths for our GPUs
¡ñ But we’ve been clamping them between 0.0 and 1.0
¡ñ What issues can this cause?
Angles above 90¡ã
Possible issues at very low
¡ñ Left shows intended Phong lighting
¡ñ Right shows a V to R angle higher than 90¡ã
¡ñ Our dot products will reduce our lighting to zero at angles > 90¡ã
Image credit: learnopengl.com
Dot Product based artifacts
A hard cutoff edge in situations with low Phong exponents
Image credit: learnopengl.com
Blinn- we make sure we never have a > 90¡ã angle?
¡ñ Blinn-Phong is a modification of specular Phong lighting
¡ñ Phong lighting will reflect the light direction
¡ñ Then dot product with the viewer direction
¡ñ Blinn-Phong will instead create a “Halfway Vector”
¡ñ Halfway between the light and the viewer
¡ñ Then test the dot product of the Halfway and the Normal
¡ñ It is much harder for the angle between Halfway and Normal to be > 90¡ã
Blinn- credit: learnopengl.com
More Advanced Lighting
Where can we go from here?
Things we haven’t talked about yet:
¡ñ Shadows
¡ñ Direct Reflections (mirrors etc)
¡ñ Techniques for hundreds of lights at once
¡ñ Screen space effects
¡ð Bloom
¡ð Blur
¡ð Motion Blur
¡ð Anti-Aliasing
¡ð etc
What did we learn today?
Some addons to
¡ñ Some corrections, some addons
¡ñ Gamma Correction
¡ñ Lightmapping
¡ñ HDR
¡ñ Blinn-Phong
¡ñ There are a lot more that we haven’t seen yet!