Normal map question
polycounter lvl 11
Hi PC crowd,
I have a question concerning normal maps. I did search before hand on the PC forums, but did not find what I am looking for.
Basically I would like to know if there is a big advantage for using normal maps to replace bump maps. I understand how each are affecting the way light and texture information is displayed/seen.
In other words, can a normal map basically replace what the bump maps can do as well as use normal maps for detail work? I know I am not wording this properly :poly122: so let me know if my question is not clear.
Thanks in advance
I have a question concerning normal maps. I did search before hand on the PC forums, but did not find what I am looking for.
Basically I would like to know if there is a big advantage for using normal maps to replace bump maps. I understand how each are affecting the way light and texture information is displayed/seen.
In other words, can a normal map basically replace what the bump maps can do as well as use normal maps for detail work? I know I am not wording this properly :poly122: so let me know if my question is not clear.
Thanks in advance
Replies
Bump maps aren't really used in modern game engines anymore except for specialized cases, because normal maps do the same thing and are much more versatile.
So yes, with normalmaps you can do what you could with bumpmaps, but with more control.
Bump map are grayscale, so you have only 256 level of height.
Normal map are colorful, so you can have 16,4 millions of level of height.
If I'm not correct, please just reply to this.
"In 3D computer graphics, normal mapping is an application of the technique known as bump mapping. While bump mapping perturbs the existing normal (the way the surface is facing) of a model, normal mapping replaces the normal entirely. Like bump mapping, it is used to add details to shading without using more polygons. But where a bump map is usually calculated based on a single-channel (interpreted as grayscale) image, the source for the normals in normal mapping is usually a multichannel image"
normal maps = x^2 normals.
bump maps = (x-1)^2 normals.
1. Accuracy as it pertains to bit depth, comparing a 8bit image to a 24bit image, sure you would instantly say the full color image has more accuracy. However, we fail to consider that a tangent space normal map, being the mostly-blue beast that it is, is hardly using the full range of information available to it. It still has a relatively small window of data it can use to represent height differences.
Normals/Bumps are also of course limited to the same resolution, same amount of pixels. So there really isn't a big difference when it comes to detail or bit depth accuracy between the two, and infact normal's poor compression habits highlight just how small of a range the image actually uses. So, this isn't really why we use normal maps over bump.
An object/world space map uses more range of the color, but it is in non-relative space, IE: specific colors always mean specific directions. A bump map is always relative to the surface, meaning each pixel could theoretically represent 256 different values.
Now, the second way in which we talk about accuracy is in regards to data baked from a mesh.
This is where normal maps are really helpful, as we can take very accurate geometric source data, and project this onto uv space and save it as an image. Details are projected accurately despite UV distortion and the low poly mesh normals being able to be replaced entirely are of course the main benefits here. With a properly sync'd up baking workflow, we can accurately replace the mesh normals of the low resolution model with those of the high.
Bit depth doesn't have a whole lot to do with this sort of accuracy. The point here is normal maps that replace a meshes normals entirely are often baked from a source, and a bump map painted by hand is only going to alter the normals relative to the exsisting normals. Meaning you'll never get that highpoly look by simply painting a bump map by hand, as you'll never be able to accurately account for the lowpoly's mesh normals/smoothing by hand.
This is the biggest reason why baking from a high res mesh is the preferred/common way to go about doing things.
For all practical purposes, a bump map, whether it is converted to normals via a tool like crazybump/nvidia plugin, or at runtime, its just the means to an end. Which is of course a normal map, so they are both normal maps and are both limited to the same resolution, when all is said and done.
Unless i'm missing something here.
Also thanks to all the responses people. I am definitely more informed now :poly142:
You ought to wonder about everything your 3d classes teach you. If I didn't, I'd still be using edit mesh, box modeling EVERYTHING, and rigging my characters with physique.
Again this isn't really a bit depth issue, bump maps introduce banding because they represent height, and normal maps represent direction, so on a slope, every pixel in your bump map would need to represent a step of the gradient, however in a normals map it can simply represent a direction.
Tangent space normal maps hardly use the fuill range, with the blue channel only really using the top 128-256 range, and the red and green using the middle range around 128 more than the upper and lower ranges. So its not simply a matter of X has better bit depth than Z, its X stores data in a completely different manner than Z. You can represent the data more accurate with less range when using a normal map, but this isn't because a normal map has more bit depth.
Another interesting tidbit on compression, video cards do not support 8bit compressed images, so while you may think your grayscale bumpmap(or spec map!!!) is 1/3rd the size of a 24bit normal/color spec map, its actually not. A compressed 24 bit image is 1/4th the size, and a greyscale image is only 1/3rd the size, so speaking from memory usage, unless you can pack multiple grayscale maps into a single 24 bit image, you're not saving any memory by going greyscale.
Also, if you pack a grayscale spec into the alpha of your diffuse, your compression ratio is 2:1, or the exact same amount of memory it takes to use 2 full size 24 bit images, so craming greyscale spec into the alpha and losing color information is always a bad idea.
Curved surfaces and gradiation to account for smoothing are good examples of where the extra bit depth comes into play, but the diamond example above is more of a best case worse case example, IE: where you need heavy gradiation in a bump map, compared to basically a few colors to represent the angles in a normal.
I dont know how productive it is to compare things like smoothing compensation in normals VS bump, as you'll never try to paint that by hand with a bump map.
oh also i think I misread your last post malcom, i'm confused now.
Allows for one less file call though, which is not always negligible (but yeah usually more interesting for stuff that is grayscale anyways, like gloss map or height map).
Right, this is generally an issue when your shader is already making lots of texture calls, in which case limiting the number of files can be key, I was speaking purely in terms of vram used.
Generally speaking, the only time you'de use bump is for ease of use when authoring, like stuff that is really easy to paint in 2d, complex designs and patterns.
If you're baking from high you will always use normals, as bump is converted to normals anyway. There is never a situation where you'de use a bump from baked geo(unless it is for displacement/paralax, then its a "height map"), because its all normals in the end.
This is what per is getting at.
Bump/displacment maps also tend to be in a sort of "optimized" state, IE: use the max range of the image as possible, and then tweak the % via a shader paramater. It would be very hard to get an accurate bake from a bump map, I think basically impossible. Normal maps have fixed values as far as the angles they represent.
Also, a baked bump/height map would never compensate for the gradiation/normals/curvature of the lowpoly mesh normals, it would only ever compensate for the height difference between the high and low, meaning the only possible use would be displacement/parralax. As a bump map will never compensate for smoothing errors like a normal map does.
A real quick way to test this, would be to generate a height map from a complex model and assign that as a bump map on your mesh, you'd get all sorts of nasty artifacts because you're applying a displacement as bump essentially, not because of anything to do with bit depth precision, just the fact that these are two entirely different sets of data. One represents height, the other direction.
Lets take a look at this:
Here we see high, low + baked normal map, and low + baked hieght map converted to normal map.
The normal map works perfectly, because a baked normal map is:
A direct comparison of the differences in the normal direction between the high and the low poly mesh.
However a height map is:
A direct comparison of the differences in the height direction between the high and the low poly mesh.
The normal map does exactly what it should, replaces the lowpoly's normals with the normal direction of the highpoly mesh.
Now, you see that the height information is completely a different set of information from that of the normals, so you get all sorts of problems, this has less to do with "accuracy" of bump vs normal than it does with the data you're generating the information from, and has absolutely nothing to do with bit depth precision
Also, I use floaters on some areas to highlight the various drawbacks of the method if it really were feasible at all. You could of course edit the hieght map to limit that, but what is the purpose, you're doing a lot of work when the proper way is just staring you in the face.
Bit depth and banding and all of these are issues(they are issues with normal maps too in some cases) but its so far down the list of real problems that its not worth discussing. Again, the reason we dont bake height maps and convert them to normal maps is not banding, but the fact that you will never accurately replace a mesh's normals from a generated height map, it just doesnt work. And this is the entire point of using normal maps, to replace the mesh normals with that of a more detailed source. If we could export 32bit per channel bump maps that solved the problem of banding, we still wouldn't be able to use a bump map as a replacement for normals, as a bump map does not contain normal information and can not compensate for smoothing.
When we realize that all bump maps are necessarily normal maps, bump maps offer absolutely no benefit, except for content that is easier to paint in 2d.
The real question is why *wouldn't* you? We've already covered the fact that bump maps are basically inferior in every way, even using more VRAM than a normal map.... Why would you ever want to do this?