WEBVTT 1 00:00:00.080 --> 00:00:03.799 Okay, let's unpack this. Today we're taking a deep dive 2 00:00:03.839 --> 00:00:07.320 into the fascinating world of game visuals. We're going to 3 00:00:07.400 --> 00:00:10.880 pull back the curtain on how developers craft those stunning, 4 00:00:10.919 --> 00:00:13.679 immersive graphics you see in modern Unity three D games. 5 00:00:13.919 --> 00:00:14.080 Right. 6 00:00:14.480 --> 00:00:16.960 Our mission isn't to bury you in technical jargon, but 7 00:00:17.079 --> 00:00:21.039 to cut through the complexity and extract the most important 8 00:00:21.120 --> 00:00:24.039 nuggets of knowledge and insight. Yeah, make it accessible, and 9 00:00:24.160 --> 00:00:27.920 we're drawing heavily from a truly fantastic resource, the Unity 10 00:00:27.920 --> 00:00:31.519 Shaders and Affects Cookbook by Kenny Lammers. A book that's well, 11 00:00:31.559 --> 00:00:35.039 it's a masterclass in practical recipe based learning, and it's 12 00:00:35.159 --> 00:00:36.920 full of surprising facts. 13 00:00:37.039 --> 00:00:39.920 That's right. This deep dive is your shortcut to being 14 00:00:39.960 --> 00:00:43.280 well informed about the magic behind how games look. Think 15 00:00:43.280 --> 00:00:47.320 of it as unveiling the clever illusions and powerful tools 16 00:00:47.399 --> 00:00:50.240 that turn polygons into vibrant living worlds. 17 00:00:50.600 --> 00:00:50.880 Yeah. 18 00:00:50.920 --> 00:00:54.640 We'll explore everything from the kind of foundational building blocks 19 00:00:54.640 --> 00:00:57.679 of visual effects to advance techniques that make a game 20 00:00:57.719 --> 00:01:01.119 truly shine. Our goal is to help you understand not 21 00:01:01.200 --> 00:01:04.239 just what shaders and effects are, but why they matter 22 00:01:04.640 --> 00:01:07.480 to the final esthetic and performance of a game. And 23 00:01:07.519 --> 00:01:09.680 how they contribute to that wow factor. 24 00:01:09.959 --> 00:01:12.519 So we're talking about making things look good in Unity. 25 00:01:13.000 --> 00:01:16.359 When you're building a game, where do you even begin 26 00:01:16.799 --> 00:01:19.719 to well paint that visual masterpiece? 27 00:01:19.840 --> 00:01:24.079 We begin with shaders. Imagine them as tiny, highly specialized 28 00:01:24.120 --> 00:01:28.760 painters that live inside your graphics card. Well painters, Yeah, exactly. 29 00:01:29.040 --> 00:01:31.799 Every surface in your game, a tree, a wall, a 30 00:01:31.879 --> 00:01:35.280 character skin gets painted by a shader. Historically it was 31 00:01:35.319 --> 00:01:38.359 like using a preset brush, maybe a bit rigid, But today, 32 00:01:38.680 --> 00:01:42.000 with modern rendering languages like Craig and Unity's user friendly 33 00:01:42.040 --> 00:01:44.760 surface shaders, developers have vastly more. 34 00:01:44.599 --> 00:01:46.439 Control, more flexibility, way more. 35 00:01:46.640 --> 00:01:49.439 Unity surface shadors are particularly efficient because they handle a 36 00:01:49.480 --> 00:01:51.920 lot of the heavy lifting for the graphics processing unit, 37 00:01:51.959 --> 00:01:55.519 the GPU, making it much smoother to customize how things look. 38 00:01:55.599 --> 00:01:59.200 That sounds incredibly powerful. So we're building these custom painters, 39 00:01:59.239 --> 00:02:02.480 these shaders, But how do artists who might not write 40 00:02:02.480 --> 00:02:04.719 code actually use them? Is there a simple way to 41 00:02:04.760 --> 00:02:05.319 tweak things? 42 00:02:05.599 --> 00:02:08.280 Absolutely? That's where properties come in. Think of them as 43 00:02:08.280 --> 00:02:11.639 the adjustable knobs and sliders on your shader's control panel 44 00:02:11.719 --> 00:02:12.759 right in the Unity editor. 45 00:02:12.879 --> 00:02:15.280 Ah okay, so the artist sees those directly. 46 00:02:15.400 --> 00:02:18.840 Yep, they let artists or designers fine tune colors, textures, 47 00:02:18.919 --> 00:02:22.479 or how shiny something is directly within Unity's inspector tab. 48 00:02:23.199 --> 00:02:24.919 No coding required for them at that point. 49 00:02:24.960 --> 00:02:28.120 That makes so much sense. So these properties literally let 50 00:02:28.159 --> 00:02:31.039 you declare different kinds of inputs. You could have a 51 00:02:31.039 --> 00:02:32.800 color property for a color picker. 52 00:02:32.560 --> 00:02:35.759 Maybe exactly, or a range for a slider. You can 53 00:02:35.840 --> 00:02:38.080 have a two D property for a texture image, a 54 00:02:38.159 --> 00:02:40.719 cube for something called a cube map. We'll definitely get 55 00:02:40.719 --> 00:02:44.159 to those later, okay. Or simple float values for numbers. 56 00:02:44.879 --> 00:02:49.560 Eat property like a missive color or my slider value 57 00:02:49.919 --> 00:02:52.919 links directly to the shader's inner workings. And the real 58 00:02:52.960 --> 00:02:55.280 beauty here is you can set up a slider in 59 00:02:55.319 --> 00:02:59.680 the Unity editor that, when dragged, might dynamically change how 60 00:02:59.719 --> 00:03:01.840 sack traded a color is in your game, all in 61 00:03:01.879 --> 00:03:02.919 real time. Wow. 62 00:03:03.000 --> 00:03:05.719 Yeah, that must be a huge time saver. Empowers the 63 00:03:05.800 --> 00:03:09.759 artists directly. What's fascinating here is how textures then become 64 00:03:10.000 --> 00:03:12.800 more than just image files you said, They become powerful 65 00:03:12.919 --> 00:03:13.840 data containers. 66 00:03:14.080 --> 00:03:17.719 Indeed, think of a texture not just as a pretty picture, 67 00:03:18.120 --> 00:03:21.000 but as a candice where each pixel can hold different 68 00:03:21.080 --> 00:03:21.879 kinds of information. 69 00:03:22.199 --> 00:03:27.280 It's quite clever like scrolling textures for effects like waterfalls, rivers, 70 00:03:27.479 --> 00:03:28.599 or maybe lava flows. 71 00:03:28.719 --> 00:03:33.080 Exactly, it's an illusion of movement, but incredibly effective. You're 72 00:03:33.120 --> 00:03:37.159 simply shifting the textures, coordinates, the uvs over time in 73 00:03:37.240 --> 00:03:40.800 the shader, often using unities built in time variable. 74 00:03:40.439 --> 00:03:43.120 Just sliding the picture along basically pretty much. 75 00:03:43.159 --> 00:03:47.039 And similarly animating sprite sheets. People often call them sprite atlases. 76 00:03:47.159 --> 00:03:48.840 That's like creating a digital flip book. 77 00:03:48.960 --> 00:03:49.599 Ah. 78 00:03:49.639 --> 00:03:52.680 You're taking a large texture with many smaller images frames 79 00:03:52.680 --> 00:03:55.719 of an animation, and the shader cleverly cycles through them, 80 00:03:55.800 --> 00:04:00.000 using precise mathematical calculations like wad and seal to create 81 00:04:00.080 --> 00:04:01.439 that smooth illusion to movement. 82 00:04:01.759 --> 00:04:04.719 And here's an AHA moment, I think, especially for performance 83 00:04:05.240 --> 00:04:09.120 packing textures. You mentioned storing multiple grayscale images inside a 84 00:04:09.159 --> 00:04:09.960 single texture. 85 00:04:10.240 --> 00:04:13.599 Yes, like a secret compartment. You use the red, green, blue, 86 00:04:13.639 --> 00:04:17.040 and alpha channels, the RGBA channels to store four different 87 00:04:17.040 --> 00:04:17.879 grayscale maps. 88 00:04:17.920 --> 00:04:18.959 Why is that so important? 89 00:04:19.120 --> 00:04:22.959 Memory textures eat up memory, especially on mobile. Packing them 90 00:04:23.000 --> 00:04:27.079 like this drastically shrinks your app size. It's a huge optimization. 91 00:04:27.360 --> 00:04:30.839 Okay, so you pack them save memory, then. 92 00:04:30.759 --> 00:04:34.439 What then the shader can intelligently blend these hidden images 93 00:04:34.439 --> 00:04:37.959 together on a surface. You use the LURP function linear 94 00:04:38.040 --> 00:04:44.000 interpolation to smoothly transition between say, grass, dirt, and rock 95 00:04:44.399 --> 00:04:46.839 on a terrain model, all from one tiny file. 96 00:04:46.959 --> 00:04:49.879 That sounds incredibly useful for detailed environments it is. 97 00:04:49.959 --> 00:04:52.839 And then there's normal mapping. This was well a truly 98 00:04:52.920 --> 00:04:57.600 genius technique that let games leak forward visually without tanking performance. 99 00:04:57.240 --> 00:05:00.720 Right, making things look bumpy without adding actual polygons. 100 00:05:00.680 --> 00:05:04.040 Instead of requiring complex high polling models. A normal map 101 00:05:04.120 --> 00:05:07.720 uses a special texture where pixel colors represent surface direction. 102 00:05:08.319 --> 00:05:10.879 It tells the light how to bounce off, faking intricate 103 00:05:10.920 --> 00:05:11.600 detail on a. 104 00:05:11.519 --> 00:05:14.920 Low poly mesh like optical illusion geometry kind of. 105 00:05:15.160 --> 00:05:18.399 Unity even has helpers like unpack normal to make it easier, 106 00:05:19.120 --> 00:05:21.800 and you can control the intensity with a shader property 107 00:05:22.199 --> 00:05:24.079 like a normal map intensity slider. 108 00:05:24.199 --> 00:05:27.319 It doesn't stop there, though. What if you need patterns 109 00:05:27.319 --> 00:05:29.879 that aren't in a file, or need to adjust textures 110 00:05:29.920 --> 00:05:30.360 on the fly. 111 00:05:30.920 --> 00:05:34.639 Well, you can create procedural textures dynamically within the Unity 112 00:05:34.759 --> 00:05:36.439 editor using c sharp. 113 00:05:36.199 --> 00:05:37.879 Scripts, generating them with code. 114 00:05:38.000 --> 00:05:41.920 Yeah, you can generate patterns, shapes, maybe gradulate distances to 115 00:05:41.959 --> 00:05:45.480 create rings or gradients. You can even replicate Photoshop levels 116 00:05:45.480 --> 00:05:46.879 effects directly in your. 117 00:05:46.759 --> 00:05:49.959 Shader, like adjusting brightness and contrast in real. 118 00:05:49.759 --> 00:05:55.560 Time exactly adjust brightness contrast gamma using functions like max 119 00:05:55.680 --> 00:06:00.680 to clamp values. Precise artistic control, but generated dynamically. 120 00:06:00.800 --> 00:06:03.959 Okay, so we've painted surfaces use textures as smart data. 121 00:06:04.160 --> 00:06:07.079 But what about making things really shine and reflect the 122 00:06:07.079 --> 00:06:10.360 world around them that metallic glint or waterychine. 123 00:06:10.439 --> 00:06:13.279 Right, That's where specularity comes in. It describes how shiny 124 00:06:13.319 --> 00:06:16.879 an object is, and crucially, it's a view dependent. 125 00:06:16.439 --> 00:06:19.000 Defect, meaning it changes based on where I'm standing. 126 00:06:19.240 --> 00:06:22.920 Precisely the highlight moves as you move around the object. 127 00:06:23.720 --> 00:06:26.480 A core concept here is the half vector, which is 128 00:06:26.639 --> 00:06:29.040 sort of an efficient way to calculate where that highlight 129 00:06:29.040 --> 00:06:32.759 should be between the light source and your viewpoint. Unity 130 00:06:32.800 --> 00:06:36.000 provides a built in blind fong lighting model that's very 131 00:06:36.000 --> 00:06:37.399 common and pretty efficient for this. 132 00:06:37.759 --> 00:06:40.480 But you're not limited to just the built in options, right? 133 00:06:40.519 --> 00:06:42.759 Can artists get more granular control? 134 00:06:43.040 --> 00:06:45.319 Oh? Absolutely not limited. You can write your own custom 135 00:06:45.360 --> 00:06:49.879 shine models and masking specula with textures gives artists incredible 136 00:06:49.879 --> 00:06:50.879 pixel level control. 137 00:06:51.040 --> 00:06:54.600 So using a texture as a stencil for shininess. 138 00:06:54.160 --> 00:06:57.439 Exactly a grayscale texture, where black means matt and white 139 00:06:57.480 --> 00:07:01.120 means full shine. This leads to tech niques for simulating 140 00:07:01.160 --> 00:07:05.560 different material properties, think metallic versus soft speculat. 141 00:07:05.319 --> 00:07:07.720 Like brushed metal versus say, plastic. 142 00:07:07.839 --> 00:07:11.279 Precisely, you can mimic different roughness levels or even at 143 00:07:11.279 --> 00:07:13.920 a fresnel term. That's the effect where reflections get stronger 144 00:07:13.920 --> 00:07:16.839 at glancing angles, like on water or car paint. And 145 00:07:16.879 --> 00:07:19.879 for really specialized surfaces like brush metal or even hair, 146 00:07:20.519 --> 00:07:24.759 there's anisotropic speculator that uses a normal map not just 147 00:07:24.759 --> 00:07:27.639 for bumps, but to define the direction of the highlight, 148 00:07:27.920 --> 00:07:31.120 making it stretch along the grain usually needs a slightly 149 00:07:31.160 --> 00:07:33.160 more powerful shader model like three. 150 00:07:33.079 --> 00:07:37.000 Point zero reflections. Then, equally important for realism, how do 151 00:07:37.040 --> 00:07:40.160 we get objects to actually mirror their surroundings. 152 00:07:40.240 --> 00:07:43.000 The key there is cube maps. Remember the cube property type. 153 00:07:43.079 --> 00:07:45.160 Yeah, you mentioned we'd get back to those right. 154 00:07:45.519 --> 00:07:49.199 So imagine taking six photos up, down, left, right, forward, backward, 155 00:07:49.279 --> 00:07:52.319 all from one point, stitch them together into a cube. 156 00:07:52.639 --> 00:07:56.319 That's your cube map. It captures the entire environment around an. 157 00:07:56.199 --> 00:07:59.000 Object, like wrapping the object in a photo box. 158 00:07:59.160 --> 00:08:02.519 Pretty much, you can create cube maps directly in Unity, 159 00:08:02.959 --> 00:08:05.399 using a function called rendered a cube map, often with 160 00:08:05.439 --> 00:08:08.519 a little menator helper tool for static scenes, or use 161 00:08:08.560 --> 00:08:11.800 external tools like Ati cube map gen for more control. 162 00:08:11.920 --> 00:08:14.439 Okay, so you've got your environment, box, your cube map. 163 00:08:14.480 --> 00:08:15.720 How does the shader use it? 164 00:08:15.920 --> 00:08:20.319 Unity makes simple cube map reflection surprisingly easy. The shader's 165 00:08:20.360 --> 00:08:23.639 input data usually have a built in vector, often called 166 00:08:23.720 --> 00:08:28.240 world refle that automatically calculates the correct reflection direction based 167 00:08:28.279 --> 00:08:30.240 on the surface normal and view angle. 168 00:08:30.040 --> 00:08:32.600 So it knows where to look into the cube exactly. 169 00:08:32.919 --> 00:08:35.279 Then you just use the text key function to sample 170 00:08:35.279 --> 00:08:37.759 that cube map at that direction and boom you get 171 00:08:37.759 --> 00:08:38.559 the reflection color. 172 00:08:38.679 --> 00:08:41.120 And just like with speculator, I assume you can control 173 00:08:41.159 --> 00:08:42.039 where it reflects. 174 00:08:42.120 --> 00:08:45.879 Yep, you can mask reflections using another grayscale texture black 175 00:08:46.000 --> 00:08:49.879 for no reflection, white for full reflection, same principle. 176 00:08:49.519 --> 00:08:54.440 And combining normal maps with reflections for bumpy reflective surfaces. 177 00:08:54.480 --> 00:08:57.399 Absolutely, That's where it gets really convincing. You need to 178 00:08:57.440 --> 00:09:00.399 access the surface normal after it's been modified by the 179 00:09:00.399 --> 00:09:04.000 normal map. Unity provides ways to do this, often using 180 00:09:04.000 --> 00:09:07.279 something called internal data. Then you use a function like 181 00:09:07.320 --> 00:09:10.840 world reflection vector to calculate the reflection direction based on 182 00:09:10.879 --> 00:09:14.679 that bumpy normal the reflection gets realistically perturbed. 183 00:09:14.879 --> 00:09:18.320 Makes sense, So the bumps distort the reflection, right, And. 184 00:09:18.320 --> 00:09:21.799 You mentioned fresnel reflections earlier with specularity, same applies here, 185 00:09:22.159 --> 00:09:25.360 very common for making reflections pomp at glancing angles looks 186 00:09:25.399 --> 00:09:27.720 great on water glass car paint. 187 00:09:27.919 --> 00:09:31.440 And can these reflections be dynamic update in real time? 188 00:09:31.679 --> 00:09:34.799 They can, but it's computationally expensive. You can build dynamic 189 00:09:34.840 --> 00:09:38.399 cube map systems that maybe swap between precaptured cube maps 190 00:09:38.440 --> 00:09:41.159 based on where the object is, or even re render 191 00:09:41.200 --> 00:09:43.000 the cube map periodically in real time. 192 00:09:43.080 --> 00:09:46.440 So needs careful scripting. Maybe checking distances. 193 00:09:46.080 --> 00:09:49.519 Exactly use c sharp scripts, maybe with execute an edit 194 00:09:49.559 --> 00:09:52.840 mode for editor previews, check distances using vector three, do 195 00:09:53.000 --> 00:09:57.120 distance and trigger cube map updates or swamps. It's powerful, 196 00:09:57.240 --> 00:10:00.039 but needs optimization. So if we connect this to the 197 00:10:00.039 --> 00:10:03.600 bigger picture, beyond the fundamental shine and color from diffuse 198 00:10:03.639 --> 00:10:07.279 in speculator lighting, custom lighting models let you achieve incredible 199 00:10:07.440 --> 00:10:12.039 visual fidelity, especially for really complex or unique surfaces, things 200 00:10:12.039 --> 00:10:13.960 that standard lighting just doesn't capture. 201 00:10:13.960 --> 00:10:17.399 Well, what's one of the more maybe unconventional approaches to lighting. 202 00:10:17.440 --> 00:10:19.840 You see something that doesn't rely on standard lights in 203 00:10:19.879 --> 00:10:20.320 the scene. 204 00:10:20.519 --> 00:10:23.440 One really interesting one is the lits sphere lighting model. 205 00:10:23.879 --> 00:10:26.600 You might hear it called Matt caps, especially if you've. 206 00:10:26.519 --> 00:10:29.240 Used z brush Matt caps. Okay, how does that work. 207 00:10:29.440 --> 00:10:32.720 It's a form of image based lighting. Basically, the entire 208 00:10:32.799 --> 00:10:36.240 lighting and shading of an object, highlights, shadows, everything is 209 00:10:36.320 --> 00:10:39.679 baked into a single two D texture, which looks like 210 00:10:39.720 --> 00:10:42.240 a picture of a sphere lit in a certain way. 211 00:10:42.360 --> 00:10:45.679 So you map that sphere image onto your object sort of. 212 00:10:45.799 --> 00:10:48.960 Yeah. The shader uses the object surface normal relative to 213 00:10:49.000 --> 00:10:52.000 the camera to look up the color on this sphere map. 214 00:10:52.879 --> 00:10:56.120 The big catches. This lighting is completely fake in a way. 215 00:10:56.360 --> 00:10:58.120 It doesn't react to scene lights at all. 216 00:10:58.240 --> 00:11:00.600 Ah, so it's always lit the same way relative to. 217 00:11:00.559 --> 00:11:03.279 The camera, exactly locked to the camera's view. But you 218 00:11:03.320 --> 00:11:06.320 can swap out the Matt cab texture to instantly change 219 00:11:06.320 --> 00:11:09.559 the perceived lighting and material. It's very fast, great for 220 00:11:09.600 --> 00:11:11.639 stylized looks or sculpting previews. 221 00:11:11.799 --> 00:11:14.039 Interesting shortcut. What else in image based lighting? 222 00:11:14.159 --> 00:11:17.759 Another technique is the diffuse convolution lighting model. This uses 223 00:11:17.799 --> 00:11:22.000 a preprocess sort of blurred cube map to simulate soft 224 00:11:22.240 --> 00:11:24.759 diffuse ambient lighting from the environment. 225 00:11:24.519 --> 00:11:27.320 So capturing the general color of the surroundings precisely. 226 00:11:27.360 --> 00:11:29.840 It gives you that nice effect where an object picks 227 00:11:29.879 --> 00:11:33.000 up ambient color from say a blue sky above and 228 00:11:33.039 --> 00:11:36.159 green grass below. I think ambient cube shading a convolution 229 00:11:36.279 --> 00:11:38.600 or blurring process is too slow for real time, but 230 00:11:38.679 --> 00:11:42.000 you pre calculate it great for static scenes or cinematics. 231 00:11:42.200 --> 00:11:45.879 For that realistic environmental downslid. It often uses the world 232 00:11:45.919 --> 00:11:48.879 normal vector function to sample this blurred cube map. 233 00:11:48.960 --> 00:11:51.720 Okay, so you have these specialized models, but then you 234 00:11:51.720 --> 00:11:54.519 start combining things. Right, what's a good example of a 235 00:11:54.519 --> 00:11:56.519 material that pulls multiple techniques together. 236 00:11:56.879 --> 00:11:59.480 The vehicle paint lighting model is a perfect example. It's 237 00:11:59.519 --> 00:12:02.840 not just one simple effect. It's often a sophisticated blend. 238 00:12:03.240 --> 00:12:08.240 You might use special BRDF textures B or bidirectional reflectance 239 00:12:08.279 --> 00:12:12.799 distribution function basically textures that define how light reflects differently 240 00:12:13.039 --> 00:12:15.559 based on viewing and light angles. So you use those 241 00:12:15.600 --> 00:12:18.120 for the diffuse color, maybe get that subtle color shift 242 00:12:18.159 --> 00:12:20.639 you see on cars, and you combine it with cue 243 00:12:20.679 --> 00:12:25.080 AAPS for the sharp clearcoat reflections. It really brings many techniques. 244 00:12:24.679 --> 00:12:28.679 Together, right, that complex layered Look what about something really 245 00:12:28.840 --> 00:12:32.080 organic like skin that seems incredibly hard to get right. 246 00:12:32.399 --> 00:12:36.399 Oh. Skin shading is notoriously tricky because light doesn't just 247 00:12:36.519 --> 00:12:41.480 bounce off skin, It penetrates and scatters underneath, called subsurface scattering. 248 00:12:41.919 --> 00:12:43.440 How do shaders even fake that? 249 00:12:43.639 --> 00:12:47.120 Well? The diffuse part often uses a BRDF lookup texture 250 00:12:47.480 --> 00:12:51.360 specifically designed to simulate that light scattering, and the speculator 251 00:12:51.440 --> 00:12:55.320 or shine is complex too. It usually incorporates fresmal effects 252 00:12:55.320 --> 00:12:58.360 and maybe some rim lighting techniques to give that soft, 253 00:12:58.399 --> 00:13:01.519 waxy highlight you see on skin. It often relies on 254 00:13:01.600 --> 00:13:04.759 calculating things like blurred normals and surface curvature. 255 00:13:04.840 --> 00:13:07.200 Curvature like how quickly the surface is bending. 256 00:13:07.320 --> 00:13:10.279 Yeah, Using functions like fwidth to find sharp changes in 257 00:13:10.360 --> 00:13:13.159 length to measure how sharp they are helps find details 258 00:13:13.200 --> 00:13:15.480 like pores or wrinkles to subtly affect the lighting. 259 00:13:15.559 --> 00:13:18.679 Wow. And for cloth shading, getting that fabric look a. 260 00:13:18.720 --> 00:13:22.440 Common technique there involves detail normal maps and detailed textures. 261 00:13:22.519 --> 00:13:23.559 Using two normal maps. 262 00:13:23.919 --> 00:13:28.279 Yeah, you overlay a fine tiling normal map representing the 263 00:13:28.320 --> 00:13:30.519 weave pattern on top of the main normal map for 264 00:13:30.559 --> 00:13:34.000 the folds. This achieves a higher level of micro detail, 265 00:13:34.320 --> 00:13:37.600 helping to break up and realistically disperse the speculator highlights 266 00:13:37.679 --> 00:13:40.799 across the tiny fibers makes it look much more like 267 00:13:40.840 --> 00:13:41.639 actual fabric. 268 00:13:41.799 --> 00:13:45.519 We've covered a lot on making things look solid, shiny, reflective, 269 00:13:46.200 --> 00:13:50.320 but what about the opposite, making things see through? Transparency 270 00:13:50.399 --> 00:13:53.360 seems simple, maybe just an alpha channel, but you mention 271 00:13:53.480 --> 00:13:54.399 it causes issues. 272 00:13:54.440 --> 00:13:57.960 It does, especially with draw order. Creating transparency with alpha 273 00:13:58.039 --> 00:14:01.080 is the fundamental part. Yes, you add an alpha parameters 274 00:14:01.120 --> 00:14:04.080 your shadeer's set up the hashtag pragma statement telling unity 275 00:14:04.080 --> 00:14:06.600 it can be transparent. Then you feed a value, usually 276 00:14:06.639 --> 00:14:09.480 from a texture's alpha channel to the O alpha parameter 277 00:14:09.519 --> 00:14:12.320 in your output. Zero is fully transparent, one is opaque. 278 00:14:12.399 --> 00:14:15.320 Okay, standard stuff. But then there's the transparent cutoff shader. 279 00:14:15.399 --> 00:14:16.080 How's that different? 280 00:14:16.240 --> 00:14:19.840 Right? Cutoff uses an alpha test variable name parameter. Instead 281 00:14:19.840 --> 00:14:22.759 of blending smoothly, it acts like a switch. If the 282 00:14:22.799 --> 00:14:26.000 alpha value is below a certain threshold the variable name 283 00:14:26.399 --> 00:14:30.279 the pixel is completely discarded, fully transparent. If it's above, 284 00:14:30.720 --> 00:14:33.000 it's fully opaque, no in between grays. 285 00:14:33.080 --> 00:14:35.399 Why use that performance often? 286 00:14:35.720 --> 00:14:41.200 Yes, especially historically, it avoids some blending complexities. But counterintuitively, 287 00:14:41.559 --> 00:14:44.679 the source points out that on some mobile GPUs, doing 288 00:14:44.679 --> 00:14:47.200 that per pixel test for the cutoff can actually be 289 00:14:47.240 --> 00:14:50.840 more expensive than regular alpha blending depends on the hardware architecture. 290 00:14:50.919 --> 00:14:54.080 Huh. Interesting, So this draw order problem, how does Unity 291 00:14:54.159 --> 00:14:56.200 handle stacks of transparent things. 292 00:14:56.519 --> 00:14:59.320 That's where depth sorting with rendered cues comes in. Normally, 293 00:14:59.320 --> 00:15:02.399 a Unity draw solid objects from front to back using 294 00:15:02.440 --> 00:15:05.159 the depth buffer or Z buffer to make sure closer 295 00:15:05.200 --> 00:15:08.440 things cover farther things. Transparent objects are usually drawn after 296 00:15:08.480 --> 00:15:10.919 solid ones sorted back to front, back to front. Why 297 00:15:11.080 --> 00:15:14.080 so that you can see farther transparent objects through closer 298 00:15:14.120 --> 00:15:18.399 ones correctly. But you can override this default sorting using 299 00:15:18.440 --> 00:15:22.200 tags in your shader. You can set tags q transparent ten, 300 00:15:22.279 --> 00:15:25.039 for example, to force an object into a specific drawing 301 00:15:25.159 --> 00:15:26.759 order within the transparent group. 302 00:15:26.600 --> 00:15:28.399 So you can layer them manually if needed. 303 00:15:28.559 --> 00:15:33.120 Exactly. Unity has built in queues like background geometry, alpha test, 304 00:15:33.159 --> 00:15:37.200 or cutoff shaders transparent and overlay, and a crucial tag 305 00:15:37.240 --> 00:15:40.639 for transparent objects is z write off. This tells Unity 306 00:15:40.759 --> 00:15:44.120 not to write the object's depth information into the depth buffer, 307 00:15:44.279 --> 00:15:47.200 which is essential for letting things behind it render correctly. 308 00:15:47.279 --> 00:15:51.399 Okay, that makes sense. So a practical example maybe GUI 309 00:15:51.600 --> 00:15:54.679 and transparency like three D interfaces floating in the world. 310 00:15:54.759 --> 00:15:57.840 Perfect example, you might create a cool three dui using 311 00:15:57.879 --> 00:16:01.000 texture sheets with alpha channels for buttons or readouts. When 312 00:16:01.000 --> 00:16:04.240 those UI elements get very close together, maybe overlapping slightly, 313 00:16:04.759 --> 00:16:07.399 Unity's automatic sorting might flicker or get confused. 314 00:16:07.480 --> 00:16:10.159 Right, you see that Z fighting sometimes exactly. 315 00:16:10.279 --> 00:16:13.480 So this is where a small C sharp script, maybe 316 00:16:13.559 --> 00:16:16.000 using execute and edit mode so it runs in the editor, 317 00:16:16.480 --> 00:16:19.600 becomes invaluable. It can let you dynamically adjust the Q 318 00:16:19.840 --> 00:16:22.759 values for individual UI materials right there in the inspector. 319 00:16:22.919 --> 00:16:26.279 It gives you that fine grained Photoshop like layer control 320 00:16:26.519 --> 00:16:27.799 over your three DUI. 321 00:16:27.519 --> 00:16:32.039 Elements, super useful for complex interfaces. Now, moving beyond just 322 00:16:32.080 --> 00:16:36.679 surface appearance. Vertex magic, you mean, shaders can actually change 323 00:16:36.679 --> 00:16:38.120 the shape of the model precisely. 324 00:16:38.279 --> 00:16:40.840 There's a special function within a shader, the vertex function, 325 00:16:41.039 --> 00:16:43.799 that runs once for every single point or vertex that 326 00:16:43.840 --> 00:16:47.000 makes up the three D model. Inside this function, you 327 00:16:47.000 --> 00:16:50.320 can manipulate that vertex's position, it's color, even it's textra 328 00:16:50.399 --> 00:16:52.960 coordinates uves before it even gets rendered. 329 00:16:53.039 --> 00:16:55.440 WHOA, so you can access a vertex color in a 330 00:16:55.480 --> 00:16:58.639 surface shader. Models can store colored data per point. 331 00:16:58.720 --> 00:17:01.360 They can often export of and three D modeling software. 332 00:17:01.519 --> 00:17:04.119 You can retrieve this using a specific infesststructure like ap 333 00:17:04.240 --> 00:17:07.119 data full and passed along. This float for color variable 334 00:17:07.119 --> 00:17:09.799 can hold RGB and even an alpha value for extra 335 00:17:09.880 --> 00:17:11.480 data right there on the vertex. 336 00:17:11.519 --> 00:17:13.160 What can you do with that vertex data? 337 00:17:13.240 --> 00:17:15.640 All sorts of cool stuff. You can animate vertices in 338 00:17:15.680 --> 00:17:19.680 a surface shader. Imagine making a flag ripple realistically. Instead 339 00:17:19.720 --> 00:17:22.720 of complex bones and skinning, you just apply a sine 340 00:17:22.720 --> 00:17:26.480 wave using the sin function to the vertex positions based 341 00:17:26.519 --> 00:17:27.160 on time. 342 00:17:27.079 --> 00:17:29.240 So the shader itself makes the flagwave. 343 00:17:29.359 --> 00:17:32.799 Yeah, or create ocean waves pulsating effects, all without traditional 344 00:17:32.839 --> 00:17:36.279 animation systems. You could also use Vertex color for terrains 345 00:17:36.319 --> 00:17:39.960 to blend textures. For instance, paint Vertex colors onto your 346 00:17:40.079 --> 00:17:43.240 terrain mash, maybe red for rock, green for grass, and 347 00:17:43.359 --> 00:17:45.559 use those colors in the shader to control the blend. 348 00:17:45.960 --> 00:17:48.359 Combined with a height map, this lets you get really 349 00:17:48.400 --> 00:17:52.079 detailed blending in crevasses and on hillsides. Games like Uncharted 350 00:17:52.079 --> 00:17:54.759 in Gears of War made this popular for their stunning environments. 351 00:17:55.480 --> 00:17:59.000 This all sounds incredibly powerful, but it does raise important question. 352 00:17:59.799 --> 00:18:04.240 With all these techniques layering effects, maybe animating vertices, how 353 00:18:04.279 --> 00:18:08.319 do we keep things running smoothly? Especially on say, mobile devices, 354 00:18:08.359 --> 00:18:10.119 How do we manage performance? 355 00:18:10.240 --> 00:18:13.000 That's the critical question, isn't it? What makes a shader 356 00:18:13.119 --> 00:18:15.680 cheap or efficient? It's not always obvious. 357 00:18:15.440 --> 00:18:19.559 It's not, but generally it means optimizing a few things, 358 00:18:20.599 --> 00:18:23.920 minimizing memory usage for variables, keeping the number of texture 359 00:18:23.960 --> 00:18:28.039 lookups low, and writing efficient code logic within the shader itself, 360 00:18:28.680 --> 00:18:30.079 fewer calculations per pixel. 361 00:18:30.119 --> 00:18:32.559 Basically, how do you even measure that? How do you 362 00:18:32.599 --> 00:18:34.039 know if a shader is slow? 363 00:18:34.400 --> 00:18:37.400 Unity's built in profiler is your absolute best friend here. 364 00:18:37.400 --> 00:18:38.880 It's like an EKG for your game. 365 00:18:39.079 --> 00:18:39.480 Okay. 366 00:18:39.680 --> 00:18:44.559 Lets you track GPU usage, CPU usage and specifically rendering performance. 367 00:18:44.599 --> 00:18:47.279 Frame by frame. You can see details like draw calls, 368 00:18:47.319 --> 00:18:50.880 how many separate things are being drawn, and the actual milliseconds. 369 00:18:50.279 --> 00:18:53.160 Spent rendering, so you can pinpoint bottlenecks exactly. 370 00:18:53.519 --> 00:18:56.400 Profiling might clearly show that adding just one more texture 371 00:18:56.400 --> 00:19:00.359 lookup and ALERP function for blending significantly increases the render 372 00:19:00.400 --> 00:19:03.359 time for certain objects, guiding you directly to where optimization 373 00:19:03.440 --> 00:19:03.839 is needed. 374 00:19:04.160 --> 00:19:07.680 And what about specifically modifying shaders for mobile? Are there 375 00:19:07.680 --> 00:19:08.400 common tricks? 376 00:19:08.680 --> 00:19:12.119 Yeah? There are definitely mobile specific considerations. You might use 377 00:19:12.160 --> 00:19:14.920 simplified lighting functions like a proxview or half as view, 378 00:19:15.400 --> 00:19:19.079 which are faster but slightly less accurate. You might declare 379 00:19:19.119 --> 00:19:22.400 variables using fixed or half precision instead of full float 380 00:19:22.799 --> 00:19:23.920 to save memory. 381 00:19:23.559 --> 00:19:25.960 And bandwidth smaller numbers basically right. 382 00:19:26.319 --> 00:19:28.839 You might also use directives like no forward ad to 383 00:19:28.920 --> 00:19:32.640 limit complex per pixel lighting to only one directional light, 384 00:19:32.839 --> 00:19:37.920 significantly cutting down calculations, or explicitly state no light mapping 385 00:19:37.920 --> 00:19:40.640 support if you're not using baked lighting to prevent the 386 00:19:40.680 --> 00:19:44.480 shader from doing unnecessary checks. Yeah, it's always a trade off. 387 00:19:44.880 --> 00:19:48.599 Balancing visual fidelity with the performance constraints of your target 388 00:19:48.599 --> 00:19:49.599 hardware makes sense. 389 00:19:49.680 --> 00:19:51.440 It sounds like you could end up with lots of 390 00:19:51.480 --> 00:19:54.559 slightly different versions of shaders, though, how do you manage 391 00:19:54.599 --> 00:19:55.440 that complexity. 392 00:19:55.880 --> 00:19:59.480 That's where modularity comes in. Making your shader world modular 393 00:19:59.519 --> 00:20:02.319 with c includes is crucial. Think of them like shared 394 00:20:02.319 --> 00:20:05.359 code libraries or header files and C plus plus hand. 395 00:20:05.720 --> 00:20:10.119 Unity already provides several built in siege include files. Unity 396 00:20:10.160 --> 00:20:12.400 CG dot c jink is a big one, full of 397 00:20:12.400 --> 00:20:16.799 helper functions for common tasks like calculating luminance for desaturation 398 00:20:16.880 --> 00:20:20.720 effects lighting. Dot cjinc defines the standard built in lighting 399 00:20:20.759 --> 00:20:21.799 models like blindphone. 400 00:20:22.000 --> 00:20:23.480 But the real power is making your own. 401 00:20:23.640 --> 00:20:26.599