73 lines
6.7 KiB
Plaintext
73 lines
6.7 KiB
Plaintext
|
[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Debugging Lighting Transfer" vod_platform=youtube id=iqVzS326DsA annotator=Miblo]
|
||
|
|
[0:07][Recap and set the stage for the day]
|
||
|
|
[1:14][Run the game to see how the lighting is looking at the moment]
|
||
|
|
[7:39][Note some oddities in the lighting solution]
|
||
|
|
[10:14][handmade_render_group.cpp: Prevent the ambient occlusion code from running and run the game to still see the bright flashes]
|
||
|
|
[11:50][handmade_config.h: Only do one pass of the lighting solution, and run the game to see that this is relatively stable]
|
||
|
|
[13:14][handmade_config.h: Add Global_Renderer_Occlusion_IterationCount for LightingTest() to use]
|
||
|
|
[13:43][Run the game doing two ambient occlusion passes]
|
||
|
|
[14:44][handmade_config.h: Switch to the game view, with two ambient occlusion passes, and run the game to see how that looks]
|
||
|
|
[18:01][handmade_config.h: Increase the number of lighting iteration passes and run the game with the determination to investigate the flashes]
|
||
|
|
[20:35][Launch Milton and try out the tablet tracking]
|
||
|
|
[22:58][Blackboard: Light Conservation]
|
||
|
|
[28:45][Blackboard: Converging on a good lighting solution]
|
||
|
|
[30:00][handmade_render_group.cpp: Consider making emission a first-pass-only process]
|
||
|
|
[32:40][Blackboard: Occluded Reflectors, and Total Emittance]
|
||
|
|
[37:37][The difficulty of parallelised summation]
|
||
|
|
[39:48][Blackboard: Radiosity, and stabilising the contribution of light by multiple proximate reflectors, with a recommendation to read literature on the problem]
|
||
|
|
[43:37][Blackboard: Considering how to handle over-contribution of light distribution]
|
||
|
|
[48:04][handmade_render_group.cpp: Organise lighting_element to aid our conceptualisation of the light conservation problem]
|
||
|
|
[53:18][Hit an error in OpenGLDebugCallback()]
|
||
|
|
[54:30][Blackboard: All light must go somewhere]
|
||
|
|
[55:33][handmade_render_group.cpp: Enable LightingTest() to make RefC converge towards 0, and track the transference and accumulation of light]
|
||
|
|
[1:03:25][handmade_render_group.cpp: Enable LightingTest() to correct for the wrongness of the transfer]
|
||
|
|
[1:11:10][Step in to LightingTest() and ]
|
||
|
|
[1:13:10][Consider how to handle emission]
|
||
|
|
[1:13:46][handmade_render_group.cpp: Prevent LightingTest() from performing the correction and just letting the light bounce ad infinitum]
|
||
|
|
[1:14:27][Run the game to see the flickery results]
|
||
|
|
[1:14:56][handmade_render_group.cpp: Let LightingTest() perform the correction again, and run the game to see the flickering still]
|
||
|
|
[1:15:36][Consider how to handle the total light transfer]
|
||
|
|
[1:17:35][handmade_render_group.cpp: Add PhotonsToSend and PhotosReceived to lighting_element, for LightingTest() to use]
|
||
|
|
[1:22:14][handmade_render_group.cpp: Enable LightingTest() to draw the photons]
|
||
|
|
[1:23:31][Run the game to see the photons transference]
|
||
|
|
[1:24:08][handmade_render_group.cpp: Assert in LightingTest() that PhotonsToSend <= TotalPhotonCount, run the game, hit that assertion and investigate why]
|
||
|
|
[1:26:43][handmade_render_group.cpp: Make LightingTest() actually multiply in the correction]
|
||
|
|
[1:27:14][Run the game in release, and see that it is more correct but that the flickering is still there]
|
||
|
|
[1:30:36][Run the game on a loop and change the lighting iteration count to see how that affects it]
|
||
|
|
[1:32:40][handmade_world_mode.cpp: Prevent AddPlayer() from adding any body parts and hit points]
|
||
|
|
[1:34:06][Run the game and move just the light, to determine that the hero himself was causing the flickering problem]
|
||
|
|
[1:36:39][handmade_render_group.cpp: Make LightingTest() strictly sum the FrontEmitC, and run the game without flickering, noting that the occluders are spaced far apart]
|
||
|
|
[1:39:31][Determine to fix the distance falloff for close objects]
|
||
|
|
[1:40:11][handmade_render_group.cpp: Let LightingTest() temper the FrontEmitC by the number of lighting iterations]
|
||
|
|
[1:41:42][handmade_render_group.cpp: Remove PhotonsToSend and PhotonsReceived from lighting_element]
|
||
|
|
[1:42:34][Run the game to see the stable light]
|
||
|
|
[1:42:44][handmade_world_mode.cpp: Let AddPlayer() add body parts, and run the game noting that these body parts are very bright]
|
||
|
|
[1:44:28][handmade_render_group.cpp: Fix the DistanceFalloff computation in LightingTest()]
|
||
|
|
[1:44:44][Blackboard: Distance Falloff]
|
||
|
|
[1:48:25][Run the game to see that the flickering has gone]
|
||
|
|
[1:49:27][handmade_world_mode.cpp: Make AddStandardRoom() draw the walls in red]
|
||
|
|
[1:51:18][Run the game to see if we get red light bleeding from the walls]
|
||
|
|
[1:51:53][handmade_config.h: Perform two ambient occlusion passes and run the game]
|
||
|
|
[1:54:34][Q&A]
|
||
|
|
[1:54:47][@macielda][Is it supposed to be Square(...) and not SquareRoot(...)?]
|
||
|
|
[1:56:15][handmade_render_group.cpp: Make LightingTest() prevent the DistanceFalloff from getting below 1]
|
||
|
|
[1:56:44][Run the game to see how that looks]
|
||
|
|
[1:57:58][@the_8th_mage][Now we don't need to do a global pass to normalize light?]
|
||
|
|
[1:59:07][@macielda][Is it useful to convert the surface color from RGB to YUV in these equations, as in using Y to modulate light contribution somehow?]
|
||
|
|
[2:00:55][@the_8th_mage][Do you know how much does a GPU gather cost compared to a load from a linear memory read?]
|
||
|
|
[2:02:01][@the_8th_mage][I wrote GPU, not CPU]
|
||
|
|
[2:02:37][handmade_config.h: Play with the lighting IterationCount and run]
|
||
|
|
[2:03:17][@cubercaleb][Spectral lighting is something I never heard of before. Can you point out some good resources on the topic?[ref
|
||
|
|
site="Matt Pharr and Greg Humphreys"
|
||
|
|
page="Physically Based Rendering"
|
||
|
|
url="http://pbrt.org/"]]
|
||
|
|
[2:05:44][@the_8th_mage][In CPU it's much more efficient to read a cache line using _mm_load and not use the gather commands. Is the same true of the GPU?]
|
||
|
|
[2:12:25][@the_8th_mage][Thanks, so you usually don't want to swizzle it yourself?]
|
||
|
|
[2:15:59][@the_8th_mage][Is HMCon 3 still at the start of 2018?]
|
||
|
|
[2:16:32][@Brian][ctray improvement: Would you be so kind as to give a suggestion of how you tackle saving the day? Do you prefer temp files (i.e. in %AppData%)? Just keep it simple like how you read settings.ctray. Should I look at how you save state like in ctime? I can try to tackle an alternative this week for I do need to become more confident in reading / writing to files]
|
||
|
|
[2:18:04][@Brian][But that's what I did! I made it an ini file and rewrote that]
|
||
|
|
[2:19:15][@macielda][Is it possible to mode-change monitor frequency nowadays (say from 75Hz to 60Hz) so I always try to get my game loop to run at 60Hz?]
|
||
|
|
[2:22:07][@Brian][ctray question: As an exercise, I would like to investigate the cost of just bringing the overlays to the top and checking first if the overlays need to be brought forward. What should I look for? Should I profile the calls? Should I run it continuously to see if I get an error case? I realize this may not be the best thing to use as an example, but it was something I struggled with]
|
||
|
|
[2:24:35][Close that]
|
||
|
|
[/video]
|