[55:23][Blackboard: Fix up the terminology in accordance with the OpenGL spec]
[58:01][Blackboard: Perspective projection]
[1:00:32][Blackboard: Projecting to the screen using a relationship of similar triangles]
[1:02:37][Blackboard: Matrix multiplication doesn't allow for dividing]
[1:05:14][Blackboard: How OpenGL provides for one divide operation, normalisation of the vector by its w coordinate, in order to compute correct perspective]
[1:08:00][Blackboard: Implementing our own perspective projection and why we compute z]
[1:10:11][Double-check the OpenGL spec on coordinate transformations[ref
site="OpenGL"
page="The OpenGL Graphics System: A Specification"
[1:13:03][Blackboard: Performing the near plane clipping before moving into the -1 to 1 space]
[1:16:33][Blackboard: Recap what our perspective transform must accomplish]
[1:19:30][Blackboard: The Z-buffer and near and far clip planes]
[1:21:56][Further reading: W-buffer; infinite far clip plane; disable far clip plane]
[1:23:46][Blackboard: Camera space, and getting the effects we want out of the projection matrix]
[1:26:47][handmade_render_group.cpp: Consider how our perspective transform is currently happening]
[1:30:04][handmade_opengl.cpp: Temporarily make OpenGLSetScreenSpace() calculate the height dimension based on the width and run the game to see what that does]
[1:31:14][handmade_render_group.cpp: Prevent GetRenderEntityBasisP() from adding CameraTransform->ScreenCenter to the Perspective computation, and run the game to see what that has done]
[1:32:23][handmade_opengl.cpp: Shuffle the projection matrix initialised in OpenGLSetScreenspace(), and run the game to see that our transform is correct, but the sorting is not]
[1:33:52][handmade_render_group.cpp: Consider what the MetersToPixels value is contributing to GetRenderEntityBasisP()]
[1:36:47][Blackboard: How MetersToPixels passes through the pipeline]
[1:41:20][handmade_render.h: Consider how to simplify MetersToPixels]
[1:42:14][handmade_opengl.cpp: Make OpenGLSetScreenspace() compute the Width and Height more simply]
[1:43:34][handmade_render.h: Prevent GetStandardCameraParams() from taking WidthInPixels into account in the MetersToPixels computation, and run the game]
[1:44:29][handmade_render.h: Remove WidthOfMonitor from the camera_params struct and rename MetersToPixels to WorldScale]
[1:47:11][handmade_render_group.cpp: Consider simplifying the ProjectedXY computation]
[1:48:45][handmade_render_group.h: Remove the render_entry_coordinate_system struct]
[1:49:50][handmade_render_group.h: Make the entity_basis_p_result struct contain a 3D coordinate, and propagate that change]
[1:56:21][Run the game with everything being passed down as 3D, and consider how we'll proceed]
[1:58:27][@rivten][Concerning the "homogeneous" use. The "homogeneous" word indeed comes from mathematics. Homogeneous is used for mathematical objects that have some scalability property. Here, p0 = (x, y, z, 1) and p1 = (2x, 2y, 2z, 2) represent the same point in space (but p1 = 2 * p0 mathematically speaking). Therefore the usage of homogeneous coordinates and homogeneous matrices here]
[2:00:03][@vaualbus][Turn off the sorting so we won't have flashing]
[2:01:58][handmade_render.cpp: Temporarily make SortEntries() set ShouldSort to false and run the game to see how that affects it]
[2:03:20][@kim_jorgensen][Debug UI is broken?]
[2:05:25][@elxenoaizd][I was reading the article from Fabian about his optimizations on the Intel software renderer and I saw him doing the clipping in a very simple manner in screenspace, where he takes the min / max between the pixel and screen dimensions because he was using orient2d and barycentric coordinates to rasterize. The clipping was only four lines of code and easy to understand. Why does OpenGL have to do complicated homogeneous clipping?[ref
[2:07:58][@rivten][In practice, does the camera near plane and the camera focal length really differ? I would expect them to be the same]
[2:10:37][@elxenoaizd][Are we going to continue supporting the software renderer in 3D as well?]
[2:11:07][@elxenoaizd][If I set the near clip plane to, say, 10, does that mean that entities with a world space Z less than 10 would be clipped? Just trying to make sure that near / far clip planes are defined in terms of world space]
[2:13:35][@elxenoaizd][Can you use the GPU to bypass the OpenGL or DirectX API / pipeline and just use compute shaders to implement your own pipeline that's also running on the GPU?]
[2:16:51][@rivten][So, to avoid Z fighting, should we have dynamical near / far planes? I mean that their values should change according to the nearest and the farthest objects we want to render in order for the near / far plane space to be as small as possible?[ref
[2:22:50][@elxenoaizd][Does any of that clip and projection math change if we change the rendering technique that we're using? Say, rasterizing vs raytracing or voxels]
