WEBVTT

1
00:00:00.040 --> 00:00:01.879
<v Speaker 1>Hey there, and welcome back to the deep Dive. Today,

2
00:00:01.879 --> 00:00:04.120
<v Speaker 1>we're taking a journey into the intricate world of modern

3
00:00:04.160 --> 00:00:08.519
<v Speaker 1>three DE graphics, that magical realm powering everything from your

4
00:00:08.519 --> 00:00:12.599
<v Speaker 1>favorite Triple A games to cutting edge augmented reality experiences.

5
00:00:12.919 --> 00:00:15.480
<v Speaker 1>We've got an incredible set of sources for this deep

6
00:00:15.560 --> 00:00:18.920
<v Speaker 1>dive excerpts from the Vulcan three D Graphics Rendering Cookbook,

7
00:00:18.960 --> 00:00:22.079
<v Speaker 1>second Edition. And this is just any book. It's penned

8
00:00:22.079 --> 00:00:26.719
<v Speaker 1>by real industry titans. We're talking Sergei Kosarewski formally rendering

9
00:00:26.760 --> 00:00:29.800
<v Speaker 1>lad at Ubisoft red Links now leading Vulcan development at Meta,

10
00:00:29.879 --> 00:00:32.920
<v Speaker 1>and Alexi Medvedev ar tech lead at Meta and also

11
00:00:33.200 --> 00:00:35.399
<v Speaker 1>the Kronos Chair for three D Formats.

12
00:00:35.560 --> 00:00:37.520
<v Speaker 2>Yeah, these are folks who've been in the trenches ship

13
00:00:37.640 --> 00:00:41.359
<v Speaker 2>massive games, designed real time rendering tech for years, really

14
00:00:41.399 --> 00:00:42.759
<v Speaker 2>know their stuff exactly.

15
00:00:43.479 --> 00:00:46.200
<v Speaker 1>So our mission for you today is a shortcut, a

16
00:00:46.240 --> 00:00:49.799
<v Speaker 1>shortcut to understanding the core pillars of three D graphics rendering.

17
00:00:50.359 --> 00:00:54.200
<v Speaker 1>We'll unpack how engineers achieve that astonishing performance, how they

18
00:00:54.240 --> 00:00:57.119
<v Speaker 1>craft that jaw dropping realism, and what it takes to

19
00:00:57.119 --> 00:01:00.640
<v Speaker 1>build these experiences across all sorts of different platforms. Consider

20
00:01:00.679 --> 00:01:03.039
<v Speaker 1>this your fast track to being truly well informed about

21
00:01:03.039 --> 00:01:07.480
<v Speaker 1>the incredible engineering under the hood. So let's jump right in. Okay,

22
00:01:07.480 --> 00:01:11.079
<v Speaker 1>first up, the book immediately highlights Vulcan. Now for anyone

23
00:01:11.120 --> 00:01:14.120
<v Speaker 1>following graphics its name is absolutely everywhere. But what makes

24
00:01:14.120 --> 00:01:15.680
<v Speaker 1>this API so significant?

25
00:01:15.680 --> 00:01:19.400
<v Speaker 2>Why Vulcan, Well, what's fascinating here is that Vulcan's popularity.

26
00:01:19.439 --> 00:01:22.640
<v Speaker 2>It's not just hype, you know, it's a real foundational shift.

27
00:01:22.680 --> 00:01:25.200
<v Speaker 2>As Anton Kaplanion from Intel points out in the forward,

28
00:01:25.480 --> 00:01:28.599
<v Speaker 2>it really boils down the two main things, incredible performance

29
00:01:28.599 --> 00:01:31.719
<v Speaker 2>and truly being cross platform. It's designed to give developers

30
00:01:31.760 --> 00:01:34.879
<v Speaker 2>really granular control over the GPU, much more than older

31
00:01:34.920 --> 00:01:37.439
<v Speaker 2>APIs like OpenGL or directex eleven.

32
00:01:37.599 --> 00:01:38.959
<v Speaker 1>And that control is the key.

33
00:01:38.959 --> 00:01:43.079
<v Speaker 2>It's absolutely essential. It lets developers push the absolute limits

34
00:01:43.120 --> 00:01:47.799
<v Speaker 2>of graphics of efficiency. Doesn't matter if you're targeting Windows, Linux,

35
00:01:47.879 --> 00:01:51.359
<v Speaker 2>high end Android phones, even consoles. Now it fundamentally changed

36
00:01:51.359 --> 00:01:54.239
<v Speaker 2>how developers could talk to the hardware. Really lets them

37
00:01:54.239 --> 00:01:56.560
<v Speaker 2>squeeze out every last drop of performance.

38
00:01:56.640 --> 00:02:00.480
<v Speaker 1>Okay, that granular control, that high performance sounds like a

39
00:02:00.519 --> 00:02:05.239
<v Speaker 1>developer's dream, definitely, but maybe also a bit of a

40
00:02:05.319 --> 00:02:08.400
<v Speaker 1>nightmare to set up. Initially, where does someone even begin

41
00:02:08.639 --> 00:02:11.479
<v Speaker 1>to build a dev environment for something that powerful must

42
00:02:11.479 --> 00:02:13.199
<v Speaker 1>require pretty specific toolkit.

43
00:02:13.280 --> 00:02:15.520
<v Speaker 2>Right, You're right, it has its requirements, but the book

44
00:02:15.560 --> 00:02:17.919
<v Speaker 2>actually outlines a very clear path. You'd start with the

45
00:02:18.560 --> 00:02:22.159
<v Speaker 2>standard toolkit basically Microsoft Visual Studio twenty twenty two for

46
00:02:22.360 --> 00:02:25.039
<v Speaker 2>C plus plus A. You need to get for version control,

47
00:02:25.319 --> 00:02:28.639
<v Speaker 2>C MAKE for building projects, Python, maybe for scripting, pretty

48
00:02:28.639 --> 00:02:31.560
<v Speaker 2>standard dev stuff. Okay, but here's the critical part. For Vulcan.

49
00:02:32.039 --> 00:02:34.560
<v Speaker 2>You need the full Vulcan SDK, not just the header

50
00:02:34.560 --> 00:02:35.719
<v Speaker 2>files you might find lying.

51
00:02:35.599 --> 00:02:36.680
<v Speaker 1>Reund full SDK.

52
00:02:36.919 --> 00:02:40.840
<v Speaker 2>Why is that because the SDK gives you essential validation layers.

53
00:02:41.400 --> 00:02:44.719
<v Speaker 2>These are absolute life savers for debugging when you're working

54
00:02:44.719 --> 00:02:47.360
<v Speaker 2>at such a low level. They catch mistakes. And it

55
00:02:47.479 --> 00:02:52.120
<v Speaker 2>includes the GLSL shader compiler, which you obviously need. And

56
00:02:52.240 --> 00:02:54.719
<v Speaker 2>of course, always make sure you have the latest GPU

57
00:02:54.800 --> 00:02:56.240
<v Speaker 2>drivers installed. That's crucial.

58
00:02:56.479 --> 00:03:00.280
<v Speaker 1>Got it. So, validation layers, shader compiler, latest drivers. Without

59
00:03:00.280 --> 00:03:03.759
<v Speaker 1>those specific Vulcan bits, you're kind of flying blind pretty much. Yeah,

60
00:03:03.759 --> 00:03:06.479
<v Speaker 1>so I've got the foundational tools sorted. But even with

61
00:03:06.520 --> 00:03:10.960
<v Speaker 1>those building blocks, Vulcan has a reputation for being well complex,

62
00:03:11.479 --> 00:03:14.680
<v Speaker 1>a steep learning curve. Are there any of those aha tools?

63
00:03:14.759 --> 00:03:18.000
<v Speaker 1>Or libraries mentioned. That really helps simplify things, especially when

64
00:03:18.000 --> 00:03:20.280
<v Speaker 1>you're just starting out, make life a bit easier.

65
00:03:20.479 --> 00:03:23.360
<v Speaker 2>Yeah, that's a really important point. The book highlights two

66
00:03:23.479 --> 00:03:26.479
<v Speaker 2>standout libraries, GLFW and Taskflow.

67
00:03:26.719 --> 00:03:28.319
<v Speaker 1>GLFW, what's that handle?

68
00:03:28.439 --> 00:03:31.759
<v Speaker 2>GLFW is fantastic because it handles all that operating system

69
00:03:31.840 --> 00:03:35.759
<v Speaker 2>level boilerplate, you know, creating windows, managing the graphics context,

70
00:03:35.960 --> 00:03:39.199
<v Speaker 2>capturing keyboard and mouse input. It just hides all that complexity,

71
00:03:39.360 --> 00:03:42.080
<v Speaker 2>lets you focus on the actual Vulcan rendering code instead

72
00:03:42.080 --> 00:03:43.000
<v Speaker 2>of fighting with the OS.

73
00:03:43.240 --> 00:03:46.000
<v Speaker 1>Okay, that makes sense, takes away the platform specific headaches

74
00:03:46.560 --> 00:03:47.319
<v Speaker 1>and taskflow.

75
00:03:47.400 --> 00:03:50.719
<v Speaker 2>Taskflow is different. It's a C plus plus header only library,

76
00:03:50.840 --> 00:03:53.400
<v Speaker 2>sumer easy to integrate, and it's a game changer for

77
00:03:53.479 --> 00:03:57.439
<v Speaker 2>multi threading. Think of it like conducting an orchestra of CPU. Course.

78
00:03:57.520 --> 00:04:01.039
<v Speaker 2>It helps you write parallel programs, manage really complex task

79
00:04:01.080 --> 00:04:05.479
<v Speaker 2>dependencies efficiently. Dependencies like like in modern rendering pipelines, you

80
00:04:05.560 --> 00:04:09.000
<v Speaker 2>often have these frame graphs where one rendering pass depends

81
00:04:09.000 --> 00:04:12.240
<v Speaker 2>on another finishing or maybe you want to generate your

82
00:04:12.319 --> 00:04:15.719
<v Speaker 2>Vulcan command buffers across multiple CPU core simultaneously.

83
00:04:15.840 --> 00:04:17.879
<v Speaker 1>Ah okay, So distributing.

84
00:04:17.399 --> 00:04:20.920
<v Speaker 2>The work exactly. Task flow helps manage all that parallelism.

85
00:04:20.959 --> 00:04:23.639
<v Speaker 2>It's really about leveraging every bit of processing power your

86
00:04:23.720 --> 00:04:26.319
<v Speaker 2>CPU has available, super important for performance.

87
00:04:26.480 --> 00:04:29.560
<v Speaker 1>Right makes sense. Okay, so we've got our environment, we've

88
00:04:29.600 --> 00:04:33.120
<v Speaker 1>got tools to help manage complexity. Now the fun part

89
00:04:33.639 --> 00:04:37.399
<v Speaker 1>making things look real? How do modern graphics achieve that

90
00:04:37.519 --> 00:04:40.120
<v Speaker 1>stunning level of realism we see in today's games and

91
00:04:40.240 --> 00:04:42.759
<v Speaker 1>you know advanced dar It feels like it's gone way

92
00:04:42.800 --> 00:04:44.720
<v Speaker 1>beyond just slapping on a texture.

93
00:04:44.800 --> 00:04:49.720
<v Speaker 2>Oh. Absolutely. The answer largely is physically based rendering or PBR.

94
00:04:50.040 --> 00:04:53.319
<v Speaker 1>PBR heard that term a lot. What's the core idea?

95
00:04:53.560 --> 00:04:57.720
<v Speaker 2>The core principle is energy conservation. It sounds technical, but

96
00:04:57.759 --> 00:05:01.399
<v Speaker 2>it's a fundamental law from physics. It basically asserts that

97
00:05:01.439 --> 00:05:04.360
<v Speaker 2>the amount of light hitting any point on a surface

98
00:05:04.720 --> 00:05:07.399
<v Speaker 2>has to equal the total amount of light that gets reflected,

99
00:05:07.480 --> 00:05:10.639
<v Speaker 2>transmitted through it, or absorbed by it. No energy is

100
00:05:10.720 --> 00:05:12.319
<v Speaker 2>magically created or destroyed.

101
00:05:12.439 --> 00:05:16.519
<v Speaker 1>Okay, energy conservation. Why is that so transformative for graphics?

102
00:05:16.800 --> 00:05:21.600
<v Speaker 2>Because it forces assets, models, materials to behave realistically and

103
00:05:22.000 --> 00:05:26.959
<v Speaker 2>crucially consistently under any lighting condition. It prevents those weird,

104
00:05:27.079 --> 00:05:29.800
<v Speaker 2>unnatural kind of glowing or two dark results you sometimes

105
00:05:29.839 --> 00:05:32.839
<v Speaker 2>saw in older engines. It grounds the visuals in reality,

106
00:05:33.079 --> 00:05:33.759
<v Speaker 2>so it moves.

107
00:05:33.560 --> 00:05:35.720
<v Speaker 1>Away from artists just guessing how light should look.

108
00:05:35.800 --> 00:05:39.120
<v Speaker 2>Pretty much, it's like shifting from artistic interpretation to applying

109
00:05:39.160 --> 00:05:41.720
<v Speaker 2>the actual laws of physics. It leads to much more

110
00:05:41.759 --> 00:05:45.199
<v Speaker 2>believable and predictable results, which also makes artists' lives easier

111
00:05:45.199 --> 00:05:45.920
<v Speaker 2>in the long run.

112
00:05:46.199 --> 00:05:49.759
<v Speaker 1>So, sticking with that energy conservation idea, when light actually

113
00:05:49.800 --> 00:05:52.240
<v Speaker 1>hits a surface, how does PBR model the different ways

114
00:05:52.240 --> 00:05:53.040
<v Speaker 1>it can interact.

115
00:05:53.360 --> 00:05:56.120
<v Speaker 2>Well, we mainly observe two key types of light interaction

116
00:05:56.199 --> 00:05:59.920
<v Speaker 2>in PBR models. First, there's diffuse light. That's when light

117
00:06:00.000 --> 00:06:03.279
<v Speaker 2>penetrates the surface just a little bit, scatters around inside,

118
00:06:03.439 --> 00:06:05.879
<v Speaker 2>and then re emerges at different points. Think of a

119
00:06:05.920 --> 00:06:08.639
<v Speaker 2>matte surface like rough plastic or dry wall.

120
00:06:08.800 --> 00:06:10.560
<v Speaker 1>Okay, so it scatters. What's the other type?

121
00:06:10.639 --> 00:06:14.319
<v Speaker 2>The other is specular reflection. That's when light bounces directly

122
00:06:14.360 --> 00:06:17.040
<v Speaker 2>off the surface, more like a mirror. This is dominant

123
00:06:17.079 --> 00:06:20.800
<v Speaker 2>on smooth, polished areas, metals plastics.

124
00:06:20.319 --> 00:06:22.800
<v Speaker 1>That sort of thing, right, shiny versus matt.

125
00:06:22.759 --> 00:06:25.439
<v Speaker 2>Exactly and how much light does which is governed by

126
00:06:25.439 --> 00:06:28.839
<v Speaker 2>the material's properties, is it metal or non metal and

127
00:06:28.879 --> 00:06:30.959
<v Speaker 2>its microfacets.

128
00:06:30.079 --> 00:06:32.680
<v Speaker 1>Microfacets tiny details on the surface.

129
00:06:32.720 --> 00:06:36.240
<v Speaker 2>Precisely, these are tiny, often microscopic bumps and grooves on

130
00:06:36.279 --> 00:06:39.319
<v Speaker 2>the surface. They dictate how light scatters at a very

131
00:06:39.360 --> 00:06:42.040
<v Speaker 2>fine level, giving materials their unique look, whether it's a

132
00:06:42.040 --> 00:06:44.959
<v Speaker 2>blurry reflection or a sharp one. We can even simulate

133
00:06:45.079 --> 00:06:49.480
<v Speaker 2>really nuanced effects like anisotropic reflection. Yeah, like on brushed

134
00:06:49.519 --> 00:06:52.920
<v Speaker 2>metal or velvet, where the reflection stretches or changes depending

135
00:06:52.920 --> 00:06:55.639
<v Speaker 2>on the viewing angle and the orientation of the surface details.

136
00:06:55.959 --> 00:06:57.360
<v Speaker 2>PBR can moodel that too.

137
00:06:57.759 --> 00:07:00.439
<v Speaker 1>Wow. Okay, that's a lot of physics detail. For a

138
00:07:00.480 --> 00:07:02.800
<v Speaker 1>developer actually working with this, does it mean they need

139
00:07:02.839 --> 00:07:05.839
<v Speaker 1>a PhD in optics or is there a more practical

140
00:07:05.879 --> 00:07:06.680
<v Speaker 1>way to handle it? Uh?

141
00:07:06.800 --> 00:07:12.079
<v Speaker 2>Huh No PhD required. Thankfully, standardization is absolutely key here.

142
00:07:12.240 --> 00:07:16.240
<v Speaker 2>The glTF PBR specification is a great example. It approaches

143
00:07:16.319 --> 00:07:20.399
<v Speaker 2>material definition focusing on realism, yes, but also efficiency and

144
00:07:20.439 --> 00:07:23.040
<v Speaker 2>consistency across different renderers.

145
00:07:22.519 --> 00:07:26.160
<v Speaker 1>So it gives artists and developers standard knobs to turn exactly.

146
00:07:26.639 --> 00:07:30.040
<v Speaker 2>While the physics underneath is complex. The spec provides standardized

147
00:07:30.079 --> 00:07:34.720
<v Speaker 2>parameters like base color, roughness, metallic value, specular value, things

148
00:07:34.839 --> 00:07:37.360
<v Speaker 2>artists can understand and control and to make all those

149
00:07:37.360 --> 00:07:40.519
<v Speaker 2>complex calculations actually run in real time, like sixty times

150
00:07:40.560 --> 00:07:40.959
<v Speaker 2>a second.

151
00:07:41.120 --> 00:07:42.199
<v Speaker 1>Yeah, how do they do that?

152
00:07:42.279 --> 00:07:45.279
<v Speaker 2>They use clever tricks like pre computing things. A big

153
00:07:45.319 --> 00:07:47.839
<v Speaker 2>one is using BRDF lookup tables.

154
00:07:47.519 --> 00:07:49.839
<v Speaker 1>Or LUT lookup tables like a cheat sheet.

155
00:07:50.000 --> 00:07:53.519
<v Speaker 2>Sort of. Think of it as a precalculated table stored

156
00:07:53.560 --> 00:07:56.759
<v Speaker 2>in a two D texture using some advanced math, often

157
00:07:56.800 --> 00:08:00.680
<v Speaker 2>involving things like Monte Carlo estimation, run on a compute shader. Beforehand,

158
00:08:01.439 --> 00:08:04.639
<v Speaker 2>they basically bake the results of the complex physics equations

159
00:08:04.639 --> 00:08:08.240
<v Speaker 2>into this simple texture. Then in the game, the shader

160
00:08:08.319 --> 00:08:10.160
<v Speaker 2>just needs to do a quick lookup in the texture

161
00:08:10.319 --> 00:08:13.279
<v Speaker 2>based on things like surface roughness and viewing angle to

162
00:08:13.360 --> 00:08:15.439
<v Speaker 2>get the physically correct lighting results.

163
00:08:15.519 --> 00:08:18.720
<v Speaker 1>Ah clever. So you do the heavy math once offline,

164
00:08:19.000 --> 00:08:20.600
<v Speaker 1>then use a fast lookup at runtime.

165
00:08:20.680 --> 00:08:23.959
<v Speaker 2>Precisely, it makes complex physics feasible in real time. The

166
00:08:24.000 --> 00:08:26.839
<v Speaker 2>book even points to resources like Brian Carris's work on

167
00:08:27.000 --> 00:08:29.680
<v Speaker 2>Unreal Engine four shading for a deeper dive into the

168
00:08:29.680 --> 00:08:30.360
<v Speaker 2>math behind it.

169
00:08:30.399 --> 00:08:34.519
<v Speaker 1>That's really interesting. So this standardized PBR approach like glTF,

170
00:08:35.039 --> 00:08:37.360
<v Speaker 1>can it be extended for even more specific effects?

171
00:08:37.399 --> 00:08:40.440
<v Speaker 2>Oh? Absolutely, It's designed to be extensible. For instance, the

172
00:08:40.440 --> 00:08:43.840
<v Speaker 2>book mentions extensions like KHR materials clearcoat, clear coat like

173
00:08:43.879 --> 00:08:46.799
<v Speaker 2>on a car exactly. It adds a thin reflective layer

174
00:08:46.879 --> 00:08:50.480
<v Speaker 2>on top of the base material, perfect for simulating car paint,

175
00:08:50.559 --> 00:08:52.559
<v Speaker 2>lacquered wood, polished shoes, that kind of thing.

176
00:08:52.639 --> 00:08:52.879
<v Speaker 1>Cool.

177
00:08:52.960 --> 00:08:57.039
<v Speaker 2>Any other examples, Yeah, there's KHR material sheen. This one

178
00:08:57.080 --> 00:09:00.360
<v Speaker 2>simulates how light interacts with tiny fibers on a surface,

179
00:09:00.399 --> 00:09:02.840
<v Speaker 2>giving that soft, fuzzy look you see on velvet or

180
00:09:02.840 --> 00:09:03.720
<v Speaker 2>certain fabrics.

181
00:09:03.799 --> 00:09:04.120
<v Speaker 1>Wow.

182
00:09:04.279 --> 00:09:07.200
<v Speaker 2>So these extensions show how you can layer effects onto

183
00:09:07.200 --> 00:09:11.639
<v Speaker 2>the base PBR model to get incredibly nuanced and realistic materials.

184
00:09:11.960 --> 00:09:14.080
<v Speaker 2>It allows artists huge flexibility.

185
00:09:14.159 --> 00:09:17.840
<v Speaker 1>Okay, so realistic materials are sorted, but modern game scenes,

186
00:09:18.080 --> 00:09:22.679
<v Speaker 1>architectural visualizations, they can be absolutely massive, thousands, maybe millions

187
00:09:22.720 --> 00:09:27.080
<v Speaker 1>of objects. How do engineers manage all that complexity? How

188
00:09:27.080 --> 00:09:30.279
<v Speaker 1>do they structure the scene data and still keep performance high?

189
00:09:30.480 --> 00:09:32.080
<v Speaker 1>Are their common mistakes people make?

190
00:09:32.240 --> 00:09:34.840
<v Speaker 2>That's a huge challenge, and scene management is critical. The

191
00:09:34.840 --> 00:09:37.080
<v Speaker 2>book specifically calls out how not to do it?

192
00:09:37.200 --> 00:09:38.679
<v Speaker 1>Oh, what's the big don't.

193
00:09:38.519 --> 00:09:43.120
<v Speaker 2>The naive traditional object oriented approach class based scene graphs

194
00:09:43.240 --> 00:09:45.720
<v Speaker 2>where each know they might have a virtual render method

195
00:09:45.799 --> 00:09:47.240
<v Speaker 2>and you traverse it recursively.

196
00:09:47.360 --> 00:09:49.279
<v Speaker 1>That sounds intuitive. Maybe why is it bad?

197
00:09:49.480 --> 00:09:52.639
<v Speaker 2>It sounds intuitive, but it quickly becomes a performance nightmare.

198
00:09:52.919 --> 00:09:56.240
<v Speaker 2>Lots of virtual function calls cash misses because related data

199
00:09:56.320 --> 00:10:00.159
<v Speaker 2>isn't stored together in memory. Plus it makes managing things.

200
00:10:00.000 --> 00:10:04.279
<v Speaker 2>It's like rendering order for transparency really complicated and prone

201
00:10:04.320 --> 00:10:06.360
<v Speaker 2>to errors. It's a classic trap.

202
00:10:06.559 --> 00:10:10.720
<v Speaker 1>Okay, so recursive rendering is out. What's the recommended more

203
00:10:10.720 --> 00:10:11.480
<v Speaker 1>efficient way?

204
00:10:11.519 --> 00:10:15.600
<v Speaker 2>Then it's all about moving towards a data oriented design.

205
00:10:15.759 --> 00:10:17.519
<v Speaker 1>Data oriented meaning.

206
00:10:17.600 --> 00:10:21.080
<v Speaker 2>Instead of objects owning other objects and calling methods everywhere,

207
00:10:21.159 --> 00:10:24.679
<v Speaker 2>you focus on the data itself. You store similar data together,

208
00:10:24.720 --> 00:10:28.200
<v Speaker 2>typically in contiguous arrays, so all the positions might be

209
00:10:28.240 --> 00:10:30.720
<v Speaker 2>in one array, all their rotations in another, all the

210
00:10:30.799 --> 00:10:32.000
<v Speaker 2>mesh references in another.

211
00:10:32.240 --> 00:10:33.080
<v Speaker 1>Right. How does that help?

212
00:10:33.240 --> 00:10:37.279
<v Speaker 2>It drastically improves CPU cash efficiency. The processor loves working

213
00:10:37.279 --> 00:10:40.039
<v Speaker 2>on data that's packed together tightly in memory. It spends

214
00:10:40.159 --> 00:10:43.279
<v Speaker 2>less time waiting for data to be fetched, and operations

215
00:10:43.320 --> 00:10:46.200
<v Speaker 2>like updating transformation trees become much faster.

216
00:10:46.440 --> 00:10:49.320
<v Speaker 1>Transformation trees that's figuring out where everything is in the

217
00:10:49.320 --> 00:10:51.159
<v Speaker 1>world exactly.

218
00:10:50.840 --> 00:10:54.879
<v Speaker 2>Right, calculating each object's final position, rotation, and scale in

219
00:10:54.919 --> 00:10:58.679
<v Speaker 2>the world based on its local transformation and its parents transformation.

220
00:10:59.200 --> 00:11:02.120
<v Speaker 2>Doing this across us thousands of objects is much faster

221
00:11:02.200 --> 00:11:03.879
<v Speaker 2>when the data is laid out linearly.

222
00:11:04.240 --> 00:11:06.320
<v Speaker 1>Makes sense. Better data layout equals.

223
00:11:06.000 --> 00:11:10.279
<v Speaker 2>Better performance fundamentally yes. But even with efficient data layout,

224
00:11:10.399 --> 00:11:13.720
<v Speaker 2>there's another bottleneck. Just telling the GPU draw this mash,

225
00:11:13.759 --> 00:11:16.399
<v Speaker 2>now draw this mash, now draw this one. Tens of

226
00:11:16.440 --> 00:11:17.960
<v Speaker 2>thousands of times per frame.

227
00:11:18.120 --> 00:11:20.279
<v Speaker 1>That's a lot of chatter between the CPU and GPU

228
00:11:20.399 --> 00:11:21.440
<v Speaker 1>the draw call overhead.

229
00:11:21.480 --> 00:11:24.120
<v Speaker 2>Precisely, the CPU gets bogged down just issuing all those

230
00:11:24.120 --> 00:11:25.320
<v Speaker 2>individual draw commands.

231
00:11:25.360 --> 00:11:27.879
<v Speaker 1>And I'm guessing this is where a technique like indirect

232
00:11:27.879 --> 00:11:31.080
<v Speaker 1>rendering comes in, Yeah, to cut down on that chatter exactly.

233
00:11:31.399 --> 00:11:34.639
<v Speaker 2>Indirect rendering is a massive game changer for handling scenes

234
00:11:34.639 --> 00:11:38.679
<v Speaker 2>with huge object counts. Instead of the CPU micromanaging every

235
00:11:38.720 --> 00:11:41.720
<v Speaker 2>single draw call, you know, you basically prepare a list

236
00:11:41.759 --> 00:11:44.320
<v Speaker 2>of draw commands on the GPU itself in a buffer.

237
00:11:44.759 --> 00:11:48.440
<v Speaker 2>This list says draw mesh A ten instances starting at

238
00:11:48.480 --> 00:11:52.120
<v Speaker 2>index X, draw MESHB five instances starting at index Y,

239
00:11:52.200 --> 00:11:55.399
<v Speaker 2>and so on. Then the CPU issues just one command

240
00:11:55.440 --> 00:11:59.360
<v Speaker 2>to the GPU like vkcmd draw indirect just one command yep,

241
00:11:59.360 --> 00:12:01.320
<v Speaker 2>and that one come out and tells the GPU, go

242
00:12:01.480 --> 00:12:04.399
<v Speaker 2>execute all the draw instructions you find in that buffer.

243
00:12:04.559 --> 00:12:07.519
<v Speaker 1>Wow, So the GPU pulls the work itself exactly.

244
00:12:07.759 --> 00:12:10.360
<v Speaker 2>It pulls the draw commands and their parameters directly from

245
00:12:10.360 --> 00:12:14.840
<v Speaker 2>GPU memory. This dramatically cuts down the CPU overhead. It

246
00:12:14.960 --> 00:12:17.919
<v Speaker 2>enables rendering scenes with like the book shows, thirty two

247
00:12:18.080 --> 00:12:22.480
<v Speaker 2>thousand individual meshes or even more, especially when combined with instancing.

248
00:12:22.840 --> 00:12:24.919
<v Speaker 2>It's key for massive scale rendering.

249
00:12:25.039 --> 00:12:27.399
<v Speaker 1>That's a huge performance win. But even if you can

250
00:12:27.480 --> 00:12:29.639
<v Speaker 1>draw thirty two thousand things, most of them aren't actually

251
00:12:29.720 --> 00:12:31.879
<v Speaker 1>visible to the camera at any given moment, right they're

252
00:12:31.960 --> 00:12:34.159
<v Speaker 1>off screen or behind other objects.

253
00:12:33.879 --> 00:12:36.919
<v Speaker 2>Absolutely, and drawing things you can't see is just wasted work,

254
00:12:37.200 --> 00:12:41.399
<v Speaker 2>which leads to the next crucial optimization frustum culling.

255
00:12:41.159 --> 00:12:45.080
<v Speaker 1>Right culling only drawing what's inside the camera's view exactly.

256
00:12:45.320 --> 00:12:48.320
<v Speaker 2>The view frustum is essentially the pyramid shape representing what

257
00:12:48.360 --> 00:12:51.360
<v Speaker 2>the camera can see. Before drawing, you check if an

258
00:12:51.360 --> 00:12:55.240
<v Speaker 2>object's bounding box or bounding sphere intersects with this frustum.

259
00:12:55.679 --> 00:12:59.799
<v Speaker 2>If it's completely outside, you simply skip drawing it, don't

260
00:12:59.799 --> 00:13:01.559
<v Speaker 2>even send it to the GPU.

261
00:13:01.360 --> 00:13:05.639
<v Speaker 1>Saving potentially millions of triangles from being processed unnecessarily.

262
00:13:05.000 --> 00:13:08.919
<v Speaker 2>Potentially, Yes, it's a fundamental optimization. This check can be

263
00:13:08.960 --> 00:13:13.279
<v Speaker 2>done efficiently on the CPU, or for truly massive scenes

264
00:13:13.480 --> 00:13:14.879
<v Speaker 2>with maybe hundreds of.

265
00:13:14.840 --> 00:13:16.679
<v Speaker 1>Thousands of objects, you can do it on the GPU.

266
00:13:16.919 --> 00:13:19.600
<v Speaker 2>You can offload the culoring logic itself to the GPU

267
00:13:19.799 --> 00:13:23.399
<v Speaker 2>using compute shaders. The CPU sends rough scene data, the

268
00:13:23.480 --> 00:13:26.480
<v Speaker 2>GPU compute shader figures out what's visible, and then it

269
00:13:26.559 --> 00:13:29.720
<v Speaker 2>generates that indirect draw buffal we just talked about, containing

270
00:13:29.759 --> 00:13:30.799
<v Speaker 2>only the visible.

271
00:13:30.519 --> 00:13:33.519
<v Speaker 1>Objects, chaining the techniques together exactly.

272
00:13:33.720 --> 00:13:37.320
<v Speaker 2>The book shows these cool visualizations. The frustum in yellow

273
00:13:37.399 --> 00:13:40.559
<v Speaker 2>visible meshes green called meshes red really makes it clear

274
00:13:40.600 --> 00:13:41.440
<v Speaker 2>how effective it is.

275
00:13:41.720 --> 00:13:47.799
<v Speaker 1>Okay, so building these complex pipelines optimizing them it sounds

276
00:13:47.919 --> 00:13:51.799
<v Speaker 1>incredibly involved. Debugging must be a nightmare sometimes. How do

277
00:13:51.919 --> 00:13:55.600
<v Speaker 1>graphics developers actually figure out what's going wrong or why

278
00:13:55.679 --> 00:13:58.320
<v Speaker 1>performance suddenly drop? What tools do they rely on?

279
00:13:58.679 --> 00:14:02.240
<v Speaker 2>Good question? Essential activity tools are absolutely key. You can't

280
00:14:02.240 --> 00:14:05.639
<v Speaker 2>develop this stuff effectively without them. INGUI is a fantastic

281
00:14:05.679 --> 00:14:10.759
<v Speaker 2>example mention. It stands for Immediate Mode Graphical User Interface.

282
00:14:10.879 --> 00:14:14.679
<v Speaker 2>It's a bloat free, very easy to use C plus

283
00:14:14.679 --> 00:14:18.519
<v Speaker 2>plus library for creating debuguiys inside your application.

284
00:14:18.720 --> 00:14:20.639
<v Speaker 1>Inside the app, not a separate tool.

285
00:14:20.720 --> 00:14:24.039
<v Speaker 2>Right, you can add sliders, buttons, checkboxes, data plocks directly

286
00:14:24.080 --> 00:14:26.360
<v Speaker 2>onto your rendering window on the fly. Want to tweak

287
00:14:26.360 --> 00:14:28.519
<v Speaker 2>a PBR parameter, Add a slider, want to select an

288
00:14:28.559 --> 00:14:29.960
<v Speaker 2>object in the scene, add.

289
00:14:29.840 --> 00:14:32.000
<v Speaker 1>A drop down without recompiling exactly.

290
00:14:32.240 --> 00:14:35.840
<v Speaker 2>It's invaluable for interactive debugging and tweaking, a real life saver.

291
00:14:36.039 --> 00:14:39.279
<v Speaker 1>Okay, that's for tweaking values. What about when performance tanks?

292
00:14:39.600 --> 00:14:40.960
<v Speaker 1>How do you find the bottleneck?

293
00:14:41.240 --> 00:14:44.639
<v Speaker 2>That's where a profiler like Tracy comes in. Tracy is

294
00:14:44.679 --> 00:14:47.559
<v Speaker 2>mentioned as being used in the book's codebase Lightweight VK.

295
00:14:48.240 --> 00:14:52.600
<v Speaker 2>It's a powerful frame profiler that integrates directly into your

296
00:14:52.679 --> 00:14:55.960
<v Speaker 2>C plus plus code. You add simple macros to mark

297
00:14:56.000 --> 00:14:59.519
<v Speaker 2>sections of your code. Start physics, end physics, start rendering,

298
00:14:59.679 --> 00:15:04.120
<v Speaker 2>and and then Tracy visualizes exactly how much time is

299
00:15:04.159 --> 00:15:07.440
<v Speaker 2>spent in each section, both on the CPU and importantly

300
00:15:07.480 --> 00:15:10.120
<v Speaker 2>on the GPU timeline. You can see which functions are

301
00:15:10.159 --> 00:15:12.840
<v Speaker 2>taking too long, where the bubbles are in your pipeline.

302
00:15:12.919 --> 00:15:15.799
<v Speaker 2>You can pinpoint the exact slow spots precisely. It makes

303
00:15:15.879 --> 00:15:19.320
<v Speaker 2>identifying and optimizing performance bottlenecks much much easier. You're not

304
00:15:19.320 --> 00:15:22.840
<v Speaker 2>guessing anymore, and beyond UI and profiling, just seeing things

305
00:15:22.879 --> 00:15:26.000
<v Speaker 2>as crucial. The book also talks about implementing an immediate

306
00:15:26.000 --> 00:15:28.600
<v Speaker 2>mode three D drawing canvas.

307
00:15:27.919 --> 00:15:30.000
<v Speaker 1>Like drawing dbug lines and shape yah.

308
00:15:29.919 --> 00:15:33.000
<v Speaker 2>For rendering auxiliary info directly into the three D scene,

309
00:15:33.120 --> 00:15:36.879
<v Speaker 2>things like object bounding boxes, collision shapes, light positions, maybe

310
00:15:36.919 --> 00:15:40.559
<v Speaker 2>the camera frustum itself for debugging culling. It helps visualize

311
00:15:40.600 --> 00:15:43.080
<v Speaker 2>the invisible structure of the scene. Right makes sense, And

312
00:15:43.159 --> 00:15:46.639
<v Speaker 2>of course you need good camera controls. A solid first

313
00:15:46.679 --> 00:15:50.360
<v Speaker 2>person camera implementation, often wrapped in a helper class is

314
00:15:50.399 --> 00:15:53.399
<v Speaker 2>just fundamental for navigating and inspecting these complex three D

315
00:15:53.559 --> 00:15:54.840
<v Speaker 2>environments during development.

316
00:15:54.960 --> 00:15:57.440
<v Speaker 1>Okay, let's pull this all together. We've built the scene,

317
00:15:57.559 --> 00:16:01.600
<v Speaker 1>optimized it, debugged it. What's that final layer of visual magic,

318
00:16:02.039 --> 00:16:04.799
<v Speaker 1>the polish that really sells the image on screen and

319
00:16:04.840 --> 00:16:05.879
<v Speaker 1>makes it look immersive.

320
00:16:06.360 --> 00:16:08.960
<v Speaker 2>That would be a suite of image based techniques often

321
00:16:09.000 --> 00:16:12.480
<v Speaker 2>called post processing effects, applied after the main scene is rendered.

322
00:16:13.120 --> 00:16:17.039
<v Speaker 2>High dynamic range or HDR rendering is absolutely essential here.

323
00:16:17.240 --> 00:16:19.879
<v Speaker 1>HDR my TV talks about that. How does it apply here?

324
00:16:19.960 --> 00:16:23.120
<v Speaker 2>Well? Traditional rendering clamps colors between zero point zero black

325
00:16:23.159 --> 00:16:25.519
<v Speaker 2>and one point zero white but the real world has

326
00:16:25.519 --> 00:16:28.279
<v Speaker 2>a much wider range of brightness, think the sun versus

327
00:16:28.279 --> 00:16:31.720
<v Speaker 2>a dimly lit room. HDR rendering uses floating point numbers

328
00:16:31.720 --> 00:16:35.120
<v Speaker 2>for colors, preserving that huge range of brightness. It captures

329
00:16:35.159 --> 00:16:39.039
<v Speaker 2>details and super bright highlights and deep shadows simultaneously, just

330
00:16:39.080 --> 00:16:41.159
<v Speaker 2>like a real camera or your eye would perceive.

331
00:16:41.360 --> 00:16:45.120
<v Speaker 1>So you get brighter brights and darker darks, more detail exactly.

332
00:16:45.159 --> 00:16:47.919
<v Speaker 2>It adds incredible depth and realism. But then you have

333
00:16:47.960 --> 00:16:51.639
<v Speaker 2>a problem. Your monitor can't display that full HDR range.

334
00:16:51.480 --> 00:16:53.480
<v Speaker 1>Right, So how do you get the HDR image onto

335
00:16:53.519 --> 00:16:54.320
<v Speaker 1>a standard screen.

336
00:16:54.519 --> 00:16:57.399
<v Speaker 2>That's where tone mapping comes in. It's a process an

337
00:16:57.480 --> 00:17:02.080
<v Speaker 2>algorithm that intelligently compresses or maps those HDR values back

338
00:17:02.159 --> 00:17:04.640
<v Speaker 2>down to the limited range your display can actually show.

339
00:17:05.200 --> 00:17:08.519
<v Speaker 2>There are different tone mapping operators rein hard Uchimura. The

340
00:17:08.519 --> 00:17:12.160
<v Speaker 2>book mentions chronos PBR neutral, each giving a slightly different look,

341
00:17:12.200 --> 00:17:14.319
<v Speaker 2>But the goal is to preserve the intent of the

342
00:17:14.440 --> 00:17:18.160
<v Speaker 2>HDR image as best as possible. Like compressing audio carefully

343
00:17:18.240 --> 00:17:21.079
<v Speaker 2>good analogy, you want to reduce the range without crushing

344
00:17:21.119 --> 00:17:24.240
<v Speaker 2>the details or losing the overall feel. And one more

345
00:17:24.279 --> 00:17:27.319
<v Speaker 2>related effect is light adaptation or eye adaptation.

346
00:17:27.680 --> 00:17:29.279
<v Speaker 1>Simulating how our eyes adjust.

347
00:17:29.400 --> 00:17:31.960
<v Speaker 2>Precisely when you move from a bright area to a

348
00:17:32.039 --> 00:17:35.079
<v Speaker 2>dark one, or vice versa, your eyes take time to adjust.

349
00:17:35.480 --> 00:17:39.200
<v Speaker 2>This effect simulates that, gradually changing the overall exposure of

350
00:17:39.200 --> 00:17:42.880
<v Speaker 2>the scene based on its average brightness. It really enhances immersion,

351
00:17:43.200 --> 00:17:45.799
<v Speaker 2>making the virtual world feel more reactive and alive.

352
00:17:46.119 --> 00:17:49.559
<v Speaker 1>Wow, what an incredible deep dive that was. We've really

353
00:17:49.599 --> 00:17:51.440
<v Speaker 1>gone from the nuts and bolts of setting up a

354
00:17:51.519 --> 00:17:55.480
<v Speaker 1>Vulcan environment all the way to these sophisticated algorithms creating

355
00:17:55.559 --> 00:17:59.279
<v Speaker 1>hyperrealistic visuals. You should now have a really solid grasp

356
00:17:59.359 --> 00:18:02.160
<v Speaker 1>on how modern engines bring these worlds to life with PBR,

357
00:18:02.680 --> 00:18:06.200
<v Speaker 1>how they manage immense complexity using things like data oriented

358
00:18:06.200 --> 00:18:09.200
<v Speaker 1>design and indirect rendering, and keep it all running smoothly

359
00:18:09.240 --> 00:18:13.160
<v Speaker 1>with culling. Plus the tools developers use, and those final

360
00:18:13.200 --> 00:18:15.960
<v Speaker 1>touches like HDR and tone mapping that add that layer

361
00:18:16.000 --> 00:18:18.680
<v Speaker 1>of polish. You basically just had a shortcut to being

362
00:18:18.759 --> 00:18:21.880
<v Speaker 1>seriously well informed about the amazing engineering behind modern three

363
00:18:21.920 --> 00:18:24.680
<v Speaker 1>D graphics, all thanks to the insights from the Vulcan

364
00:18:24.680 --> 00:18:26.200
<v Speaker 1>three D Graphics Rendering Cookbook.

365
00:18:26.279 --> 00:18:29.640
<v Speaker 2>Absolutely, and thinking about all this it makes you wonder

366
00:18:29.920 --> 00:18:32.480
<v Speaker 2>what's next? What are the big challenges ahead in pushing

367
00:18:32.559 --> 00:18:35.359
<v Speaker 2>real time rendering even further? You know, consider things like

368
00:18:35.400 --> 00:18:38.480
<v Speaker 2>real time retracing becoming more mainstream, or maybe even more

369
00:18:38.559 --> 00:18:41.319
<v Speaker 2>dynamic AI driven ways to generate content on the fly.

370
00:18:41.960 --> 00:18:45.039
<v Speaker 2>How might these incredibly sophisticated techniques evolve in the next

371
00:18:45.079 --> 00:18:48.039
<v Speaker 2>few years. What new problems will developers have to solve?

372
00:18:48.359 --> 00:18:49.240
<v Speaker 2>Thing to think about.