[0:00][Recap and set the stage for the day, creating a hierarchy of :lighting nodes][:rendering :speech]
[0:45][:Run the game to see our current :lighting solution running at \~30 fps][:rendering]
[4:28][Determine to make SplitBox() do something intelligent][:geometry :lighting :optimisation :rendering :speech]
[5:07][Introduce AddBoxStorage() and AddBoxReference()][:geometry :lighting :optimisation :rendering]
[9:04][A few words on box storage vs box referencing][:geometry :lighting :rendering :speech]
[9:27][Implement AddBoxReference() and AddBoxStorage()][:geometry :lighting :optimisation :rendering]
[12:36][Consider how to store our partitioned boxes][:geometry :lighting :memory :rendering :speech]
[15:03][Begin to enable BuildSpatialPartitionForLighting() to build the spatial hierarchy][:geometry :lighting :optimisation :rendering]
[22:08][Introduce a rectangle3 version of Union()][:geometry :mathematics]
[22:56][Continue to enable BuildSpatialPartitionForLighting() to build the spatial hierarchy][:geometry :lighting :optimisation :rendering]
[24:54][Introduce InvertedInfinityRectangle3() and GetRadius()][:geometry :mathematics]
[27:20][Finish setting up BuildSpatialPartitionForLighting() to call SplitBox()][:geometry :lighting :optimisation :rendering]
[33:08][Spatial Partition "In Place"][:blackboard :geometry :memory]
[36:18][Add ScratchA and ScratchB arrays to lighting_solution and enable BuildSpatialPartitionForLighting() to use them][:geometry :lighting :optimisation :rendering]
[38:26][Begin to enable SplitBox() to split a box along each axis][:geometry :lighting :optimisation :rendering]
[44:56][Consult our MergeSort() to see how it stores the data][:memory :research :sorting]
[46:08][Try to enable SplitBox() to ping-pong between the buffers][:geometry :lighting :optimisation :rendering]
[1:07:54][Step through BuildSpatialPartitionForLighting() and SplitBox() to inspect their values][:geometry :lighting :optimisation :rendering :run]
[1:13:35][Make SplitBox() break after splitting][:geometry :lighting :optimisation :rendering]
[1:13:54][Continue to step through SplitBox()][:geometry :lighting :optimisation :rendering :run]
[1:14:36][:Run the game to see our resulting :lighting][:rendering]
[1:16:35][Determine to debug the splitting][:geometry :lighting :optimisation :rendering :speech]
[1:17:38][Delete AddOverlappingBoxes() and read closely through RayCastRecurse()][:geometry :lighting :optimisation :rendering :research]
[1:19:27][Note that RayCastRecurse() is not checking to see if we are inside a bounding box][:geometry :lighting :optimisation :rendering :speech]
[1:20:47][Introduce IsInRectangleCenterHalfDim() to enable RayCastRecurse() to check if we are inside a box][:geometry :lighting :mathematics :optimisation :rendering]
[1:26:06][:Run the game to see that that sort of fixed us][:geometry :lighting :optimisation :rendering]
[1:27:12][:Run the game to see our more realistic :lighting situation][:rendering]
[1:28:50][Q&A][:speech]
[1:29:21][@jacksonbanan][Q: Do you even like sushi?][:trivia]
[1:30:00][@insobot][89 minutes into the main stream. 31 until Q&A. (based on NOTE)]
[1:31:02][@Brian][Q: This is a generic question, but for an example AddBoxStorage demonstrates this. I see Asserts are used to find exceptions in debug mode. What would be the way to handle a failed Assert in release mode, assuming in release Assert is just stubbed. Is it a case where most if not all problems would be found during testing and not needed to make changes for release?]
[1:33:03][Add a TIMED_FUNCTION() in BuildSpatialPartitionForLighting()][:geometry :optimisation :profiling]
[1:33:32][:Run the game to see the :performance of BuildSpatialPartitionForLighting()][:geometry :optimisation]
[1:34:12][@0b0000000000000][Q: Couldn't you have just used a stack or a queue to do a depth first search or breadth first search? You init the stack with the root box, and then splitting just adds to it, if the stack is empty you're done?]
[1:34:49][@Brian][Q: Will we need to go through each Assert call and eventually add ways to handle failure cases? Or only when we run into an issue down the line and fix those specific failures? I ask because I add Asserts to my code but then wonder what is the proper way to handle failures when I am not building release]
[1:36:06][@dragoonx6][Q: I noticed how you barely have any code / keyword highlighting in your editor. Do you not like that?]
[1:36:32][@jacksonbanan][Q: Do you wish you never started the Sushi game thing to begin with or do you feel like you didn't waste your time and you actually got something out of it?]
[1:37:45][@dragoonx6][Q: Like I have here for example[ref
site=https://puu.sh/yC8CO.png
url=https://puu.sh/yC8CO.png]]
[1:38:20][@jim0_o][Q: Have you thought of making a stream be a recap of your code, kind of looking over it and explaining it to catch people up who can't watch it all?]
[1:39:04][@zennmystic][Q: Started slightly late and the pre-stream went on for longer than usual]
[1:39:40][@bigmofo1][Q: Can you add partition box visualization? Or is that not valuable?][:"debug visualisation"]
[1:40:28][@deadlines_over][How close are you to finishing?]
[1:40:58][@menelaus35][Q: That frame profiler :UI, is that custom made on stream? Looks good][:profiling]
[1:41:06][Show off the profiler][:run :profiling]
[1:43:13][@deadlines_over][Q: What do you think of functional programming[ref
