EMBM is just a simple method to distort your texture coordinates when rendering an environment map.
EMBM limitations:
- Works only on objects that have environment maps. Warps only the environement reflection texture, does not affect lighting (diffuse/specular) at all.
- Not in any way physically correct. Has all the same limitations as doing fake specular reflections with environment maps: The environment map is "rendered" from one point (not from all the object surface points) and the EMBM shift to the texture coordinate is just a addition, not a real calculated reflection vector.
- EMBM is not based on real dynamic lighting (it only distorts environment map texture coordinates). Environment maps are (most of the time) static (hand drawn by artists) forcing the lighting conditions to be static.
- If developer chooses, the environment maps can be rendered on real time to allow dynamic lighting, but the performance penalty for doing this is heavy. It's not something that Wii games will likely use. Swapping between different environment textures is also possible, but all the possible lighting conditions still have to be precalculated and stored into a large amount of environment map textures.
- To have both per pixel diffuse and specular lighting, all objects need to be rendered twice using different specular and diffuse environment maps. It still does not look as good as dot product (Blinn/Phong) diffuse/specular normap mapping because of the limitations described above.
As you see from the "Conduit" screenshots all the EMBM bump mapped surfaces are all shiny and reflective (heavily environment mapped). This is because the EMBM only distorts the environment map (without a environment map it does not work). Shiny "fake specular" environment map based bumps like these do not look realistic at all. It's a technique that does not work on dusty industrial looking scenes like Doom 3's really well.
Wouldn't it just be a matter of fixing the halfway vector, to do diffuse (using a appropriately computed diffuse "environment map")?
All your other "gripes" are all correct if we are talking highend rendering. But the "cheats" are perfectly acceptable for lower end real time rendering.
They are used on the vast majority of 360 and PS3 games without anyone complaining.
In the end the question is, do you want a little of one effect that is close to perfect, or do you want a lot of an approximation that is so close people won't notice when playing the game?
Why would emboss bump mapping be as costly as normal mapping?
I couldn't imagine Rogue Squadron III with the same performance had its embossing been replaced by normal maps. In some places it covers entire environments in the stuff (Hoth, Endor).
(Not having played the game) are you sure it's even realtime computed bumps? It would seem silly to do realtime calculation of bumps with a fixed lightsource (the sun in an outdoors environment), and since emboss mapping can't do specular successfully (that
would need dynamic calc outdoors) that can't be what you mean.
The data texture for emboss mapping is smaller (gray-scale as opposed to RGB), and you don't need to compute a per-pixel dot product. It's just a texture offset and an alpha blend.
pc999, emboss mapping is basically severely limited in the types of "bumpy" surfaces it can represent and lighting conditions it responds to. You should read this explanation of the three main types of bump mapping:
http://www.tweak3d.net/articles/bumpmapping/
The Gamecube had hardware support for emboss mapping and environment mapped bump mapping (which is how it did those nifty water effects), but it wasn't really designed for normal mapping (it could be done...but was slow and expensive as compared to the Xbox).
I'd say the extra overhead for RGB textures is negligible if we are only talking bumpmaps, and for small bumps (texturespace normalmapping mostly) 8 bit or 4 bit textures should be more than enough.
AFAIK there isn't any "per pixel" calculations with standard normal mapping, other than what all other pixels go through on a GPU.
Basically, it's just a multicoloured lightsource (RGB) cast on a RGB textured model, that is reduced to monocrome.
Maybe NM on Wii could be done like it was proposed on PS2, with a simple palette swap of the framebuffer (with some some additional transform calculations of course).
I don't see why you'd need much "hardware support" for something as simple as emboss mapping. It's just UV animation according to some specified rules. Very much like environment mapping.
