Recently I''ve launched site about my own game http://www.sunnygames.com and I''ve got some good feedback about it. But I still unsure about bump mapping. Should I implement it? And if I should what kind of bump-mapping should I choose? Dot3Bump or Emboss or EMBM? All of them has some advantages and disadvantages. Actually I''ve already built in the engine Dot3Bump but it is not working properly on some old video cards like Riva TNT. So what is better to impement in the game latest features and forget about users with old hardware or cut engine features but all people with any hardware will be happy with my game

Make your engine scale. So for instance, if the user has a GF3, enable full bump-mapping. On a GF2, only use per-pixel lighting, then below this cut out per-pixel lighting all together ( well, lightmaps could be used I suppose ).

Death of one is a tragedy, death of a million is just a statistic.

Assuming you have limited programmer time, aim for the middle. Don''t spend time on effects that only the highest-end people will see, and don''t aim for satisfying the lowest-end either. Specifically, do not implement emboss bump-mapping.

Dot3 is very different than EMBM, the graphical effect isn't the same at all. Dot3 is used to bumpmap diffuse/specular material components (that's the standard bumpmapping everyone knows). EMBM is reflective bumpmapping, and only useful to bumpmap reflective geometry that can't be correctly bumpmapped through dot3 (metals, glass, mirrors, etc). EMBM is a very highend effect, and will only work on GF3+ and new Radeons. Dot3 works very well on any GeForce/Radeon/Kyro type board. Emboss shouldn't be used anymore, it's obsolete.

/ Yann

[edited by - Yann L on July 3, 2002 8:49:14 PM]

if the user has a GF3, enable full bump-mapping. On a GF2, only use per-pixel lighting

perpixellighting includes bumpmapping, bumpmappingno gpu today can do perpixellighting correctly with everything except radeon8500, just to state that. (yes you can hack around with rendertotexture and much multipass but thats not the point, its not simple supported. its as good supported as raytracing on the radeon8500 is..)

"take a look around" - limp bizkit
www.google.com

Perpixel lighting does not include bump mapping. Bump mapping includes per-pixel lighting. You can per-pixelly light without bump mapping. On nutty.org you will see a per-pixel lighting demo that doesn''t use bump mapping. There is also an article on per-pixel lighting without bumpmapping here.

On another note, I have a demo here from nVidia on 2 pass cubemap EMBM, and it works on my GFMX ( granted, really slow ), so it is possible on < GF3.

Death of one is a tragedy, death of a million is just a statistic.

quote:

---

On another note, I have a demo here from nVidia on 2 pass cubemap EMBM, and it works on my GFMX ( granted, really slow ), so it is possible on < GF3.

---

That's fake EMBM, it uses a simple x/y perpixel offset into the envmap. This can be done on < GF3, but as you noticed, it's very slow, since it involves a framebuffer readback. It only works on planar surfaces, but looks pretty good if you respect the limitations.

Real EMBM (much better quality and robust on arbitary geometry) needs a perpixel matrix multiply and reflection vector computation. That's GF3+ only. IIRC, there is a demo somewhere on nVidia's site that shows the difference between both methods.

/ Yann

[edited by - Yann L on July 4, 2002 8:31:30 PM]

Yeah, somehow I didn''t think that what I had was real EMBM. Do you know of any good articles on real EMBM? I wouldn''t mind getting up to speed on it...

Death of one is a tragedy, death of a million is just a statistic.

a) the demo uses real "true reflective bumpmapping" (as nvidia calles it)
b) it does _NOT_ depend. lower gf3 can't do any dependend texture lookups, not important if its a true 3d matrix transformed and reflected vector perpixel or simply a 2doffset. it CANT do it.

how its done:
it _DOES_ calc the reflection vector perpixel.
it reads back the screen.
it draws glPoints at every pixel with the texcoord as the vector that is read back at this pixel.



about the perpixellighting
bumpmapping does not need perpixellighting. perpixellighting does not need bumpmapping. but perpixellighting can include bumpmapping in its technology, while bumpmapping can't "include" perpixellighting. it can bumpmap in a perpixellighting engine, or in some simple vertexlighting engine even. you can bumpmap without a light even...

perpixellighting is more than bumpmapping.. much more.. (dive into brdf's and all that to have real fun)

anyways, its just nitpicking. (i do this because i hate it that on nvidia hw its nearly not possible to get correct perpixellighting to work while bumpmapping is that easy.. but not correct perpixel lit bumpmaps don't look that sweet..)

"take a look around" - limp bizkit
www.google.com

[edited by - davepermen on July 5, 2002 7:04:49 AM]

quote:

---

a) the demo uses real "true reflective bumpmapping" (as nvidia calles it)

---

It looks very fake to me, compared to real EMBM. Perhaps it depends on our defintion of ''real EMBM''... Or perhaps it''s just a side effect of their half hardware/half software rendering. I haven''t looked at the source, so I''m not 100% sure either.

quote:

---

b) it does _NOT_ depend. lower gf3 can''t do any dependend texture lookups, not important if its a true 3d matrix transformed and reflected vector perpixel or simply a 2doffset. it CANT do it.

---

Quoting myself: "This can be done on < GF3, but as you noticed, it''s very slow, since it involves a framebuffer readback". Where did I say that it would work on HW on < GF3 ? Of course, even true reflective EMBM could be done on a GF2. Even on a Trident 512kB ISA card. That''s called software rendering - and it''s not what i was talking about...

quote:

---

Do you know of any good articles on real EMBM?

---

Hmm, about the theory or the implementation ? nVidia has a nice paper explaining (and comparing) both methods (for OpenGL). I think it was this one.

/ Yann