PDA

View Full Version : Some Bump Mapping Questions (cube-mapping)

Whooster
01-14-2012, 10:35 PM
This is regarding some old tutorials I've read online. I'm not as much asking about how to do bump mapping, as much as I am just curious about the tutorials (they seem pretty popular). The questions mainly concern this tutorial: http://www.paulsprojects.net/tutorials/simplebump/simplebump.html

1. I've seen that cube-mapping is used a lot for environment reflections, yet I've also seen a decent amount of bump-mapping tutorials using cube-mapping in a very different way. Just to make sure I'm getting this right, the cube-mapping was being used to store the value of a vector, in the vector itself, on the cube map? So (1.0, 0.0, 0.0) corresponded to a 'texel' of (1.0, 0.0, 0.0)? And this was done in order to normalize light vectors? That just seems like a lot of overhead and work compared to just normalizing a light vector by finding the length of the vector, and dividing that by the x,y, and z coordinates. Is using the cube map method supposed to be a lot faster?

2. So those methods of bump mapping are kinda hackish, as in they had to do it that way since there weren't shaders back then? Also no one uses them anymore since GPU's started supporting shaders?

3. If I actually wanted to do bump mapping I shouldn't do something like that, but learn GLSL, right?

Alfonse Reinheart
01-14-2012, 11:55 PM
And this was done in order to normalize light vectors? That just seems like a lot of overhead and work compared to just normalizing a light vector by finding the length of the vector, and dividing that by the x,y, and z coordinates. Is using the cube map method supposed to be a lot faster?

Once upon a time, yes. Computing a length was at one point impossible in shaders (at least for practical purposes). And even when it was possible, computing the length was not necessarily cheap. A quicky texture access in those days could beat it.

Of course, things are different now. A reciprocal square-root is cheap. And because the ALU shader count has increased far faster than memory bandwidth, the cost of texture accesses is much higher relative to the cost of math operations these days.