Accurate Perpixel Bumpmapping
"Dont Believe Imitations"
Download: L3S_bm2.gm6[GM6][1.8mb][Host-a.net]
Previous versions:
L3S_BM [GM6][1.7mb][64digits]
Since im probably ending my GM career fairly soon (Ogre3d & c++ look tantalising) and ill probably never make an L4S, i thought i would release the only example of real perpixel bumpmapping i've ever seen. I managed to get it fairly fast (I get a drop of about 10% compared to emboss bumpmapping), it requires no extra surfaces in my L3S engine and only requires two more sprite renders than the old emboss bumpmapping. Unlike other examples the accuracy of the bumpmap render does not depend on how many objects you use.... this isnt quite as obvious in the engine since i cant be bothered uploading my 4.5mb version with 512x512 textures.
EDIT _linenums:0'><strong class='bbc'>EDIT:</strong> Since not many people are actually aware of how the Dot3 bumpmapping formula works, just how it should look....*cough cough*.... i've decided to write a little speal arguing why this is an accurate approximation as opposed to the other examples i see lieing around.The normal dot3 bumpmapping formula is (n = normal,l = light):result = n.x*(x-l.x) + n.y*(y-l.y) + n.z*(z-l.z)Doing the usual GM workaround i split it into 3 renders:result = 0;result += n.x*(x-l.x)result += n.y*(y-l.y)result += n.z*(z-l.z)To deal with negative x-l.x components we have to create an inverse n.x so the equation becomes:if (x>l.x){result += n.x*abs(x-l.x)}else{result += -n.x*abs(x-l.x)}......Thats pretty easy and all, But tell me this, how do you get the x - l.x component on a perpixel basis? You see.... this is where my example differs from others. Others usually just approximated it based on the centre of the sprite or something. But, If you paid close attention in mathematics, you would realise that the dx component changes linearly with 0 at the light and extends out to infinity (Actually 255 because were dealing with 8bit per channel textures) on either side. This means that we could easily represent it like this:
Using this information, we see that by shifting the colours from black to white on each vertex of the n.x sprite based on the dx <strong class='bbc'>of that vertex</strong> we can make it automatically render the internal x - l.x components. This methods works 100% until you get the case where the light is above the sprite, however i've fixed this in the example by making it render 2 halfs with correct vertex colours when this special case occurs.Theres still more to the algorithm than i posted above, for instance how do you get the dz on a perpixel basis? This is where the only approximation (i know of) comes in.... Ill leave you guys to figure it out.Cheers,PS: No i did not make the textures/normal maps, they are from FilterForge. This example will work with mulitple lights, but its not 100% integrated into the engine so it might be a bit hard to set up.
Update: Added some better Bumpmaps to show how versitile the engine is.
Update v2: Added some new Bumpmaps which have 'exhaggerated bumpiness'... also slightly modified the rendering procedure (normalised light vector).
Edited by Adventus, 27 September 2007 - 09:57 AM.
