Adding Simple Phong Lighting — Handmade Hero — Episode Guide

0:02Recap and run the game to show off the radial fade

2:36handmade_render_group: Recap what PushQuad() does

3:30On specifying normals per vertex, separately from the triangles

6:15handmade_opengl.cpp: Make CompileZBiasProgram() pass VertN to the fragment shader

8:25handmade_render_group.cpp: Make PushCube() colour all faces the same, and run the game

9:53handmade_opengl.cpp: Determine to edit the lighting equation in CompileZBiasProgram() to use the normals

11:12Blackboard: Normal Interpolation

15:44Blackboard: Linearly interpolating on the curve of a perfect circle

18:02Blackboard: We don't need to worry about the speed problem or need to renormalise

19:03Blackboard: Reflection equation

20:34handmade_opengl.cp: Make CompileZBiasProgram() compute LightDistance falloff¹

22:00Run the game to make sure we're computing the falloff correctly

22:15Blackboard: Dot product

24:29Blackboard: Understanding cosing falloff

27:31Blackboard: An equation to compute cosine falloff

32:07Determine to check our equation against the physical lighting transfer equations

33:08Blackboard: Defining our angles and getting this to work for cosine 0

36:43Blackboard: Making better sense of cosine falloff for different angles of reflection

44:56Blackboard: Understanding cosine falloff from the collector's viewpoint, with the need to research this

50:56Blackboard: On the apparent need for an inverse relationship beween the light source and collector

55:42handmade_opengl.cpp: Make CompileZBiasProgram() compute and clamp the cosine angle²

57:17Run the game to see black

57:35handmade_opengl.cpp: Rephrase the ToLight computation in CompileZBiasProgram() and investigate why the normals are not working

1:02:21Run the game to see apparent darkening at oblique angles

1:04:56handmade_opengl.cpp: Read carefully through CompileZBiasProgram()

1:08:35Inspect screenshots of the darkening at oblique angles

1:11:01handmade_opengl.cpp: Make CompileZBiasProgram() set and pass WorldN from the VertexCode to FragmentCode

1:12:34Run the game to see our light source reflecting more correctly

1:13:24handmade_render_group.h and handmade_render_group.cpp: Add DebugLightP to render_setup and enable SetCameraTransform() to set it

1:16:16Run the game to see the light at the centre of the world

1:16:27handmade_world_mode.cpp: Make UpdateAndRenderWorld() set the DebugLightP

1:17:17Run the game to see the light in its original position

1:17:27handmade_world_mode.cpp: Make UpdateAndRenderWorld() attach the light to the hero

1:19:48Run the game to see the light moving with the hero

1:22:10Blackboard: Better lighting: 1) More lights

1:24:00Blackboard: Better lighting: 2) Reflected light / "bounce" light

1:25:36Blackboard: Better lighting: 3) Surface variability

1:27:42handmade_opengl.cpp: Enable CompileZBiasProgram() to take into account the angle and distance of the viewer

1:33:00handmade_opengl.cpp: Introduce in CompileZBiasProgram() the notion of specular light

1:35:53Blackboard: Reflection vector

1:39:14Blackboard: Computing that reflection vector

1:42:01handmade_opengl.cpp: Enable CompileZBiasProgram() to compute that RefVec

1:42:45Run the game to see the light reflection adapting to our viewpoint

1:43:16handmade_opengl.cpp: Enable CompileZBiasProgram() to make a very bright and tight specular highlight, and run the game to see that

1:46:52Q&A

🗩

1:46:52Q&A

🗩

1:46:52Q&A

🗩

1:47:47desuused The problem you could not find when you thought about dividing by cos(phi) is that the only reason diffuse surfaces can exist is surface roughness, which invalidates the assumption that you will collect photons from the entire surface. Roughness blocks some photons. One trick to check your model: a photon must have the same probability of going one way as the opposite way. All formulas for diffusive light are approximations, all diffuse surfaces are different. In order to render a physically correct diffuse surface you'd have to measure a 4-dimensional dataset of light distribution (reflectance depending on two angles of incidence and two angles of reflection)

🗪

1:47:47desuused The problem you could not find when you thought about dividing by cos(phi) is that the only reason diffuse surfaces can exist is surface roughness, which invalidates the assumption that you will collect photons from the entire surface. Roughness blocks some photons. One trick to check your model: a photon must have the same probability of going one way as the opposite way. All formulas for diffusive light are approximations, all diffuse surfaces are different. In order to render a physically correct diffuse surface you'd have to measure a 4-dimensional dataset of light distribution (reflectance depending on two angles of incidence and two angles of reflection)

🗪

1:47:47desuused The problem you could not find when you thought about dividing by cos(phi) is that the only reason diffuse surfaces can exist is surface roughness, which invalidates the assumption that you will collect photons from the entire surface. Roughness blocks some photons. One trick to check your model: a photon must have the same probability of going one way as the opposite way. All formulas for diffusive light are approximations, all diffuse surfaces are different. In order to render a physically correct diffuse surface you'd have to measure a 4-dimensional dataset of light distribution (reflectance depending on two angles of incidence and two angles of reflection)

🗪

1:48:47yurasniper GLSL has reflect function

🗪

1:48:47yurasniper GLSL has reflect function

🗪

1:48:47yurasniper GLSL has reflect function

🗪

1:49:11mtsmox Should you normalize the worldN in the fragment shader?

🗪

1:49:11mtsmox Should you normalize the worldN in the fragment shader?

🗪

1:49:11mtsmox Should you normalize the worldN in the fragment shader?

🗪

1:49:35ba6ix Ever done website dev work?

🗪

1:49:35ba6ix Ever done website dev work?

🗪

1:49:35ba6ix Ever done website dev work?

🗪

1:50:49uplinkcoder Can you take a quick shot at reducing the banding?

🗪

1:50:49uplinkcoder Can you take a quick shot at reducing the banding?

🗪

1:50:49uplinkcoder Can you take a quick shot at reducing the banding?

🗪

1:51:51uplinkcoder Also, I opened an issue where the game crashes when you go backwards after starting the game

🗪

1:51:51uplinkcoder Also, I opened an issue where the game crashes when you go backwards after starting the game

🗪

1:51:51uplinkcoder Also, I opened an issue where the game crashes when you go backwards after starting the game

🗪

1:52:44win32_handmade.h: Prevent SetCursor() and LoadCursor() from calling MAKEINTRESOURCE³

1:54:00ttbjm Would HDR / tonemapping be worth implementing?

🗪

1:54:00ttbjm Would HDR / tonemapping be worth implementing?

🗪

1:54:00ttbjm Would HDR / tonemapping be worth implementing?

🗪

1:54:32soysaucethekid Is bumpmapping a feature you're looking into implementing?

🗪

1:54:32soysaucethekid Is bumpmapping a feature you're looking into implementing?

🗪

1:54:32soysaucethekid Is bumpmapping a feature you're looking into implementing?

🗪

1:57:31jezzi23 SIMD on CPUs are pretty cool. However, it sounds painful to make use of the newest and the best instructions (e.g. AVX512) while remaining compatible with older CPUs. I don't see programs being compiled separately for different SSE capabilities. I assume a program will just crash if the CPU encounters an unsupported instruction? Would you dispatch at runtime for different code paths to flexibly use supported SIMD instructions, or does that sound dumb?

🗪

1:57:31jezzi23 SIMD on CPUs are pretty cool. However, it sounds painful to make use of the newest and the best instructions (e.g. AVX512) while remaining compatible with older CPUs. I don't see programs being compiled separately for different SSE capabilities. I assume a program will just crash if the CPU encounters an unsupported instruction? Would you dispatch at runtime for different code paths to flexibly use supported SIMD instructions, or does that sound dumb?

🗪

1:57:31jezzi23 SIMD on CPUs are pretty cool. However, it sounds painful to make use of the newest and the best instructions (e.g. AVX512) while remaining compatible with older CPUs. I don't see programs being compiled separately for different SSE capabilities. I assume a program will just crash if the CPU encounters an unsupported instruction? Would you dispatch at runtime for different code paths to flexibly use supported SIMD instructions, or does that sound dumb?

🗪

1:58:02Words of wisdom on the rarity of needing to optimise for newer instruction sets

2:02:34jezzi23 What if you have a deal with Intel to benchmark higher on the newest hardware?

🗪

2:02:34jezzi23 What if you have a deal with Intel to benchmark higher on the newest hardware?

🗪

2:02:34jezzi23 What if you have a deal with Intel to benchmark higher on the newest hardware?

🗪

2:04:05Jim0_o Any plans to create different types of lighting as in Room X is lit like a summers day while Room Y is contrasted and dark like a film Noir? (Or would you have all this done in the assets, maybe?)

🗪

2:04:05Jim0_o Any plans to create different types of lighting as in Room X is lit like a summers day while Room Y is contrasted and dark like a film Noir? (Or would you have all this done in the assets, maybe?)

🗪

2:04:05Jim0_o Any plans to create different types of lighting as in Room X is lit like a summers day while Room Y is contrasted and dark like a film Noir? (Or would you have all this done in the assets, maybe?)

🗪

2:04:44Close things down

🗩

2:04:44Close things down

🗩

2:04:44Close things down

🗩

Keyboard Navigation

Global Keys

Menu toggling

In-Menu and Index Controls

Quotes and References Menus and Index

Quotes, References and Credits Menus

Filter Menu

Filter and Link Menus

Credits Menu