Index hero/code550
This commit is contained in:
Matt Mascarenhas
parent
483091684e
commit
06c886f563
|
|
@ -0,0 +1,69 @@
|
|||
[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="SIMD Raycast Point and Normal Computations" vod_platform=youtube id=BzrMiEVa3gs annotator=Miblo]
|
||||
[0:00][Recap and set the stage for the day][:speech]
|
||||
[2:14][Putting six-rayed light probes into the :lighting system][:speech]
|
||||
[3:16][Our old box-intersection testing in RayCast()][:lighting :speech]
|
||||
[4:54][Our box :lighting primitives][:run]
|
||||
[7:00][Our old box-intersection testing and reporting in RayCast(), continued][:lighting :speech]
|
||||
[10:31][Ways of Getting Intersection Normals for AABB][:blackboard :lighting]
|
||||
[14:31][Consider storing the BoxMin and BoxMax in lighting_box][:lighting]
|
||||
[15:39][Getting an Approximate Normal from an Ellipsoid-like AABB][:blackboard :lighting]
|
||||
[18:50][Getting Accurate AABB Intersection Normals][:blackboard :lighting]
|
||||
[24:52][Set up RayCast() to compute the intersection normal for a unit cube lighting_box][:lighting]
|
||||
[29:39][Could we compute our intersection normal more efficiently?][:blackboard :lighting]
|
||||
[32:26][Consider the cost of our intersection normal computation in RayCast()][:lighting :performance :research]
|
||||
[34:31][Computing the intersection normal only of box hits, saving the box scale and centre][:blackboard :lighting]
|
||||
[37:33][Let RayCast() only set the box centre and scale, making ComputeLightPropagation() compute the intersection normal][:lighting]
|
||||
[40:17][The cost and availability of _mm_blend_ps[ref
|
||||
site=Intel
|
||||
page="Intel Intrinsics Guide"
|
||||
url=https://software.intel.com/sites/landingpage/IntrinsicsGuide/][ref
|
||||
site=Valve
|
||||
page="Steam Hardware & Software Survey"
|
||||
url=https://store.steampowered.com/hwsurvey][ref
|
||||
site=uops.info
|
||||
url=https://uops.info/table.html]][:performance :research]
|
||||
[44:25][Make RayCast() select the RefColor and at the end compute the Result, augmenting raycast_result with P, Normal and RefColor[ref
|
||||
site=Intel
|
||||
page="Intel Intrinsics Guide"
|
||||
url=https://software.intel.com/sites/landingpage/IntrinsicsGuide/]][:lighting]
|
||||
[57:37][Introduce SignBitFrom()][:mathematics]
|
||||
[59:37][Finish making RayCast() set the HitNormal from Masks][:lighting]
|
||||
[1:07:49][Clean up compile errors, making RayCast() compute BoxRadius and its approximate inverse, introducing ApproxOneOver()[ref
|
||||
site=Intel
|
||||
page="Intel Intrinsics Guide"
|
||||
url=https://software.intel.com/sites/landingpage/IntrinsicsGuide/]][:lighting :mathematics :performance]
|
||||
[1:22:33][Consider the potential speed improvement of RayCast()][:lighting :performance :speech]
|
||||
[1:23:39][Determine to make ComputeLightPropagation() operate wide][:lighting :speech]
|
||||
[1:24:52][Lament SIMD's lack of fetching instructions][:speech]
|
||||
[1:26:09][Consider how to make our :lighting operate wide][:speech]
|
||||
[1:30:08][Q&A][:speech]
|
||||
[1:31:12][@ellesar1][Q: Origin, BoxCenter, and HitP are on the same line. Why do we use HitP – Center for the normal computation, and not Origin – Center? The direction should be the same. Problems could arise if origin is within the box (esp if origin = center), but I don't think that's a use case. I understand the HitP is useful for other purposes, just wondering if it's actually necessary for the normals computation][:lighting]
|
||||
[1:32:37][@uplinkcoder][Q: I've just added the C++ standard reference to the issue type-name member-name, issue.[ref
|
||||
site=GitHub
|
||||
page="HandmadeHero / cpp / Linux Problems"
|
||||
url=https://github.com/HandmadeHero/cpp/issues/109] I agree it's a stupid warning, but there seems to be no way to disable it in GCC][:language]
|
||||
[1:33:06][@ellesar1][Ahh, thanks for explaining it once more. I get it now][:lighting]
|
||||
[1:35:22][@rooctag][Q: Why are the light probes cubes and not spheres?][:lighting]
|
||||
[1:36:29][@uplinkcoder][Q: GCC is following the standard. It's just that the standard is stupid[ref
|
||||
site=GitHub
|
||||
page="HandmadeHero / cpp / Linux Problems"
|
||||
url=https://github.com/HandmadeHero/cpp/issues/109]][:language]
|
||||
[1:45:33][@mr4thdimention][The good idea in C++ was "Let's start with C"][:language]
|
||||
[1:46:12][@maliusarth][Q: Should I work on a game engine in C / C++ or just put out games in Unity / Unreal until Jai comes out?][:language]
|
||||
[1:49:14][@bulmanator][Q: Is there any reading material you recommend for more serious real-time :lighting like this (Papers, books, even blog posts etc.)? I've done simple diffuse lighting before but nothing beyond that[ref
|
||||
site=SIGGRAPH
|
||||
url=https://www.siggraph.org/]]
|
||||
[1:51:00][@saidwho12][The PBR book is good book[ref
|
||||
site="Matt Pharr and Greg Humphreys"
|
||||
page="Physically Based Rendering / 8.4 Microfacet Models"
|
||||
url=http://www.pbr-book.org/3ed-2018/Reflection_Models/Microfacet_Models.html]]
|
||||
[1:53:23][@oliverthebestcat][What do you think is a good idea in games? I feel like I tune into so many programmer streams telling me this and that is terrible, but not really giving me another option. I don't want the answer to be "wait for Jai"! What is good today?][:language]
|
||||
[1:55:21][@sapper123][Jai demo on Macros is in an hour and a half. Just a reminder for chat][:language]
|
||||
[1:56:53][@oliverthebestcat][But it's pretty difficult to listen to you or [@naysayer88 Jon]'s stream when it's all just "this is bad, that is bad". But hey, maybe it's true?][:language]
|
||||
[1:58:02][Shut down, with a plug of [@naysayer88 Jon]'s stream[ref
|
||||
site=Twitch
|
||||
page=Naysayer88
|
||||
url=https://twitch.tv/naysayer88] and Handmade Seattle[ref
|
||||
site="Handmade Seattle"
|
||||
url=https://www.handmade-seattle.com/]][:speech]
|
||||
[/video]
|
||||
Loading…
Reference in New Issue