@cuenta007 and as a pyro it's more fun to fight spies with it. Praying and spraying till you catch one by accident is funny but like random shits after a while I just feel bad about it and also want a bit more of a challenge than holding m1 and doing some housekeeping
LED's a mapper, though? not only are they not normal, but they logically would study maps to know how to make theirs better and to understand what's going on, no?
@@zzyxxyzz5442 it's just a joke that plays on how it sounds out of context. it sounds like some random person fascinated by walls, which most people very much aren't and could also imply long periods of time staring at walls, which would be even more strange
"I was studying walls." -LED and his fans looking for the pressable brick in the wall leading to a secret passage to a secretsociety (we are schizophrenic.)
@@notnullptryeah the video went on for so long, like I know all this already I just wanna know what the ssbumpmap does man. Probably good if you don't know about any of the other stuff beforehand tho
Fascinating topic, but there are two things I'd note about this video: - Explanation of bump maps here is incorrect, bright areas on the bump map don't reflect more light back to you per-se, and you can see that in the video demonstration too. Bump maps have the same meaning as height maps, bright means higher "ground", dark means lower. And for bump-mapped lighting you don't really care how high or low the texel is, you just care about the slope. Flat white area will reflect the same amount of light in the same way as a flat black area. What you need to do is to sample the neighborhood too and compute those slopes, and get the normal, and then you light the pixel from there. That's why bump maps are pretty much completely phased out, normal maps just give that end result directly from a single sample. You can technically save some memory since bump map is a 1D value (so you can use just a single channel), and normal vector is 3D (so you have to use three channels, i.e. RGB (or possibly two with more math)), but it isn't worth it these days, we can afford normal maps memory-wise and it's just simpler and quicker overall to deal with them. - Not completely wrong, but the file size comparison near the end is not the most relevant one. When they're saying their technique isn't requiring more memory, they mostly mean they're not using additional textures or additional channels, it's still RGB, so in GPU memory, where they'd either be uncompressed or compressed with fixed bitrate, they would be of exactly the same size. PNG isn't a GPU format, and is very content-sensitive. There is something to be said about hard drive memory too, but that's usually not the focal point in such graphics papers.
same i was like whar? when i heard the bump explanation and woah you really went into details regarding bump maps, nice i understand this is a fairly short video but just saying "represents height" sounds both accurate and intuitive
I kinda get what your saying about bumpmaps, rather than reduce the light that bounces off a texture, it skews the light away from the direction of the normal based on the brightness value? And yeah, it's less to do with normals being full RBG and more to do with normals requiring more math to calculate.
@@Nilon241 In the end, lighting calculation is the same in both cases. You'll use the surface normal, and that can be the "real" polygonal one, or one modified in some way by textures and algorithms to produce the illusion of a "rough", more detailed surface. And that modified one will end up being the ~same for both the bump maps and normal maps. You're interested in the angle, and you can't know the angle with just the height info at a single point, you need to sample the neighboring points too, see if they are taller or shorter, in which direction, to figure out which way the surface is tilted. With normal maps, that normal/angle is directly what's written in the texture, you just read once per pixel and you're good to go. If A + B = C, with bump maps you have read A and read B, and then add them up yourself. With normal maps, you just read C, it's already there just the way you need it. TLDR: They're both about "skewing the light", difference is just how you get to that skewing angle. One takes less memory, but requires more steps to reach that result, the other takes more memory but gives you ready-made result.
You can actually quantize normal map by loosing precision you would unlikely ever notice but it's not worth it due to how much vram modern gpus have and it adds a couple extra instructions.
vtf textures aren't just jpegs like. Apart of texture images for each mip level, they contain reflectance value and various flags that indicate how Source engine must interpret them. vtf can also have different compression method.
1:50 Source 1 uses VTFs while Source 2 uses vtex. Its the same thing, its just that Source 2 gives you an editor to make these automatically rather than manually. Source 1 has a community tool called VMTEditor which is really useful for creating materials and I've never written a vmt by hand in ages.
It's nowhere close to the same thing. Source 2's material editor allows you to preview different shader types with a super helpful and intuitive UI that (I didn't mention this) supports .tga file formats, which is convenient for making quick edits. There are also various sliders and check boxes that allow you to make real-time adjustments to the texture maps.
All textures in Source 1 and Source 2 have to be compiled into a new format for the engine to use them. Both vtf and vtex contain some meta data + the actual image, usually with some form of DXT compression applied. He is saying that vtf and vtex are basically the same because vtex does for source 2 what vtf did for source 1. The editor thing doesn't really relate to this. For source there simply wasn't a public official material editor that did the conversion from image + meta data to vtf and for source 2 there is. However the community made their own tools like VTF editor and VMT editor that would happily convert .pngs, .tgas etc to vtf for you. Being able to use those file formats isn't special to source 2 nor does either engine work with non valve texture files. Its just now we have a nice material editor built right into the public tools ;-)
Blend modulate texture is used to indicate how to alter texture transition on map displacements. This allows keeping small details between transition, like for ex. rocks between sand and stone.
Fun fact regarding 9:25 ; On Rotunda, the blend texture used for the oil shader in mid caused a ton of issues just before release due to the fact that the oil was shiny, had a $blendmodulate, and used SSbump. This wasnt an issue for most players, but DX8 and players playing without reflections enabled broke the shader completely. We had to make some fallback materials, brand new normal maps, and a lot of slamming our heads against a wall to fix it just before release.
Honestly, I've always hated those brick walls because you can clearly see the DXT compression artifacts in the bumpmap. I don't know why they did that; most normal maps even in Source games are uncompressed, for that exact reason.
I remember messing around with ssbumps when I was working as a level designer for Pirates, Vikings and Knights 2 source mod. They worked well on organic textures like cliff, sand and weathered down bricks, but wouldn't work on a flat texture that had well defined elements on it, like a clean metal surface with rivets for example. In this case the self shadowing would only look good if the light came from one of the three specific directions that align with the direction of the shadows in ssbump texture. Otherwise it would just make a messy blend between the main shadow positions resulting in an extremely unnatural surface.
That's not what a bump map is. A bump map is just a height map as you later said. It's a texture where white pixels represent high points and black pixels represent low points and the game engine internally generates a normal map based off this information. The white and black pixels do not represent pointing "towards" or "away" from anything. It's just height information. The way the game generates normals from this height info is as follows; if you have a single while pixel on an otherwise black height map, the game will see that white pixel as a hill and on the generated normal map it will generate normals pointing north on the pixel north of the white dot, south on the pixel south of the white dot, east to the east, and west to the west, making it so the surface where that white dot would be would appear to have a single small bump on it. If you use an all black height map or an all white bump map they will both look identically lit and perfectly flat. This is because the game doesn't care about the objective colors of the pixels on these maps. It just cares about the difference between neighboring pixels and assumes a slope between high and low points.. Edit: To be honest your description of what a bump map is and this video you linked both seem unclear to me so I actually don't know if we're talking about the same thing or not. Here is what I understand a bump map to be: th-cam.com/video/nfaOP27GZ5U/w-d-xo.html You were talking about skewing normals towards and away from "you" where I assume "you" is the camera and I don't understand bump maps to be doing this. “This is done by skewing the normals towards and away from you” I'm not really sure what that would mean. If normals are being skewed away from the camera, what direction are they being skewed in? Maybe we're talking about completely different effects, I'm not sure. You'll have to watch my short video and tell me cause I could just be wrong. I don't know how bump maps work in source or if they're different from other engines. Also I can't reply for some reason.
It is what a bump map is, how do you think "height" works in the technical sense? By skewing surface normals that influence the way light reflects back to you. Watch here: th-cam.com/video/D7uK4WWW-Rk/w-d-xo.htmlsi=2iaHwhKCnhqCmtVy
The size being the same is probably because they can use the same amount of channels and be the same size as normal maps. When an image is compressed with DXT it will always be the same size (based on channel count and pow2 texture size) in compressed form (ignoring additional compression such as LZMA)
When the document referred to "texture storage space" it was likely referring to its data in VRAM, which in the case of Source is the DXT format due to its use of DirectX. Regardless of the actual texture *file*, the GPU needs to store that data in a way that it can use, and this is where storage really matters. If you make a file that's 4096x4096 but all one color and save it as a PNG, that file is going to be way smaller than the memory usage because in PNG we can afford to have some amount of time to load the image out of a compressed state, whereas in a GPU it needs to be ready in less than a millisecond to render potentially dozens of materials at once each using more than one texture. This storage technique is also why textures have a resolution that is a power of two (64, 128, 256, 512, ...)
SSbumpmaps are also used a lot in L4D and L4D2, it looks good when lit with a flashlight, they are good for nature stuff like terrain, rocks and the like, not so good for small details or repetitive patters, the main problem they have is that instead of having light information in 4 directions like normal normal maps they have 3 using the rgb values, and they divide it using the 0 to 128 for the shadows, so half the range of detail, it also makes the texture look darker and the shadows also can overlap on parts where you need detail if illuminated by other angle.
Little correction about bump maps: they represent the height of a pixel relative to the surface of the mesh. Pure gray is 0, white is out and black is in. The program then interpret that data to show how light and shadows interact with the object
"Height" means nothing without the context of surface normals. You can't just tell the engine "this is higher than that" using a value between 0 and 1. Bump maps work by perturbing the surface normals by a factor between 0 and 1. That's the most important part of the entire explanation.
@@LEDs usually software has a way to say "in this case 1 (white) equals 1 meter away from the surface and 0 (black) 1 meter inside the surface", it could be called something like "distance" or "strenght" or "scale" or something similar depending on the software. The surface normal thing is derived from that but it's not directly controlled by the bump map. Normal maps on the other end directly tell the software in what direction should the surface normal be pointed for that pixel
And for those who want to know, the way Normal Maps work are that the Colour Values represent with direction that Normal is facing. Red is usually X, Blue is usually Z and Green is usually Y, with the Pink being the Middle ground of the Normals Facing Directly Outwards..
Honestly, ssbump in that case genuinely just Is better than Normal maps, purely because storing AO inside a texture and it take up no less than normal maps is genuinely amazing. A Shame modern mappers just kinda fallback on basic Normals.
"we typically use things ike PNGs or JPG" Well, no. That's only input format to engine. (And JPG shouldn't be EVER used in gamedev, and using JPG should be treated as crime.) Game engines internally use rather GPU compatible compression format like DDS. VAT and Source2's VTEX are also DDS alike format.
Valve always pushed, created and generally developed new technology. This is one of the (if not the) company you want to go, when you look for a genuin creative think tank, who makes the bleeding edge of technology and actually turns it into a healthy, usefull and just good product for people.
This is one of the greatest things about TH-cam (ignoring all the terrible stuff about TH-cam), which is finding hyper specific and detailed breakdowns on essentially any topic that could hold any amount of examination or objective critique. Has to be my favorite genre of creator.
The bump map explanation was weird, true that it affects normals but bright or dark pixels don't inherently make those areas have more or less light. Just saying bump maps store height information would've made more sense, sounds fairly intuitive to me. Overall good video though, I'd like to hear more details but then it wouldn't be 10 minutes, so fair. Also, the example of a bump map in blender looks right, but am I going insane or is the grayscale brick texture is actually an ambient occlusion map instead of a bump map...
I do a lot of custom texture work for tf2maps, and generally SSbumpmaps require more authoring and custom work to get 'looking good' than just a normal map, so they arent really used that often. Hell, even normal maps themselves tend to not be used as much in tf2 due to unintended overdetailing, instead relying more on baked in detail like seams and cracks.
I believe the ssbump was discontinued due to the fact how pbr works with AO, and secondly using ssbump the engine had to calculate the cross product of X and Y that is the RB channel, which is not that huge but again it saves gpu an extra step Sorry for bombarding comments on your videos your videos are interesting :)
The normal map being more intense than the ssbump is more likely to be a result of artistic intent rather than due to the formats. In all the 3D software I've worked with, there has been some way to multiply the normal intensity which allows the artist to fine tune the look of the material, and by having the default normal intensity be really intense, it allows for less information to be lost when multiplying. Also this is the first time I've heard someone call a height map a bump map, though I also don't use hammer.
"I was studying walls the other day" Valve has abandoned this game so long ago hour long videos about the shortstop and.. this is our standard of content.
Quick correction! SSBump is unused in Source 2 not because of PBR, but because it uses "Ambient Highlight Direction encoding" instead of "Radiosity Normal Mapping". The tech is difficult to explain, but you can think of it as two distinct techniques that allow lightmaps and normal maps to "work" together.
1:07 wait what? I thought vertexlit generic only used the model's root vertex for lighting, seeing as baked lights cause the whole model to either fall into shadow or be lit.
Mapper is free to choose prop lighting either from arbitrary light origin (model origin or own pointed location) or use per vertex lighting. The second option doesn't work for models with bump map materials. And there's shadow texture option, but it's ass as it uses model's UV and requires the UV not overlap with each other, and increased bsp size.
@@LEDs huh. I recently watched that and didn't notice it. Can you give me an idea of where this is mentioned in the video? I was thinking maybe my understanding of model lighting only applied to dynamic objects like players, not props baked into the map.
The usual children and manchildren of the tf2 community. Just like in game, they try so hard to be funny 24/7 while completely failing at it. Absolutely love how a whole quarter of the comments are the same exact lame ass joke.
Interesting... There is another way to do this, materials from Quixel Megascans have Roughness, Occlusion and Displacement on one texture each occupying its separate color channel
Those are for PBR materials which are not supported in Source 1. You can only have "basetexture" and "bump" maps. There is no option for roughness, metalic, ambient occlusion, etc. and especially not displacement (not even Source 2 fully embraces displacement maps). There are some extra ones for adding details or blending two textures together, but that's a separate thing.
I’m actually curious how to set up using normal textures in tf2 since I use a lot of custom textures from other games when making maps and a lot of the time they come with normals
9:15 Small thing, but the size of the PNG files does not matter due to source using DXT/BC/S3 compression for its textures (most of the time), why this matters is because of the format being a fixed size, meaning even a single color across a 512x512 area will be identical to any other 512x512 texture of the same format, I'd explain but I'd end up butchering the explaination sooo en.wikipedia.org/wiki/S3_Texture_Compression TLDR: no matter the PNG size, they would be identical down to the last bit in actual size in the game files and memory usage. brickwall001_height-ssbump.vtf is actually 682.91kb in size, it is stored as a DXT1 texture with mipmaps, a DXT5 image of the same size would be 1.33mb, without mipmaps the DTX1 image is 512mb... god this comment feels 🤓
Yeah, I saw that the vtfs were all the same size, so I didn’t know what Chris meant in his paper when he he mentioned file size. That’s why I looked at the PNG files
If it is - then it's an example of smart asset recycling on Valve's part (reuse an already owned texture by touching it up for a new game with a different art direction, instead of making a new similar one from ground up), as well as a good illustration for the process of making textures for TF2 ("make a set of photos for realistic texture and its bump maps --> produce realistic bump maps from them --> paint over the 'flat color realistic texture' to make it look hand drawn and apply bump maps from step 2")
I'll do you one better: that one white wall in the courtyard in 2fort? With the vertical ribbing? That's a HL2 texture that just got run through a Photoshop filter.
I invented that system, nice to see people noticed!
YOU DID??? yoooo
So that's why TF2 walls look so good.
Wait somebody thinks tf2 IS normal?
Insane
Somehow yes
How tf explain@@DustEatingMan
@@vhammermdl built different or alien
*tf2 maps*
9:08 there's actually a single dynamic light source in TF2 (that I know of)! The Dragon's Fury fireball
The Dragon's Fury is very sexy and cool
@@vinnyandlin8510 as a spy
Yes
@cuenta007 and as a pyro it's more fun to fight spies with it. Praying and spraying till you catch one by accident is funny but like random shits after a while I just feel bad about it and also want a bit more of a challenge than holding m1 and doing some housekeeping
@@vinnyandlin8510 tf is a random shit
@@cuenta007 Random crit
That's why the walls look so bumpy I wanna eat them
you know you want to eat the dustbowl crunchy dirt
Same
"I was studying walls"
Yea that's a normal person thing to say.
LED's a mapper, though? not only are they not normal, but they logically would study maps to know how to make theirs better and to understand what's going on, no?
@@zzyxxyzz5442 its not that deep
architects disagree
"I watched a video about someone studying walls" isn't exactly a normal person thing to say, either.
@@zzyxxyzz5442 it's just a joke that plays on how it sounds out of context. it sounds like some random person fascinated by walls, which most people very much aren't and could also imply long periods of time staring at walls, which would be even more strange
"I was studying walls."
-LED and his fans looking for the pressable brick in the wall leading to a secret passage to a secretsociety (we are schizophrenic.)
It leads to Team Fortress 3
@@TungstenCubeGaming SOURCE 2!?!?!?!
Me rubbing my face on every wall to find out if there isn't a secret room with machine gun behind it
ssbump is in essence pre-baked shadows information, not a real bump map. It was abandoned because it only works properly on static geometry.
thanks for summarizing. dude in the video wouldn't stop YAPPING when it can be summarized in like a paragraph
@@notnullptryeah the video went on for so long, like I know all this already I just wanna know what the ssbumpmap does man.
Probably good if you don't know about any of the other stuff beforehand tho
You can actually use these with real-time lighting, but i've only ever seen that done with sun-shadows since they're pretty global.
Thanks bro, I know the community is dead after 7 years without updates but 10 minutes about a premade bump map is NOT a good use of my time
@@notnullptr 10 minuts mark needs to be done for money lol
Fascinating topic, but there are two things I'd note about this video:
- Explanation of bump maps here is incorrect, bright areas on the bump map don't reflect more light back to you per-se, and you can see that in the video demonstration too. Bump maps have the same meaning as height maps, bright means higher "ground", dark means lower. And for bump-mapped lighting you don't really care how high or low the texel is, you just care about the slope. Flat white area will reflect the same amount of light in the same way as a flat black area. What you need to do is to sample the neighborhood too and compute those slopes, and get the normal, and then you light the pixel from there. That's why bump maps are pretty much completely phased out, normal maps just give that end result directly from a single sample. You can technically save some memory since bump map is a 1D value (so you can use just a single channel), and normal vector is 3D (so you have to use three channels, i.e. RGB (or possibly two with more math)), but it isn't worth it these days, we can afford normal maps memory-wise and it's just simpler and quicker overall to deal with them.
- Not completely wrong, but the file size comparison near the end is not the most relevant one. When they're saying their technique isn't requiring more memory, they mostly mean they're not using additional textures or additional channels, it's still RGB, so in GPU memory, where they'd either be uncompressed or compressed with fixed bitrate, they would be of exactly the same size. PNG isn't a GPU format, and is very content-sensitive. There is something to be said about hard drive memory too, but that's usually not the focal point in such graphics papers.
same i was like whar? when i heard the bump explanation
and woah you really went into details regarding bump maps, nice
i understand this is a fairly short video but just saying "represents height" sounds both accurate and intuitive
I kinda get what your saying about bumpmaps, rather than reduce the light that bounces off a texture, it skews the light away from the direction of the normal based on the brightness value?
And yeah, it's less to do with normals being full RBG and more to do with normals requiring more math to calculate.
@@Nilon241 In the end, lighting calculation is the same in both cases. You'll use the surface normal, and that can be the "real" polygonal one, or one modified in some way by textures and algorithms to produce the illusion of a "rough", more detailed surface. And that modified one will end up being the ~same for both the bump maps and normal maps. You're interested in the angle, and you can't know the angle with just the height info at a single point, you need to sample the neighboring points too, see if they are taller or shorter, in which direction, to figure out which way the surface is tilted. With normal maps, that normal/angle is directly what's written in the texture, you just read once per pixel and you're good to go. If A + B = C, with bump maps you have read A and read B, and then add them up yourself. With normal maps, you just read C, it's already there just the way you need it.
TLDR: They're both about "skewing the light", difference is just how you get to that skewing angle. One takes less memory, but requires more steps to reach that result, the other takes more memory but gives you ready-made result.
Actually, (tangent space) bump maps are pretty much 2D because scaling the tangent Z is quite weird
You can actually quantize normal map by loosing precision you would unlikely ever notice but it's not worth it due to how much vram modern gpus have and it adds a couple extra instructions.
Don’t worry! I’ll fix it!
*proceeds to 3D model every brick and detail in precise polygons*
And it will run in 60 flames per second
@@_GhostMinerhey it worked for ID software
tf2 fans are starting to become insane considering how much they've toughed it out without an update for years and it just began to show. worrying.
we have reached pinacle tf2 content, walls are now the most interesting thing to talk about. Great video as always btw
vtf textures aren't just jpegs like. Apart of texture images for each mip level, they contain reflectance value and various flags that indicate how Source engine must interpret them. vtf can also have different compression method.
Indeed it it strange, unique even, unusual to some
This is definitely a vintage technique
@@RedGoldDolfin-ez9iy and their report was quite genuine
I am genuinely astonished
collector
Even Valve is surprised
“TF2 isn’t normal”
We never fucking were and I’m proud of it
1:50 Source 1 uses VTFs while Source 2 uses vtex. Its the same thing, its just that Source 2 gives you an editor to make these automatically rather than manually. Source 1 has a community tool called VMTEditor which is really useful for creating materials and I've never written a vmt by hand in ages.
It's nowhere close to the same thing. Source 2's material editor allows you to preview different shader types with a super helpful and intuitive UI that (I didn't mention this) supports .tga file formats, which is convenient for making quick edits. There are also various sliders and check boxes that allow you to make real-time adjustments to the texture maps.
All textures in Source 1 and Source 2 have to be compiled into a new format for the engine to use them. Both vtf and vtex contain some meta data + the actual image, usually with some form of DXT compression applied. He is saying that vtf and vtex are basically the same because vtex does for source 2 what vtf did for source 1.
The editor thing doesn't really relate to this. For source there simply wasn't a public official material editor that did the conversion from image + meta data to vtf and for source 2 there is. However the community made their own tools like VTF editor and VMT editor that would happily convert .pngs, .tgas etc to vtf for you.
Being able to use those file formats isn't special to source 2 nor does either engine work with non valve texture files. Its just now we have a nice material editor built right into the public tools ;-)
@@LEDs VTFEdit uses TGA
@@Apple-vk3fi If you save as instead of export, you can save as vttf
TF2 players are so starved for content that they've started studying walls.
I'm so glad you finally got around to talking about that damn wall, LED
np
Blend modulate texture is used to indicate how to alter texture transition on map displacements. This allows keeping small details between transition, like for ex. rocks between sand and stone.
We are so dried of major updates now we are discussing brick walls.
Truly a mental asylum of all times.
Fun fact regarding 9:25 ; On Rotunda, the blend texture used for the oil shader in mid caused a ton of issues just before release due to the fact that the oil was shiny, had a $blendmodulate, and used SSbump. This wasnt an issue for most players, but DX8 and players playing without reflections enabled broke the shader completely. We had to make some fallback materials, brand new normal maps, and a lot of slamming our heads against a wall to fix it just before release.
Wow
“TF2 is not normal”
*Well I gathered as much*
Honestly, I've always hated those brick walls because you can clearly see the DXT compression artifacts in the bumpmap. I don't know why they did that; most normal maps even in Source games are uncompressed, for that exact reason.
Hampter
I remember messing around with ssbumps when I was working as a level designer for Pirates, Vikings and Knights 2 source mod. They worked well on organic textures like cliff, sand and weathered down bricks, but wouldn't work on a flat texture that had well defined elements on it, like a clean metal surface with rivets for example. In this case the self shadowing would only look good if the light came from one of the three specific directions that align with the direction of the shadows in ssbump texture. Otherwise it would just make a messy blend between the main shadow positions resulting in an extremely unnatural surface.
That's not what a bump map is. A bump map is just a height map as you later said. It's a texture where white pixels represent high points and black pixels represent low points and the game engine internally generates a normal map based off this information. The white and black pixels do not represent pointing "towards" or "away" from anything. It's just height information.
The way the game generates normals from this height info is as follows; if you have a single while pixel on an otherwise black height map, the game will see that white pixel as a hill and on the generated normal map it will generate normals pointing north on the pixel north of the white dot, south on the pixel south of the white dot, east to the east, and west to the west, making it so the surface where that white dot would be would appear to have a single small bump on it.
If you use an all black height map or an all white bump map they will both look identically lit and perfectly flat. This is because the game doesn't care about the objective colors of the pixels on these maps. It just cares about the difference between neighboring pixels and assumes a slope between high and low points..
Edit: To be honest your description of what a bump map is and this video you linked both seem unclear to me so I actually don't know if we're talking about the same thing or not. Here is what I understand a bump map to be: th-cam.com/video/nfaOP27GZ5U/w-d-xo.html
You were talking about skewing normals towards and away from "you" where I assume "you" is the camera and I don't understand bump maps to be doing this.
“This is done by skewing the normals towards and away from you”
I'm not really sure what that would mean. If normals are being skewed away from the camera, what direction are they being skewed in? Maybe we're talking about completely different effects, I'm not sure. You'll have to watch my short video and tell me cause I could just be wrong. I don't know how bump maps work in source or if they're different from other engines.
Also I can't reply for some reason.
It is what a bump map is, how do you think "height" works in the technical sense? By skewing surface normals that influence the way light reflects back to you. Watch here: th-cam.com/video/D7uK4WWW-Rk/w-d-xo.htmlsi=2iaHwhKCnhqCmtVy
@@LEDsI edited my original comment. I can't seem to send you a reply for some reason. God TH-cam is buggy...
The size being the same is probably because they can use the same amount of channels and be the same size as normal maps. When an image is compressed with DXT it will always be the same size (based on channel count and pow2 texture size) in compressed form (ignoring additional compression such as LZMA)
this is what happens when a fanbase has been starving for years
I remember learning about ssbump layers from scruffy's pikmin model trivia video. You are my second youtuber to touch on the topic :D
Ssbump maps are fantastic, they compute faster and are smaller than having three images for AO, Bump, and Normal maps.
Maybe that’s what Chris meant when he was referring to smaller file size
if you make a map with ssbump textures, add reflections for metals, and make the displacement relief more realistic, then the map will look better
When the document referred to "texture storage space" it was likely referring to its data in VRAM, which in the case of Source is the DXT format due to its use of DirectX. Regardless of the actual texture *file*, the GPU needs to store that data in a way that it can use, and this is where storage really matters. If you make a file that's 4096x4096 but all one color and save it as a PNG, that file is going to be way smaller than the memory usage because in PNG we can afford to have some amount of time to load the image out of a compressed state, whereas in a GPU it needs to be ready in less than a millisecond to render potentially dozens of materials at once each using more than one texture. This storage technique is also why textures have a resolution that is a power of two (64, 128, 256, 512, ...)
One of my favorite TF2 TH-camrs right now :)
I love this mans channel, keep it up!
SSbumpmaps are also used a lot in L4D and L4D2, it looks good when lit with a flashlight, they are good for nature stuff like terrain, rocks and the like, not so good for small details or repetitive patters, the main problem they have is that instead of having light information in 4 directions like normal normal maps they have 3 using the rgb values, and they divide it using the 0 to 128 for the shadows, so half the range of detail, it also makes the texture look darker and the shadows also can overlap on parts where you need detail if illuminated by other angle.
Little correction about bump maps: they represent the height of a pixel relative to the surface of the mesh. Pure gray is 0, white is out and black is in. The program then interpret that data to show how light and shadows interact with the object
"Height" means nothing without the context of surface normals. You can't just tell the engine "this is higher than that" using a value between 0 and 1. Bump maps work by perturbing the surface normals by a factor between 0 and 1. That's the most important part of the entire explanation.
@@LEDs usually software has a way to say "in this case 1 (white) equals 1 meter away from the surface and 0 (black) 1 meter inside the surface", it could be called something like "distance" or "strenght" or "scale" or something similar depending on the software. The surface normal thing is derived from that but it's not directly controlled by the bump map. Normal maps on the other end directly tell the software in what direction should the surface normal be pointed for that pixel
I like walls
Strength of both SSbumps and Normal maps can be adjusted so not only can you make the curvature more pronounced for SSbumps, you can retain the AO.
I was not expecting the topic of this video to be what it was but I'm all for it
Man I was WONDERING if they were normals! Bc I don't remember source games using Normal maps o-o
And for those who want to know, the way Normal Maps work are that the Colour Values represent with direction that Normal is facing. Red is usually X, Blue is usually Z and Green is usually Y, with the Pink being the Middle ground of the Normals Facing Directly Outwards..
Honestly, ssbump in that case genuinely just Is better than Normal maps, purely because storing AO inside a texture and it take up no less than normal maps is genuinely amazing. A Shame modern mappers just kinda fallback on basic Normals.
your bump map example needed to have its colors inverted. for some reason it rendered the colors the opposite height of what they were supposed to be.
Whether it was intentional or not, this title is a fantastic pun.
You know it 😉
"we typically use things ike PNGs or JPG"
Well, no. That's only input format to engine. (And JPG shouldn't be EVER used in gamedev, and using JPG should be treated as crime.)
Game engines internally use rather GPU compatible compression format like DDS. VAT and Source2's VTEX are also DDS alike format.
And by DDS alike i mean literally DDS/DXT with extras like metadata
What no updates does to a community
Tf2 isn't normal and neither are us, the players
Valve always pushed, created and generally developed new technology. This is one of the (if not the) company you want to go, when you look for a genuin creative think tank, who makes the bleeding edge of technology and actually turns it into a healthy, usefull and just good product for people.
last time i had heard of ssbumps was 11 years ago, never understood how they work and forgot about them, now it finally makes sense!
You got bored on tf2 one day that you went out of your way to study the walls?
This is one of the greatest things about TH-cam (ignoring all the terrible stuff about TH-cam), which is finding hyper specific and detailed breakdowns on essentially any topic that could hold any amount of examination or objective critique.
Has to be my favorite genre of creator.
This is a fantastic little documentary on a little known and under appreciated piece of game development industry history. Excellently done!
The bump map explanation was weird, true that it affects normals but bright or dark pixels don't inherently make those areas have more or less light. Just saying bump maps store height information would've made more sense, sounds fairly intuitive to me.
Overall good video though, I'd like to hear more details but then it wouldn't be 10 minutes, so fair.
Also, the example of a bump map in blender looks right, but am I going insane or is the grayscale brick texture is actually an ambient occlusion map instead of a bump map...
I was expecting this video to be about the community and got a really interesting technical explanation instead. You've earned my sub
you know the game needs content when were talking about walls
4:55 hehe “balls”
I can hear javid9x in my mind saying “shut up”
I do a lot of custom texture work for tf2maps, and generally SSbumpmaps require more authoring and custom work to get 'looking good' than just a normal map, so they arent really used that often. Hell, even normal maps themselves tend to not be used as much in tf2 due to unintended overdetailing, instead relying more on baked in detail like seams and cracks.
2:10 i like the sound of that. Has a nice ring to it.
I believe the ssbump was discontinued due to the fact how pbr works with AO, and secondly using ssbump the engine had to calculate the cross product of X and Y that is the RB channel, which is not that huge but again it saves gpu an extra step
Sorry for bombarding comments on your videos your videos are interesting :)
"i was studying walls"
What 6 years of no updates does to a game
I like to think ssbump map just stands for source spaghetti bump map
Read the title, saw the thumbnail and I knew you are gonna talk about textures.
“I discovered something weird”
Yeah some weirdo is staring at a wall, that’s what’s weird
The normal map being more intense than the ssbump is more likely to be a result of artistic intent rather than due to the formats. In all the 3D software I've worked with, there has been some way to multiply the normal intensity which allows the artist to fine tune the look of the material, and by having the default normal intensity be really intense, it allows for less information to be lost when multiplying.
Also this is the first time I've heard someone call a height map a bump map, though I also don't use hammer.
good pun
Took me half the video but I see what you did there with "TF2 isn't *normal*"
"I was studying walls the other day"
Valve has abandoned this game so long ago hour long videos about the shortstop and.. this is our standard of content.
Great video as always. I don't think their is a youtuber who talks about the stuff you do!
Quick correction! SSBump is unused in Source 2 not because of PBR, but because it uses "Ambient Highlight Direction encoding" instead of "Radiosity Normal Mapping".
The tech is difficult to explain, but you can think of it as two distinct techniques that allow lightmaps and normal maps to "work" together.
1:07 wait what? I thought vertexlit generic only used the model's root vertex for lighting, seeing as baked lights cause the whole model to either fall into shadow or be lit.
That’s caused by something else. I talked about it in my video “Everything wrong with Dustbowl”
Mapper is free to choose prop lighting either from arbitrary light origin (model origin or own pointed location) or use per vertex lighting. The second option doesn't work for models with bump map materials. And there's shadow texture option, but it's ass as it uses model's UV and requires the UV not overlap with each other, and increased bsp size.
@@LEDs huh. I recently watched that and didn't notice it. Can you give me an idea of where this is mentioned in the video?
I was thinking maybe my understanding of model lighting only applied to dynamic objects like players, not props baked into the map.
led talked to a brick wall for 10 minutes straight. literally.
“Tf2 isn’t normal”
“Every 60 seconds a minute in Africa passes”
What 7 years without update does to a man.
this game really needs an update dog bro is out here studying the damn walls
You're telling me ssbump doesn't stand for "Super Smash Brothers Ultimate Mario Party"?
they knew what they doing
This is present in Source 2, you can easily create a self shadowing normal, special texture shaders are not a difficult thing to add in Source 2.
It is not.
@@LEDs Custom shaders is absolutely a thing, it's compiled under the material format. You can see it under the material editor page.
No one: what are you studying?
Someone: Math
No one: what are you studying?
LED: w a l l
Whats up with this comment section? Did any of you guys actually watch the video???
The usual children and manchildren of the tf2 community. Just like in game, they try so hard to be funny 24/7 while completely failing at it. Absolutely love how a whole quarter of the comments are the same exact lame ass joke.
Most TF2 players don't have experience with gamedev texturing nor are they mature enough to comment or learn on it
which types of comments are you referring to?
"I was studying TF2's walls the other day,"
Yeah, apparently the players aren't normal either.
valve should sign this man in
The title of this video could be talking about literally anything in the game
This is what happens when a game doesn’t get updated for 7 years. I love this
Interesting... There is another way to do this, materials from Quixel Megascans have Roughness, Occlusion and Displacement on one texture each occupying its separate color channel
Those are for PBR materials which are not supported in Source 1. You can only have "basetexture" and "bump" maps. There is no option for roughness, metalic, ambient occlusion, etc. and especially not displacement (not even Source 2 fully embraces displacement maps). There are some extra ones for adding details or blending two textures together, but that's a separate thing.
Well if this technically partially use normal maps would that mean that tf2 is normal?
It’s semi-normal
I’m actually curious how to set up using normal textures in tf2 since I use a lot of custom textures from other games when making maps and a lot of the time they come with normals
Make a height map. Lighter is higher, darker is lower. Use heightmap to normal converter.
check the valve developer wiki page for VMT's I would assume
There's a tool for creating ssbump maps, haven't used it though: steamcommunity.com/sharedfiles/filedetails/?id=2877119600
I was studying tf2s walls...
aka what 0 meaningful updates does to mf....
yeah i would say it is quite, unusual
"TF2 isn't normal"
The entire game depends on a cow cutout to function
I thought that was a hoax
Wasnt it a coconut?
@@KungFuGangsta the coconut is the hoax
**makes new engine to fix this**
"Man ion wanna do this shit no more"
*Makes brand new engine*
*Doesn't elaborate*
Damn, I really like the SS now !
title of the video: "TF2 isn't Normal"
as if tf2 was normal in the first place (it isn't)
The wall update
9:15 Small thing, but the size of the PNG files does not matter due to source using DXT/BC/S3 compression for its textures (most of the time), why this matters is because of the format being a fixed size, meaning even a single color across a 512x512 area will be identical to any other 512x512 texture of the same format, I'd explain but I'd end up butchering the explaination sooo en.wikipedia.org/wiki/S3_Texture_Compression
TLDR: no matter the PNG size, they would be identical down to the last bit in actual size in the game files and memory usage.
brickwall001_height-ssbump.vtf is actually 682.91kb in size, it is stored as a DXT1 texture with mipmaps, a DXT5 image of the same size would be 1.33mb, without mipmaps the DTX1 image is 512mb... god this comment feels 🤓
Yeah, I saw that the vtfs were all the same size, so I didn’t know what Chris meant in his paper when he he mentioned file size. That’s why I looked at the PNG files
best tf2 videos coming out rn, keep it up
In a game where suicide is the running gag of every joke, what did you expect?
Portal 2 also uses SSBump
That's SUPER interesting!
In accordance to the title I’d like to say No Shit dude.
pff, next you're gonna say that the sky is blue!
🤔
@@LEDsoh no
Wait the tf2 brick texture is a painted on brick texture from half life 2?
If it is - then it's an example of smart asset recycling on Valve's part (reuse an already owned texture by touching it up for a new game with a different art direction, instead of making a new similar one from ground up), as well as a good illustration for the process of making textures for TF2 ("make a set of photos for realistic texture and its bump maps --> produce realistic bump maps from them --> paint over the 'flat color realistic texture' to make it look hand drawn and apply bump maps from step 2")
I'll do you one better: that one white wall in the courtyard in 2fort? With the vertical ribbing? That's a HL2 texture that just got run through a Photoshop filter.
Very informative video! Congrats!