Phong-Shading vs. PerPixel-Lightning vs. Gouraud-Shading

Does anyone know any good way for realizing a better lightning-algorythm than the orig. grouraud-shading, support by OpenGL ?
I´like to use phong- or perpixel-lightning, but until now i don´t have found any good explanation for coding this. All stuff i found was mostly unreadable and ver slow !
If anyone has a sourcecode for one of these algorythms, please send it to me !

DjSnow

Can you be specific about what techniques for per-pixel lighting you’ve tried, and where you’ve found information so far?

What specifically are you trying to do, and how slow is “ver slow”? :slight_smile:

On current consumer hardware, if you want per-pixel lighting at interactive frame rates then you have to use lightmaps - precalculated luminance textures that are blended onto your polys. This is how Quake etc do it; it’s pretty fast with multitexture hardware. But having to pregenerate the maps is a bit cheesy.

Still, changes are afoot - the PixelFusion boards due out this year will support realtime programmable per-pixel shading models including Phong and Torrance-Sparrow. I think it’ll be priced for the pro market initially, but should come down rapidly.

I believe there are cards already out there that can do dot-product per pixel, but I couldn’t tell you what the performance or interfaces are like.

I tried some kind of specular hilight simulation, by applying a texture with sphere mapped coordinates generation.
The result is very nice, and the overhead is recalculating the highlight each time you move the affected light source.
By having an hilight map, you can use multitexturing to gain optimal performance.
I found this tecnique described in the SIGGRAPH course notes of… maybe 96-97?

Check out this link. This is the most amazing dynamic lighting algor I have seen in current consumer hardware: http://www.opengl.org/News/Special/oimupdate/perpixel.html

Also check these pages
http://www.pseudonymz.demon.co.uk/genoth.html

i Found it today on the OpenGL news called
“Supposedly useful stuff for OpenGL Game Developers”

Yes, Coco, i saw this article - but there is no source included. And i saw the same “technique” in an NVIDIA-developer demo.
The objects looks like the same, too !
I think, the man, who posted this articel to opengl.org ripped it off the NVidia-demos.

Yes, Coco, i saw this article - but there is no source included. And i saw the same
“technique” in an NVIDIA-developer demo.

What you saw in the NVIDIA-developer demo requires a GeForce. The demo I did does not require a GeForce, but it takes 26 passes to achieve its results.

The objects looks like the same, too !
I think, the man, who posted this articel to opengl.org ripped it off the NVidia-demos.

It’s SUPPOSED to look like the nvidia GeForce demo for the very purpose of illustrating that you can do (actually approximate) per-pixel lighting WITHOUT special OpenGL extensions. If you don’t have the fill-rate to support 26 passes, though, it’s gonna crawl. The look of the demo may be “ripped off”, but the technique implementing it is certainly not.

Look at the source for the OIM article that is referenced if you want to understand one way of doing per-pixel lighting in unextended opengl. The technique in the demo is an extension and generalization of that technique.

Cass: uh, sorry ! thanx for this “lightning”

hey Cass where is the original article…
Orthogonal Illumination Mapping (OIM)

the link on the page Coco mentioned is dead

Mike,

I had not noticed that before. I’ll send a note to webmaster@opengl.org and get that corrected. Both links are in the “developer features” section on the left column of the OpenGL.org main page. You can get to the original article directly with this link:
http://www.opengl.org/News/Special/oim/Orth.html

I’m planning on providing the source for the demos in 2 stages. First I’ve made a version of the terrain renderer that uses ARB_multitexture and NV_texture_env_combine4 to eliminate several passes from the original demo. I also added both specular and diffuse lighting to that demo per some suggestions from Mark Kilgard. I’m going to integrate an NV_register_combiners version too.

The source for the torus demos (which I have in separate project right now) will be released later, when I have some time to write a simple how-to.

its there…thanks for the updated link

Yeah I’ve got what you’re looking for.
I didn’t know Jack **** nor John Diddly Squat about “PHONG” and “GOURAUD” shading back in my DOS cracking ages, so I have come up with a shading and lighting procedure wich is pretty damn fast and produces the best results possible at that compuational intesive level, I like to call it, “Mike Shading” lol!
What you do is create a 3D cone that acts as you’re spotlight. The cone should always enlarge it’s nosle radius according to the polygons that are located right infront of it, so it kind of “Sticks to the wall”, so to speak. Now all you have to do, is state that whenever the cone is oriented towards a polygon that is part of an object you would like to “enlighten”, the gamma components of the texels of those polygons should be increased incrementaly up to the cone’s radius, so it kind of looks like a gradient radial “Spot” that is located on the polygons. Offcourse, you don’t have to draw the cone, allthough it would be nice for debugging. This method should work pretty fast, is very easy to implement, has “per-pixel” capablities, and is accelerated by FPU hardware (isn’t everything?).
The only bad thing about this is that the spot looks kind of bright, yet the advantage of this per-pixel approach lies in the fact that you can use diffirent (maybe gradient) colors for each “ring” of the radial spotlight.

Mike The Spike

MikeTheSpike: this suggested algorihtm sounds more like an effect, not a lighting algo.
I’ll call that a ‘hotspot hilight’ effect.
For this hotspot hilight you could achieve outstanding results if you use lightmaps, optionally combined with multi-texturing.

Yes Paolom, i think the “way to do” described above is not more than an effect.
I think with multitexturing, i´m already using, it is fast as possible - without FPU, acceleration which is already slow today - as it was in old days, as we all had 386 !
But thanx, Mike the Spike, i will think about this lightning-algorythm. But i think i´m using better the above mentioned way with multitexturing and lightmaps.

No problem pall!

Mike The Spike