Speaker 1: You know that feeling when you're playing a game and
Speaker 1: the graphics just pop, the way light catches the surface,
Speaker 1: or those subtle reflections, maybe even that really distinct stylized look,
Speaker 1: you know that makes a world feel real or sometimes
Speaker 1: magically hand drawn. Well, a lot of that visual match
Speaker 1: comes down to something called shads.
Speaker 2: Absolutely, they're kind of like the secret sauce. Whden't you say?
Speaker 2: They define how light interacts with everything you see exactly.
Speaker 1: It turns simple three D models into something visually rich.
Speaker 2: They're really the unsung heroes working away at the pixel level.
Speaker 2: It's where art definitely meets code.
Speaker 1: So today we're doing a deep dive into this fascinating
Speaker 1: world Unity Shads and Effects. Right, we're drawing from a
Speaker 1: really great resource, the Unity five point x Shaters and
Speaker 1: Effects Cookbook. Our mission is basically to unpack how developers
Speaker 1: use shader programming to really bring their Unity projects to life.
Speaker 2: Yeah, and give you a shortcut to understanding what's behind
Speaker 2: modern game visuals from you know, the basic building blocks
Speaker 2: right up to some really mind ending real time effects.
Speaker 1: And this cookbook the authors are top notch Alan Zuconi
Speaker 1: develops thirty under thirty developer behind zero Arbitalis and.
Speaker 2: Kenneth Lammers, He's got what over fifteen years in the industry,
Speaker 2: worked on huge titles like Call of Duty three, Alan Wake.
Speaker 1: So yeah, there definitely are expert guides for this for sure.
Speaker 1: So if you've ever wondered how games get those stunning visuals,
Speaker 1: how a simple cube can look like metal or wood,
Speaker 1: or how an explosion just looks.
Speaker 2: Right, then this deep dive is definitely for you. Get
Speaker 2: ready for some aha moments.
Speaker 1: Let's start right at the beginning. Then at its core,
Speaker 1: what is a shader?
Speaker 2: Okay? So think of it like a tiny program, a
Speaker 2: specialized program that runs on your graphics card, okay, and
Speaker 2: its job is to tell the graphics card how light
Speaker 2: should behave on a surface. Imagine you have a plane
Speaker 2: three D cube. Yep. The shader is what makes it
Speaker 2: look like shiny metal or rough wood or maybe even glass.
Speaker 2: It's not just slapping on a picture. It's simulating how
Speaker 2: light interacts with that material.
Speaker 1: A right, So it's about the light interaction, not just
Speaker 1: the color. Makes sense, it's the visual identity exactly. But
Speaker 1: how does this shader fit into, you know, the bigger
Speaker 1: picture in unity the rendering process? What's the chain of command.
Speaker 2: Good question. Let's break it down. So in Unity, everything
Speaker 2: you see is basically a game object.
Speaker 1: Right, characters, props everything.
Speaker 2: Yeah, And for a three D game object to show up,
Speaker 2: it usually needs a component called a mesh renderer. Think
Speaker 2: of the mesh render like the stage manager deciding how
Speaker 2: that three D model appears.
Speaker 1: Okay, like deciding its costume and lighting pretty much.
Speaker 2: Yeah, And that mesh render uses something called a material.
Speaker 2: The material is like the specific recipe is its silk
Speaker 2: is a burlap? Got it? And that material contains the shader.
Speaker 2: The shader is the actual set of instructions defining how
Speaker 2: light bounces off that silk or burlap. So the chain
Speaker 2: is game object, mish renderer, material.
Speaker 1: Shader, clear object renderer, material shader. And speaking of Unity,
Speaker 1: Unity five brought a big change rate hebr oh.
Speaker 2: Huge physically based rendering PBR that became the new standard.
Speaker 1: What was so revolutionary about it? More realistic graphics?
Speaker 2: Well, yes, but it was more than that. The real
Speaker 2: insight was that PBR provided a consistent, physically plausible way
Speaker 2: to describe materials. Consistent how meaning artists could define a material,
Speaker 2: say brushed aluminum, and it would look correct under almost
Speaker 2: any lighting condition morning sun, dim, indoor lights, whatever. No
Speaker 2: more endless tweaking for every scene.
Speaker 1: Ah okay, so it behaves predictably based on physics Exactly.
Speaker 2: It was a massive step up from the older diffuse
Speaker 2: and specular models in Unity four, which often needed a
Speaker 2: lot more manual fiddling.
Speaker 1: That sounds like a life saver for artists, and I
Speaker 1: hear properties make it even easier for them.
Speaker 2: What are those properties? Are Billiant. They're basically controls that
Speaker 2: show up in the Unity Editor in the Materials Inspector tab.
Speaker 1: Like sliders and color pickers.
Speaker 2: Precisely, a shaded programmer writes a line of code like
Speaker 2: color main, color color and boom, the artist get a
Speaker 2: color swatch in the editor. Or roughness roughness range zero
Speaker 2: one zero point gives them a slider, so the artists.
Speaker 1: Can tweet the look, change the color, adjust roughness without
Speaker 1: needing to code exactly.
Speaker 2: That's the whole point. It separates the technical shader logic
Speaker 2: from the artistic tweaking.
Speaker 1: And crucially, where are the values for those properties stored
Speaker 1: in the shader?
Speaker 2: No, that's the key distinction. The properties are defined in
Speaker 2: the shader, but there's specific values the chosen color the
Speaker 2: slider setting are stored in the material.
Speaker 1: Ah, so you can have one shader like metal, but
Speaker 1: multiple materials using it, shiny steel, rusty iron, each with
Speaker 1: different property values.
Speaker 2: You got it. Change a property on the shiny steel
Speaker 2: material and all objects using that material update instantly. Super flexible.
Speaker 1: Okay, Now, for anyone brave enough to write their own shaders,
Speaker 1: debugging sounds like fun. That magenta color, ah, the dreaded magenta.
Speaker 2: Yeah, unlike C sharp scripts that just stop your game
Speaker 2: shader errors, don't halt anything. Instead, your object turns bright unshaded.
Speaker 1: Magenta, a very clear error message.
Speaker 2: It certainly gets your attention. Commonness, the steaks are you know, typos,
Speaker 2: missing semicolms forgetting a bracket or having a property defined
Speaker 2: but not actually using it in the shader code. It
Speaker 2: needs that link.
Speaker 1: Good to know. Also heard something about floats in CIG
Speaker 1: being slightly different.
Speaker 2: Yeah, minor thing, but it catches people. In CIG the
Speaker 2: shader language you just write one point zero, one point
Speaker 2: oh f like you often do in Sea Shark, small detail,
Speaker 2: big magenta headache if you forget.
Speaker 1: Okay, so we've got the basics. Shaders tell light what
Speaker 1: to do. Artists use materials and properties to tweak them.
Speaker 1: But how do we get specific looks making something actually
Speaker 1: look like wood or stone?
Speaker 2: Right? That takes us into surface shaders, textures and lighting models.
Speaker 2: This is where the real visual magic.
Speaker 1: Happens surface shaders. What's the core idea there?
Speaker 2: A surface shad basically has two main parts. First, there's
Speaker 2: a surface function. In this function, you tell unity about
Speaker 2: the physical properties of your surface, like it's base color, albedo,
Speaker 2: how smooth or rough it is, smoothness if it's metallic, metallic, maybe,
Speaker 2: how transparent?
Speaker 1: And alpha okay, describing the material itself exactly.
Speaker 2: Then all that information gets past to a lighting model.
Speaker 2: The lighting model takes those surface properties and information about
Speaker 2: the lights in your scene and calculates the final color
Speaker 2: for each pixel.
Speaker 1: So it combines the what it is with how it's
Speaker 1: lit precisely.
Speaker 2: And there are different structs or data packages for these properties,
Speaker 2: like Surf's output standard for PBR. They hold things like albedo,
Speaker 2: normal emission, metallic, smoothness, alpha, got it, and.
Speaker 1: I understand c The shader language is pretty smart about
Speaker 1: handling data pact rays.
Speaker 2: Yeah, CG is really efficient. It uses things like float
Speaker 2: three or float four. These packed rays. Think a float
Speaker 2: three holding xyz for position or RGB for color. A
Speaker 2: float four adds W or alpha.
Speaker 1: So it groups related numbers together, right, and.
Speaker 2: This lets you do cool stuff called swizzling. Like if
Speaker 2: you have a color and a float four called color,
Speaker 2: you can grab just the RGB parts really easily by
Speaker 2: writing color dot RGB, or even rearrange them like color
Speaker 2: dot bgr meat, trek, or even smearing. Assigning a single
Speaker 2: value you like point five to a float three will
Speaker 2: set all three components xyz two point five. It's all
Speaker 2: about doing math on multiple values at once, which gpuser.
Speaker 1: Great app Okay, back to textures. How do you get
Speaker 1: a flat image, say bricks, onto a three D wall.
Speaker 2: That's texture mapping. It relies on something called UV data
Speaker 2: stored in the three D model itself.
Speaker 1: UV data like coordinates.
Speaker 2: Exactly each vertex corner point of your three D model
Speaker 2: has two coordinates U and V, usually ranging from zero
Speaker 2: to one. Think of it like flattening a three D
Speaker 2: model onto a two D plane. These uvs tell the
Speaker 2: shader exactly which part of the two D texture image
Speaker 2: corresponds to which part of the three D model's.
Speaker 1: Surface, and the GPU figures out the bits in between
Speaker 1: the vertices.
Speaker 2: Yep, it interpolates the uvs across the surface. Then the
Speaker 2: shader uses a function usually text two D, to look
Speaker 2: up or sample the color from the texture at that
Speaker 2: specific UV coordinate for each pixel.
Speaker 1: Clever? Can you animate textures this way like flowing water?
Speaker 2: Absolutely? You can modify the UV coordinates over time. Just
Speaker 2: add unities built in time variable or some fraction of
Speaker 2: it to the U or V coordinate before sampling the texture. Presto.
Speaker 2: Scrolling texture a classic way to fake movement.
Speaker 1: Nice, But what about adding really fine detail, like the
Speaker 1: tiny bumps on that brick wall where scratches on metal.
Speaker 1: Adding tons of polygons would kill performance, right.
Speaker 2: You definitely don'tant a model every single bump. That's where
Speaker 2: normal mapping comes in. It's a fantastic technique.
Speaker 1: How does that work? Is it another texture?
Speaker 2: It is. It's a special texture, often purplish, called a
Speaker 2: normal map or sometimes a bump map. But instead of
Speaker 2: storing color, the RGB values in this texture actually represent
Speaker 2: directions direction. Yeah, they represent the direction that the surface
Speaker 2: normal is pointing at that specific pixel. The normal is
Speaker 2: like an imaginary line pointing straight out from the surface.
Speaker 2: By slightly changing the direction of this normal according to
Speaker 2: the map, you trick the lighting calculation aw.
Speaker 1: So the light bounces off as if there was a
Speaker 1: bump there, even though the geometry is flat exactly.
Speaker 2: It gives this incredible illusion of surface detail bumps, grooves,
Speaker 2: rivet scratches without adding any extra polygons. It's super efficient.
Speaker 2: Unity even provides a function unpacked normal to easily decode
Speaker 2: the information from the normal map texture.
Speaker 1: That's seriously cool. Okay, so normal maps fake detail on
Speaker 1: solid surfaces. What about things that aren't solid, like glass
Speaker 1: or ghosts or fire. Transparency sounds difficult.
Speaker 2: It is surprisingly more complex than you might think. See
Speaker 2: for solid objects, the graphics card does clever stuff like
Speaker 2: z ordering, figuring out what's in front and only drawing that,
Speaker 2: and culling like not drawing the back faces of objects
Speaker 2: you can't see.
Speaker 1: Makes sense, saves work.
Speaker 2: But transparent objects mess that up. You need to see
Speaker 2: what's behind them, so they need special handling. You use
Speaker 2: shader tags to tell Unity how to handle them, like
Speaker 2: setting que transparent tells Unity to draw them after all.
Speaker 1: The solid stuff, so order matters a lot critically, and.
Speaker 2: You need specific shader directives like hashtag, pregma, surface dot
Speaker 2: alpha dot fade to enable blending so the it's parent
Speaker 2: object mixes correctly with the background pixels.
Speaker 1: Can you do stylized transparency too? I think the book
Speaker 1: mentioned a hologram shader.
Speaker 2: Oh yeah, that's a neat one. You can use a
Speaker 2: mathematical operation called the dot product. You calculate the dot
Speaker 2: product between the surface normal and the view direction.
Speaker 1: Okay, what does that tell you?
Speaker 2: It tells you how much a surface is facing towards
Speaker 2: or away from the camera. Surfaces facing you get one value,
Speaker 2: Surfaces facing away get another. You can then use this
Speaker 2: to make only the edges or the parts facing you
Speaker 2: slightly visible, creating that classic sci fi hologram rim.
Speaker 1: Effect, just showing the outlines kind of yeah.
Speaker 2: Or a faint semi transparent look. It's computationally cheap and
Speaker 2: great for ghosts, force fields, selected object outlines, that kind
Speaker 2: of thing.
Speaker 1: All right, we're using all these textures, color normal maps,
Speaker 1: maybe others. Textures take up memory, right, especially on mobile,
Speaker 1: any tricks for optimizing that.
Speaker 2: Big time textures are often a major memory hog. A
Speaker 2: really common technique is texture packing, sometimes called channel.
Speaker 1: Packing, packing like zipping files sort of.
Speaker 2: But for data, many maps you need might only be grayscale,
Speaker 2: like a roughness map or a metallic map, or an
Speaker 2: ambient inclusion map. They only need one channel of.
Speaker 1: Data instead of the usual three for RGB color exactly.
Speaker 2: So you can take say your roughness map and put
Speaker 2: it into the red channel of a texture. Take your
Speaker 2: metallic map, put it in the green channel, maybe an
Speaker 2: ambient inclusion map in the blue channel, and something else
Speaker 2: in the alpha channel.
Speaker 1: Ah. So one our GBA texture holds four different gray
Speaker 1: scale maps.
Speaker 2: You got it. It saves a ton of memory and
Speaker 2: reduces the number of texture samples the shader needs to do.
Speaker 2: Super common for character models and especially terrain. For terrain,
Speaker 2: you might have one packed texture controlling how grass, dirt, rock,
Speaker 2: and snow blend together using a function called LURP.
Speaker 1: LURP linear interpolation.
Speaker 2: Yeah, it smoothly blends between two values based on a
Speaker 2: third value. So you could use the red channel of
Speaker 2: your blend map to control the blend between dirt and grass,
Speaker 2: the green channel for grass and rock, and so on.
Speaker 2: Very efficient.
Speaker 1: Okay, that makes sense. We mentioned lighting models earlier as
Speaker 1: part of surface shaders. Why would a developer bother making
Speaker 1: a custom lighting model. If Unity has good built in
Speaker 1: ones like PBR, well, PBR.
Speaker 2: Is fantastic for realism. But sometimes you don't want realism.
Speaker 2: You want a specific artistic style. Maybe you want your
Speaker 2: game to look like a comic book or an old
Speaker 2: cartoon or something completely unique. Custom lighting models give you
Speaker 2: that precise control over how light and shadow behave, letting
Speaker 2: you define your own visual language.
Speaker 1: So for non photorealistic rendering NPR.
Speaker 2: Exactly, or even just for optimizing for very low end
Speaker 2: platforms where PBR might be too expensive. Understanding the classic
Speaker 2: models helps too.
Speaker 1: Let's talk about those classics. What's Lambertune reflectants.
Speaker 2: Lambertine was basically the default diffuse lighting model in Unity four.
Speaker 2: It's super simple, very fast. It calculates brightness based only
Speaker 2: on the angle between the light hitting the surface and
Speaker 2: the surface normal itself.
Speaker 1: So how directly the light hits it right, uses a.
Speaker 2: Dot product for that. It results in a very matt
Speaker 2: non shiny look. Thinks bull flat shading great for stylized
Speaker 2: low poly games, very efficient.
Speaker 1: And then the opposite end stylistically is maybe tune shading
Speaker 1: or cell shading. That comic book look.
Speaker 2: Yeah, totally different. Goal tune shading aims for that flat,
Speaker 2: hand drawn cartoon style. The trick here is usually a
Speaker 2: custom Whiting model that takes the smooth gradient of light
Speaker 2: intensity you'd get from.
Speaker 1: Lambursha makes it chunky exactly.
Speaker 2: It uses something called a ramp map. It's usually a
Speaker 2: small one D texture, like a thin strip with distinct
Speaker 2: bands of color or brightness. The shader calculates the normal
Speaker 2: light intensity often called n Dattel, the dot product of
Speaker 2: normal and light direction. Uses that value to look up
Speaker 2: a color on the ramp map, and poof, Instead of
Speaker 2: a smooth gradient, you get sharp defined bands of color.
Speaker 2: That's the cell shaded look.
Speaker 1: Clever use of a texture to change the lighting result. Okay,
Speaker 1: what about shininess speculat highlights, We've got pong blind fall right.
Speaker 2: These are about adding those bright spots you see on
Speaker 2: shiny objects. Is sort of a classic foundational model. It
Speaker 2: calculates the reflection based on the angle between the direction
Speaker 2: the camera is viewing from and the direction the light
Speaker 2: would perfectly reflect off the surface, So.
Speaker 1: It depends on where you're looking from very.
Speaker 2: Much, so it's view dependent. It gives a decent shiny.
Speaker 1: Look and Blindphong is it just better.
Speaker 2: It's often preferred. Yeah, it's generally faster to calculate, and
Speaker 2: in many cases looks a bit more realistic or at
Speaker 2: least softer than basic fong. Instead of calculating the full
Speaker 2: reflection vector, it uses a clever shortcut involving a half vector,
Speaker 2: which is the vector halfway between the light direction and
Speaker 2: the view direction. It was the default specular model and
Speaker 2: unity for still very useful.
Speaker 1: Okay, simple shininess covered. But then there's anisotropic speculator that
Speaker 1: sounds complex. Brushed metal hair? How does that work?
Speaker 2: Anisotropic is really cool. It simulates materials where the shininess
Speaker 2: isn't uniform because the surface has tiny parallel grooves or
Speaker 2: fibers I think brushed aluminum. The back of a CD
Speaker 2: vinyl records even strands of hair.
Speaker 1: So the highlight isn't just a round dot exactly.
Speaker 2: Instead of a circular highlight, it stretches the specular highlight
Speaker 2: perpendicularly to the direction of those tiny grooves or strands.
Speaker 2: It requires extra information, usually from another texture or model data,
Speaker 2: telling the shadeer which way the grain or fibers run
Speaker 2: on the surface. It has a massive amount of realism
Speaker 2: for those kinds of materials.
Speaker 1: Wow, Okay, that's pretty specific control. Let's circle back to
Speaker 1: PBR and unity five. You said it was a revolution.
Speaker 1: What are the main workflows?
Speaker 2: The two main ones are standard and standard a specular setup.
Speaker 2: The most common one is the standard workflow, which uses
Speaker 2: a metallic map.
Speaker 1: Metallic workflow. How does that enforce realism?
Speaker 2: It works based on a key physical principle. Things are
Speaker 2: generally either metallic or non metallic dielectric. Pure metals get
Speaker 2: almost all their color from reflected light. They have very
Speaker 2: dark or black diffuse color. Their albedo map basically defines
Speaker 2: the color of the reflection.
Speaker 1: Okay, and non metals like plastic or wood.
Speaker 2: Non metals have a colored diffuse component that's their albedo
Speaker 2: map color, and their specular reflections are generally noncolored, reflecting
Speaker 2: the color of the light source itself. The metallic map,
Speaker 2: usually a grayscale texture packed new channel tells the shade
Speaker 2: or how metallic. Each part of the surface is. Black
Speaker 2: means non metal, white means pure metal, gray is somewhere
Speaker 2: in between like dusty or corroded metal.
Speaker 1: And smoothness is that packed in there too?
Speaker 2: Often? Yes, the smoothness value controlling how sharp or blurry
Speaker 2: reflections are is frequently packed into the alpha channel of
Speaker 2: the metallic map texture. So one map controls both metalness
Speaker 2: and smoothness.
Speaker 1: It's efficient PBR in transparency. How does that work? Does
Speaker 1: it handle glass and ghosts differently?
Speaker 2: It does. PBR offers specific modes. Transparent mode is for
Speaker 2: things like proper glass or clear plastics. Crucially, it keeps
Speaker 2: all the PBR goodness speculat highlights, reflections, Fresnel effect where
Speaker 2: reflectivity changes with the young angle. It looks physically correct.
Speaker 1: Okay, what about ghosts?
Speaker 2: For that, you'd probably use fade mode. In fade mode,
Speaker 2: as the object becomes more transparent, everything fades out, including
Speaker 2: the specular highlights and reflections. Perfect for effects where things
Speaker 2: need to dissolve completely.
Speaker 1: And the third one cut out.
Speaker 2: Cutout mode is for things that are geometrically solid but
Speaker 2: need to look like they have holes, like chain link fences,
Speaker 2: leaves on a tree, or detailed grates. It uses the
Speaker 2: alpha channel of the texture, but it's not blended transparency.
Speaker 2: It's either fully opaque or fully invisible based on an
Speaker 2: alpha cutoff slider, sharp edges, no semi transparency.
Speaker 1: Got it makes sense for foliage. Now realistic reflections like
Speaker 1: mirrors or shiny floors. You mentioned reflection probes right.
Speaker 2: Real time reflections are super expensive, So reflection probes are
Speaker 2: a way to capture the environment around a certain point.
Speaker 2: Think of it like taking a three hundred and sixty
Speaker 2: degree photo from that spot and storing it as a
Speaker 2: special texture called a cube map.
Speaker 1: Six images, one for each direction.
Speaker 2: Exactly up, down, left, right, front, back. Then shiny objects
Speaker 2: near that probe can sample this cube map to show
Speaker 2: reflections of the surrounding static scenery.
Speaker 1: Are they expensive?
Speaker 2: They can be, especially if they need to update in
Speaker 2: real time, like if dynamic objects need to be reflected.
Speaker 2: Often they're baked, meaning they capture the static environment once
Speaker 2: in the editor, which is much cheaper at run time.
Speaker 2: They're crucial for making metallic PBR materials look believable.
Speaker 1: Speaking of baking, light baking, that sounds like pre calculating lighting.
Speaker 2: That's exactly what it is. Calculating how light bounces around
Speaker 2: realistically in real time. Global illumination or GI is incredibly demanding,
Speaker 2: So light baking lets unity pre calculate all that complex
Speaker 2: light bouncing for objects that don't move. Your buildings terrain static.
Speaker 1: Props and saves that lighting information.
Speaker 2: Yeah, saves it into special textures called light maps. At runtime,
Speaker 2: these static objects just look up their pre calculated lighting
Speaker 2: from the light map. It looks great and is super
Speaker 2: fast compared to calculating GI every frame.
Speaker 1: But what about things that do move your player character NPCs,
Speaker 1: moving objects, They can't use static lightmaps.
Speaker 2: Correct for them. We use light probes. You scatter these
Speaker 2: probes around your scene, especially where lighting conditions change. Like
Speaker 2: light maps, they get baked. They sample the complex bounced
Speaker 2: lighting at the specific locations during the bake.
Speaker 1: Process, so they store the lighting info at points in
Speaker 1: space exactly.
Speaker 2: Then, as your character or a dynamic object moves through
Speaker 2: the scene, it looks at the nearest light probes, blends
Speaker 2: the lighting information sampled by them, and uses that to
Speaker 2: light itself. This allows moving objects to feel realistically integrated
Speaker 2: into the baked static environment. It's a clever way to
Speaker 2: get the best of both worlds, detailed lighting on static
Speaker 2: stuff dynamic objects that still fit in.
Speaker 1: It's all about balancing that realism and performance budget always.
Speaker 2: That's the name of the game.
Speaker 1: In real time graphics, okay, shifting gears a bit, shaders
Speaker 1: aren't just about color and light, right. They can actually
Speaker 1: change the shape of objects using vertex functions.
Speaker 2: Absolutely. This is where shaters get really powerful beyond just
Speaker 2: surface appearance. A Vertex function runs for every vertex or
Speaker 2: corner point of your three D model before it even
Speaker 2: gets render, and inside this function you can actually change
Speaker 2: the vertex's position in three D.
Speaker 1: Space, So you can literally move the points of the
Speaker 1: model around with code.
Speaker 2: Yep, you can deform the geometry. For example, you could
Speaker 2: access vertex colors. Did you know you can paint colors
Speaker 2: directly onto the vertices of a model in many three
Speaker 2: D modeling tools.
Speaker 1: I didn't realize that.
Speaker 2: Yeah, And you can read those colors in the vertex
Speaker 2: shader and use the drive effects maybe make parts glow
Speaker 2: or control how much wind affects certain parts of a mesh.
Speaker 1: Speaking of wind, can you animate vertices like a waving flag?
Speaker 2: Totally? That's a classic use case. Instead of complex physics
Speaker 2: or bone animations, you can use a simple sine wave
Speaker 2: based on time time and the vertex's position to make
Speaker 2: vertices move up and down or back and forth, creating
Speaker 2: a realistic waving flag or rippling water effect directly in
Speaker 2: the shader.
Speaker 1: That's really efficient. What's this normal extrusion technique? It sounds weird,
Speaker 1: making things chubbier or skinnier.
Speaker 2: It is a bit weird, but very effective. You take
Speaker 2: the vertex position and push it outwards or inwards along
Speaker 2: its normal direction, that line pointing straight out from the surface.
Speaker 1: So everything expands or contracts along its surface direction.
Speaker 2: Right, you can make a character look inslated or deflated,
Speaker 2: and you can control how much extrusion happens using a
Speaker 2: texture map an extrusion map, so you could make certain
Speaker 2: parts puff out and others sink in.
Speaker 1: And the book mentions zombifying characters.
Speaker 2: Yeah, that's a great example. You could use an extrusion
Speaker 2: map to make the skin sync in over the bones,
Speaker 2: giving that gaunt, skeletal look, or for something less gruesome.
Speaker 2: Snow shaders often use it. They might detect which triangles
Speaker 2: face upwards, color them white, and then extrude them slightly
Speaker 2: along their normal to simulate snow piling up.
Speaker 1: Wow and explosions.
Speaker 2: Vertex shads are key from many volumetric effects too. For
Speaker 2: an explosion, you might start with a sphere mesh, then
Speaker 2: use noise textures and time in the vertex shader. To
Speaker 2: displace the vertices outwards in a chaotic expanding way. Combine
Speaker 2: that with a clip function in the fragment shader to
Speaker 2: make parts dissolve, and you get a convincing three D
Speaker 2: fireball effect without complex fluid simulations.
Speaker 1: Incredible control. Okay, beyond surface shaders, there are vertex and
Speaker 1: fragment shaders. These give even more control they do.
Speaker 2: Surface shators are actually a higher level abstraction that Unity provides,
Speaker 2: making common tasks easier. Under the hood, they get compiled
Speaker 2: down into lower level vertex and fragment shaders. Anyway, writing
Speaker 2: vertex and fragment shaders directly gives you complete control over
Speaker 2: both stages.
Speaker 1: Vertext processes geometry, Fragment processes.
Speaker 2: Pixels almost it processes fragments, which are potential pixels. A
Speaker 2: fragment has color, depth, position, etc. Before potentially gets written
Speaker 2: to the screen. But yet, think of the fragment shader
Speaker 2: as running for every pixel being rendered for that object.
Speaker 1: And this is where the grab pass comes in. That
Speaker 1: sounds powerful, It's.
Speaker 2: Very powerful for screen effects. A grab pass is a
Speaker 2: special command you put in your shader. It tells Unity,
Speaker 2: before you draw this object, grab whatever has already been drawn.
Speaker 2: To the screen in this area and put it into
Speaker 2: a texture for me.
Speaker 1: So it gets a snapshot of the background.
Speaker 2: Exactly, usually into a texture named grab texture. Now in
Speaker 2: your fragment shader for the current object, say a piece
Speaker 2: of glass, you can read from that grab texture and
Speaker 2: distort it precisely. You can sample the grab texture using
Speaker 2: modified UV coordinates. For glass, you might offset the uvs
Speaker 2: based on a normal map to simulate refraction. For water,
Speaker 2: you might use an animated noise texture to make the
Speaker 2: UV's wiggle, creating that shimmering distortion effect. It makes the
Speaker 2: object look like it's realistically interacting with the scene behind it.
Speaker 1: That's how you get those really convincing glass or heat
Speaker 1: haze effects.
Speaker 2: Yep. Grab pass is the key.
Speaker 1: Okay, amazing visuals, but we need performance, especially on mobile.
Speaker 1: How do you optimize shaders make them cheaper?
Speaker 2: Several ways. A big one is data precision. GPUs can
Speaker 2: work with different levels of floating point precision. Full float
Speaker 2: thirty two bit is most precise, but slowest. Half sixteen
Speaker 2: bit is less precise, but faster, often perfectly fined for colors,
Speaker 2: texture coordinates, maybe even normals fixed. Often eleven bit is
Speaker 2: even less precise, but the fastest good for simple color
Speaker 2: calculations are things that don't need high accuracy.
Speaker 1: So using smaller variable types saves time and memory definitely.
Speaker 2: Another trick is the hashtag pragma surface no a ford
Speaker 2: Ad directive. Normally Unity might try to calculate lighting for
Speaker 2: multiple lights hitting an object in the forward rendering path,
Speaker 2: adding complexity. No forward DAD tells Unity only calculate the
Speaker 2: brightest directional light per pixel. Handle all other lights more cheaply,
Speaker 2: maybe pervertex. Big performance win in scenes with many lights.
Speaker 1: Good tip any others.
Speaker 2: Sharing texture coordinates uves if multiple textures on your material
Speaker 2: use the same mapping, reducing the number of texture lookups
Speaker 2: overall using those texture packing techniques you talked about. It's
Speaker 2: often about reducing memory, bandwidth and calculation complexity.
Speaker 1: With all these shaders potentially running, how do you figure
Speaker 1: out which one is causing a slow down if your
Speaker 1: game starts lagging?
Speaker 2: AH. The profiler Unity's built in profiler c TROL plus
Speaker 2: seven or CMD plus seven on Mac is your best
Speaker 2: friend here?
Speaker 1: What does it show you?
Speaker 2: Everything? It shows you frame by frame, what your CPU
Speaker 2: and GPU are spending time on. You can see rendering
Speaker 2: stats like draw calls, how many separate things are being
Speaker 2: drawn triangle counts, and crucially, how much time is being
Speaker 2: spent rendering different objects and executing their shaders.
Speaker 1: So you can spot the expensive ones exactly.
Speaker 2: You can pause the game, scrub through the timeline, find
Speaker 2: a performance spike, and drill down. The profiler will often
Speaker 2: list rendering tasks and you can see which materials and
Speaker 2: therefore which shaders are taking up the most GPU time.
Speaker 2: It's essential for optimization.
Speaker 1: Okay, essential tool. Now what if you want to change
Speaker 1: the look of the entire game, like add a film
Speaker 1: grain effect or adjust overall contrast without editing hundreds of materials.
Speaker 2: That's where screen effects or post processing effects are used.
Speaker 2: They're incredibly powerful for applying a final artistic touch to
Speaker 2: the whole scene.
Speaker 1: How do they work? Do they use? Grab pass?
Speaker 2: Conceptually similar, but usually more optimized. The typical flow is
Speaker 2: Unity renders your entire normally. Instead of drawing it directly
Speaker 2: to the screen, it draws it into an off screen
Speaker 2: buffer called a render texture.
Speaker 1: Like an image of the final frame exactly.
Speaker 2: Then a special camera with a post processing shader attached
Speaker 2: simply draws a full screen quad a plat rectangle using
Speaker 2: that render texture as its input. The shader on this
Speaker 2: quad can then modify every single pixel of the final
Speaker 2: image before it's shown to you.
Speaker 1: Ah, so it's like applying a Photoshop filter to the
Speaker 1: whole game image.
Speaker 2: That's a perfect analogy. You can do brightness, saturation, contrast
Speaker 2: adjustments using formulas involving luminance. You can tint the image,
Speaker 2: apply Vignett's film grain distortions. Anything you can code in
Speaker 2: a shader you can apply to the entire screen.
Speaker 1: Can you blend images to like overlaying textures.
Speaker 2: Yep. You can sample other textures in your post processing
Speaker 2: shader and blend them with the scenes render texture using
Speaker 2: standard blend modes. Multiply for darkening, ad or screen for brightening,
Speaker 2: overlay for complex contrast. Tons of possibilities for achieving specific
Speaker 2: moods and stuff.
Speaker 1: So these screen effects are huge for immersion and cinematic feel.
Speaker 1: What are some classic examples?
Speaker 2: Oh loads, an old movie effect is great when you
Speaker 2: combine several things, maybe a CPA tone filter to make
Speaker 2: it brownish, a vignette to darken the corners, maybe some
Speaker 2: noise or film grain, and then overlay animated dust and
Speaker 2: scratches textures using time since time perhaps and random offsets
Speaker 2: to make them flicker and shift instantly. Gives that vintage vibe.
Speaker 1: Yeah, I can picture that. What about something like night vision?
Speaker 2: Another classic usually involves tinting the whole screen green, maybe
Speaker 2: boosting brightness or contrast in a nonlinear way, adding scan lines,
Speaker 2: thin horizontal dark lines, some static noise, maybe barel distortion
Speaker 2: like looking through a lens, and perhaps limiting the color palette.
Speaker 2: Put it all together and you get that familiar military
Speaker 2: or sci fi night vision look. These effects really sell
Speaker 2: the feeling of looking through a specific device or being
Speaker 2: in a particular state.
Speaker 1: Totally changes the experience. Okay, we're getting into advanced territory
Speaker 1: for developers writing lots of shaders. Is there a way
Speaker 1: to make things more modular reusable?
Speaker 2: Get? Yes, definitely. Unity uses cg include files dot CGC
Speaker 2: extensively itself, and you can create your own.
Speaker 1: Cg include like header files and c plus plus.
Speaker 2: Exactly like that. You put common functions, maybe your custom
Speaker 2: lighting calculations, helper functions for noise, complex math routines into
Speaker 2: a dot c gene file. Then in your main shader
Speaker 2: files you just hashtag include that file.
Speaker 1: And you can reuse that code across many shaders YEP.
Speaker 2: It keeps your main shader files cleaner, easier read, and
Speaker 2: makes maintenance way simpler. If you need to fix a
Speaker 2: bug or improve a function in your include file, you
Speaker 2: fix it once and all the shaders using it benefit.
Speaker 2: It's standard practice for any non trivial shader development.
Speaker 1: Smart Now, for something really complex, visually realistic fur or grass,
Speaker 1: how is that usually done? It seems impossible with just textures.
Speaker 2: It's tricky. One well known technique mentioned in the book
Speaker 2: is Lenk Eel's concentric fur shell technique.
Speaker 1: Technique sounds layered.
Speaker 2: It is, instead of trying to draw millions of individual hairs,
Speaker 2: which would destroy performance, you draw the base model multiple times,
Speaker 2: slightly enlarged each time.
Speaker 1: The same model just scaled up a bit.
Speaker 2: Yeah, usually pushed out along the vertex normals. Each shell
Speaker 2: or layer uses a special testure that has transparency, often
Speaker 2: combined with noise to simulate clumps of hair. The outermost
Speaker 2: shell is the most transparent, the inner one's less.
Speaker 1: So, so the layers build up to look like.
Speaker 2: Dense fur exactly when viewed together. These multiple semi transparent
Speaker 2: layers create the illusion of volume and density. You can
Speaker 2: even incorporate things like gravity, making the hairs droop slightly,
Speaker 2: or view direction effects. It's quite clever, but drawing the
Speaker 2: model multiple times can be expensive, so it needs careful tuning.
Speaker 2: Works for grass too, or other fuzzy surfaces.
Speaker 1: Fascinating technique. Okay, one last advanced topic using a Raisin shaders.
Speaker 1: The book mentions heat maps. Can you actually pass array
Speaker 1: data from C sharp to a shader easily?
Speaker 2: Directly? Passing a C sharp array with a single function
Speaker 2: call can be a bit awkward or limited in some
Speaker 2: Unity versions pipelines, though there are ways, like compute buffers.
Speaker 2: Now often you might pass array data element by element
Speaker 2: using multiple set float or set vector calls, or encode
Speaker 2: the data into a texture. But once the data is
Speaker 2: in the shader, seashee droop itself can work with a
Speaker 2: rays declared within the shader code.
Speaker 1: So for a heat map, how would that work?
Speaker 2: Imagine you want to show hot spots on a terrain map.
Speaker 2: You could pass the position and intensity the heat of
Speaker 2: several hot spots to the shader. Let's say you pass
Speaker 2: ten hot spot positions and ten intensity values inside the
Speaker 2: fragment shader for every pixel on the terrain, you would
Speaker 2: loop through that array of ten hot spots. For each
Speaker 2: hotspot you calculate its distance to the current pixel and
Speaker 2: figure out how much heat it contributes. Based on that
Speaker 2: distance and its intensity.
Speaker 1: Summing up the heat from all nearby.
Speaker 2: Hotspots exactly, you accumulate the total heat value for that pixel.
Speaker 2: Then you use that final heat value to look up
Speaker 2: a color on a gradient texture, a ramp map, maybe
Speaker 2: going from blue cold to red.
Speaker 1: Hot, and that colors the terrain pixel.
Speaker 2: Yep, it creates a visual overlay showing the heat distribution.
Speaker 2: The main challenge here, as the book points out, is performance.
Speaker 2: Looping through say fifty or one hundred points for every
Speaker 2: single pixel on the screen can get very slow, very quickly,
Speaker 2: so it requires careful optimization or limiting the number of
Speaker 2: influential points.
Speaker 1: Per pixel right That per pixel cost adds.
Speaker 2: Up fast, hugely fast.
Speaker 1: Wow, what a journey. We've really covered a lot from
Speaker 1: the absolute basics of what a shader even is through textures, lighting,
Speaker 1: the PBR revolution, deforming geometry with vertex shaders, screen wide
Speaker 1: effects optimization. It's incredibly deep, it really is.
Speaker 2: We've seen how shads are. This amazing blend of technical
Speaker 2: programming and artistry. They give developers the tools to define
Speaker 2: virtually any look imaginable, from hyperrealism to completely stylized visuals.
Speaker 1: And hopefully you listening now have a much deeper appreciation
Speaker 1: for what's going on under the hood. When you see
Speaker 1: those incredible visuals and games, you know how they craft
Speaker 1: that perfect metal sheen, or the look of rough stone,
Speaker 1: or even that stylized old film effect.
Speaker 2: It's a powerful toolkit enabling so much of the visual,
Speaker 2: storytelling and atmosphere we experience.
Speaker 1: So here's a final thought for you. Next time you're
Speaker 1: playing game, really look at the surfaces. Try to guess
Speaker 1: what's going on. Can you spot the telltale signs of
Speaker 1: normal mapping adding detail. Can you see how the speculator
Speaker 1: highlights change as you move? Could that cool water distortion
Speaker 1: be a grab pass? Is that enemy dissolving using a
Speaker 1: clip function driven by noise?
Speaker 2: Yes? Start dissecting the visuals and maybe even think what
Speaker 2: kind of cool effects could you imagine creating. Now knowing
Speaker 2: how these pieces
Speaker 1: Fit together, the possibilities with shaders really do feel limitless.