I’m doing a little research about different techniques on how to achieve reflections (environment mapping) and cheap per-pixel lighting.
What I would like to know is how common cube mapping is vs how common dual paraboloid mapping is. So if someone knows which of these two techniques that are being used in some common applications today (for instance HalfLife, Quake2 etc.), then please let me know.
Thanks!
There are three common methods of environment mapping:
Option #1 requires the least texture memory but also is not 100% accurate.
Option #2 is accurate, but requires twice as much memory as #1.
Option #3 is accurate, but requires six times as much memory as #1.
So why is #3 used often? Because it is the easiest to generate in real-time. Both #1 and #2 require complex mathematical operations to calculate the environment maps, so are primarily used when the world is mostly immutable. #3 is really easy to generate, so is more suited to realtime applications than #2.
I do not know what method Half-Life or Quake 2 uses. For all I know, it could be some other technique entirely…
Just give me SMP.
Cube envmaps actually make more efficient use of texture-memory than the other two techniques (which waste around 20% of a textures). A 1281286 cube-map compared with a 256*256 sphere-map will provide ~1.8 times the sampling resolution for 1.5 times the texture-memory.
Mike F
MikeF,
Point well taken. I was assuming that if the sphere map was 256x256, than each of the 6 sides of the cube map would also be 256x256.
Do you guys know if there is any program out there that uses cube mapping without special hardware support? Cube mapping is indeed more intuitive than dual paraboloid mapping, but problems occur when a triangle’s three vertexes are being mapped with texels from one cube face each. Then three rendering passes is required for that triangle (if no multitexture is available). For the whole surrounding 6 rendering passes are needed (3 with 2-unit multitexturing). I think it has to be supported in hardware to be worth considering.
Originally posted by Lubbe:
Do you guys know if there is any program out there that uses cube mapping without special hardware support? Cube mapping is indeed more intuitive than dual paraboloid mapping, but problems occur when a triangle’s three vertexes are being mapped with texels from one cube face each. Then three rendering passes is required for that triangle (if no multitexture is available). For the whole surrounding 6 rendering passes are needed (3 with 2-unit multitexturing). I think it has to be supported in hardware to be worth considering.
You’re right, cube-mapping is only practical with hardware-support. If you’re trying to pick the most suitable technique, consider: Although dual-paraboloid envmaps aren’t very intuitive, it’s fairly simple to convert cube envmaps to dual-paraboloid envmaps so they needn’t be any harder to create.
The area where cube env-maps really shine is that you can directly use the output of a render as a cube-map face with no distortion or extra processing required; this makes it feasible to regenerate the envmap each frame using the graphics hardware.
Mike F
Originally posted by Mike F:
[b]
The area where cube env-maps really shine is that you can directly use the output of a render as a cube-map face with no distortion or extra processing required; this makes it feasible to regenerate the envmap each frame using the graphics hardware.
Mike F[/b]
Really? On consumer hardware? I was under the impression that pixel transfer ops (framebuffer to texture) did horrible things to your framerate on most cards?
Originally posted by MikeC:
Really? On consumer hardware? I was under the impression that pixel transfer ops (framebuffer to texture) did horrible things to your framerate on most cards?
I’ve not tried it myself.
However, I have seen an extremely impressive D3D+GeForce demo of a Newton’s cradle with all the balls correctly reflected in each other. In case you don’t know it, a Newton’s cradle is a desk-toy with 6 chrome balls bouncing off each other; all the balls were in motion and suffice to say it was a really impressive demo that would have been considerably more tricky to do with DP envmaps.
As I said, it was a D3D demo. It at least shows that there’s consumer hardware out there that can handle this kind of thing well. How badly the OpenGL pixel transfer paths would hinder it is another matter. Does anyone have any experience with this?
Mike F
[This message has been edited by Mike F (edited 06-29-2000).]