Core Weasel +1

[SwiftSpear]

I would be much more accepting of proposals for bumpmapping then I would be of all the drooling for normal mapping. Even so you are adding 1 more texture PER UNIT to be stored in an enging that is already using the fuck out of your texture memory. When all the units are modeled spring will have an issue if we do not have sm3 by then.

Bump Mapping is basically normal mapping. It's a slight change to the way the render works that allows for a more realistic end result in certain situations. You can create a normal map from a bumpmap.

[smoth]

not really swift.

[[Krogoth86]]

not really swift.

Although I agree with you Swift has kind of a point too as the term "Bump Mapping" is a bit vague nowadays and there in fact are some normal mapping like techniques which are referred to be "Bump Mapping" although imo bump mapping still is kind of a detail texture which you assign to a surface and which adds some faked depth to it by using a greyscale texture while normal mapping is saving information of a high-res mesh into a coloured map which then emultates high-res lighting on a low-res mesh...

[SwiftSpear]

In normal mapping you use color codes to determine the direction any given pixle reflects light, as opposed to bump mapping where you just apply a greyscale heightmap to the object. From a technical perspective this allows for greater control of exactly what microfaces are being applied to the model. From the rendering standpoint there is very little difference between the two systems. Normal mapping solves all the problems with heightmaps though, you can produce a true vertical slope, you can produce very high resolution faces, you have alot more power over what exactly is being displayed by the map.

It's alot easier to break a normal map if you don't know what you're doing, but like I say, you can generate a normal map from a bump map, or more popular, a model.

[smoth]

nope

[[Krogoth86]]

Well have a look at DOT3 Bump Mapping where you also use a normal map and no greyscale heightmap...

I think from a players point of view the difference between bump mapping and normal mapping should be that bump mapping is a ffp effect available for GeForce 256 (not sure if that was the first to have it though) and higher while normal mapping needs shaders which came with a GeForce 3 and higher...

But for quite some time both terms somehow have merged into "Bump Mapping" opposing to things like Displacement, Parallax or Relief Mapping...

[smoth]

yeah, I think that is because the industry likes it's buzzwords. Remember when rendered sky areas were called portals?

[rattle]

Normal maps generated with the nvidia filter (or tool, I think there is one) will have all the normals face in the same direction except for the bumps. Also this doesn't take the UV's direction into account which a normal bake does.

[smoth]

which is bad despite what certain community members will tell you.

[imbaczek]

doesn't everybody know that normal maps are best generated from a very detailed model...?

[Zpock]

Does a normal map generated from a grayscale bumpmap look worse then rendering the bump map directly? Pictures?

[smoth]

Normals are vectors which are generated at a vertex of a model. The normal serves the purpose of providing several normals without the usage of extra vertices used for the alignment of said vectors.

Typically in the industry the model has a high detail model which is used with specific lighting to bake onto the low detail model r,g,b colors one for each light. This composite texture creates a direction based on the colored pixels creating 1000s of normals used to create light and shadow.

When you use a utility to generate a normal map from a black and white bump map in generates said normals with the assumption that the texture is a flat surface. So faces that are skewed, stretched rotated etc will have odd normals for their lighting when using the auto generate tool.

I probably did a shitty job explaining it but I hope I did good.. now for more Ah, my penis... I mean Ah, my goddess.

[Zpock]

A normal map uses 3 colors to specify normals at each pixels in 3d, the 3 values (RGB) descibes one such vector, a bump map just has relative height values for each pixel (in grayscale).

[smoth]

wow, your explanation was better then mine in a sentence

[Zpock]

The question tough is if a bump map converted and rendered as a normal map looks worse then a rendered bump map? Then I can see why you would consider using those, but normalmaps just seems much more modern to me...

I see why you would want to be able to use bumpmaps since those can be hand made, with true normalmaps you would have to use high poly models, and I would think they are more suited to organic objects.

[smoth]

the problem is the auto generated normals are more then likely incorrect so odds are they are going to be very incorrect.

[Zpock]

I thought that when you rendered a bump map (grayscale) you pretty much had to calculate those normals anyway? Since the light intensity would be dot product (how parallel) of the light direction and normal at that pixel.

Here's a decent post on bump vs normals map that I found on another forum after searching around a little:

Basically: Yeah, they're about the same thing.

A normal map stores the slope/tilt of each pixel in the texture.

A bump map stores the simulated height of each pixel in the map. The renderer has to then convert these heights into slopes when it renders. It does this by comparing the current pixel with all it's neighbors to find it's slope.

Back in the day when all bump maps were hand-painted greyscale maps, they were converted to "dot-3" maps for game engines. It was really just a normal map. If I remember correctly, the name dot3 comes from the fact that it took 3 dot-product math operations to figure out the lighting per pixel with that map. But they are the same thing in the end.

Normal maps are better becuase:
1. The renderer wants the normal (slope/tilt) of the pixel for lighting. In a normal map, that's exactly what the data represents. In the bump map, it has to calculated on the fly.
2. They are more accurate. For the most part, it's not really noticeable though. A greyscale bump map can only hold 256 levels of height, so it is technically possible to come up with a map that can't be presented in bump form, only normal form. Very sharp edges are easier in normal maps. I think a recent Game Developer has a great image that illustrated this well: Each pixel in a bump map is a little block of a certain height. Lay down a sheet of rubber on top of this to see the shaded, sloping surface. There's a loss of detail in there.
3. They are better for representing something which is difficult to paint manually (ie high rez geo). Remember, that it's not just storing the curvature of the high rez model, but the difference in curvature of the high rez model and the low rez model. That's tough to paint [img]/images/graemlins/smile.gif[/img]


Bump maps are better because:
1. They are easier to visualize.
2. They are smaller on disk (although some of the new hardware's compressed normal map formats are quite comparable)

In the end, the best of both worlds comes from the combination of the two:

A: Generate a normal map from the high-rez model. Don't model down too small (pores, scars, stitching, etc). It just leads to model bloat and excessively dense meshes. Although cool to show off, they are pretty useless in the real world.
B: Hand paint a greyscale bump map for small details: fabric pattern, scars, stitching, pores, hairs, etc. Save yourself the trouble and paint this, not model it! Faster revision time, quicker to do, quicker to preview. I know zBrush is rad, but imagine detailing the mesh down to the pores & moles, and your AD asks for changes. Either go back to an old version, or try to smooth them out and remodel. Or just repaint in Photoshop.
C: Combine the bump map and normal map into a new normal map. This renders fast and has the best quality.

Doom 3 did it this way as well. Their pipeline was automated too: they supplied a normal map and a greyscale, and a strength for the bump in the shader. The engine would generate a new .dxt file for those when loading (composite while loading) if it needed to (ie, if the normal map or bump map were newer than the composite). Great for developing, and fast for anyone who wasn't changing the maps. Contrary to what most people think, it didn't render with both a normal map and a bump map, it was combined and rendered only with the final normal map (check the .paks, the .dxt's are the combined maps).

Both have a single failing: Imagine a flat panel on top of another flat panel. Neither can show this properly without a tiny bit of bevel around the edges. If you're capturing a normal map, it's lost completely. If you're painting a grey-scale, it's beveled a bit. Neither is really the best for that.

[smoth]

the rendering can handle bump yes, but it also has the other vertices to go by. Something the nvidia tool does not have acess to on the texture.

[SwiftSpear]

The nvidia tool is a quick hack to aid in texturing. The results it produces pale in comparison to properly modeled normal references, or even manually created bumpmap imports. It's just there so you can make use of the normal features quickly and easily.

It doesn't make a better normal then a good manually created bumpmap, but it takes alot less work.