Can anyone help me with ext_fragment_lighting etc???

Hello!
I’ve just downloaded headers from sgi(glext.h…) and noticed new extensions like:
ext_fragment_lighting and WIN_phong_shading
What is this? How to use them? What I know is that they are not supported on my GF2GTS! ;( But I want-want-and-want_again per-pixel lighting!!! (don’t say me to use register combiners…) Could anyone help me?
By!

Well you could do it with the texture_env_combine and dot3, which is supported in core opengl from 1.3 up (I think) or with ARB extensions.

-Ilkka

Those extensions are actually surpassed and never widespreadly recognized. The ext_f_l comes from expensive hw and it’s probably not supported by any consumer video card.
So, I guess you cannot use them.

Too bad. I also noticed that some time ago.

SGI’s vision for improved hardware lighting was very different from the vision of PC IHVs. (Ironic when you consider some of the designers are the same). NVIDIA, ATI and others have gone for a low level very programmable approach with very simple instructions that you can chain together, and a key part of this is the DOT3 vector dot product based on color inputs and better support for signed & extended range fragment precision.

The SGI approach was to simply provide high level functionality that they thought most people wanted. This included the fragment lighting extension that pretty much added a fragment equivalent of glLight glMaterial etc. etc. (I’d have preferred a glShademodel token for this but nobody asked me :-), the main motivation here was hardware initially would only support limited fragment lights (perhaps just one) and you could combine this with vertex lighting results, but it really complicated apps, a very implementor centric decision IMHO. SGI extensions also included a light(?) texture extension, I forget the extension name. The light texture extension allowed you to direct texture unit output to any of the fragment lighting terms (hardware would have supported multitexture). Another key extension was coordinate_frame with which you could specify a tangent and binormal vector, and you could then send a DOT3 style color component normal texture map to replace the surface normal in the fragment calculations and the correct vertex vector transformation through the coordinate frame would happen pretty automatically.

I wrote a reasonably complete fragment lighting + light texture demo in OpenGL and ran it on the simulator (C and verilog), and it worked very nicely, (this was years ago). AFAIK I’m the only person in the world to have written working code to these extensions :-), but that was the easy part compared to the engineering to implement them. The code drew a metalic looking SGI tube logo dotted with plastic looking m&m style bumps, I no longer have an image of it. To do this you didn’t have to write any fragment code, the most you had to do that was substantially different from vanilla OpenGL was compute binormal and tangent vectors if you needed bump mapping.

This never made it to real hardware although Odyssey (codename) class VPRO graphics does implement a subset of fragment lighting to get better phong highlights on polygons, the rest is just an historical footnote.

Fragment lighting was probably the best way to get apps to incorporate differentiating phong shading quickly and easily(something SGI would have needed) especially in the slow moving CAD/CAM markets etc. The flexibility and power of register combiners and then even more flexible fragment programming is something better suited to a wider range of graphics, but it takes more time and skill to develop applications that exploit it for simpler cases.

The fragment lighting & related extensions could be implemented on top of existing programmability today, all it would have to do is reserve certain OpenGL functionality. This is best done in a utility library that isn’t part of OpenGL.

[This message has been edited by dorbie (edited 05-22-2003).]

That’s an impressive story, dorbie.
I didn’t even know that implementations of the ext_f_l extension ever existed !

To be honest, I’m a bit sick with the arb_f_p + arb_v_p extensions. Sure they’re great and you can do alot of things with them. But when it comes to render bump-mapped surfaces, it’s a long and painful road to learn such powerful extensions and finally just use 5% of them.

gvm: if you have a nvidia gf2gts you should really use nv_register_combiners, unless you want to export your program to other hardware. Mark Kilgard discusses of bump-mapping for “todays” hardware (back in 2000 though!) at http://developer.nvidia.com/view.asp?IO=Practical_Bumpmapping_Tech which includes source code sample for register combiners. Anyway, if you don’t like register combiners, you can still read the paper which is absolutely excellent for math & graphics algorithms in general ; just skip the nv_r_c details. You will learn what is tangent-space bump-mapping, why it is used today and how to implement it.

ammm…
I just hate nv_register_combiners and I cannot use fragment_programs, because of my gf2gts.
So how else can I implement per-pixel lighting?
maybe somehow using texture attenuation maps + vertex programs? somehow like cel-shading?(i have already made it) Or using texture_env_dot3, texture_env_combine?

thanks for replyz…

Originally posted by gvm:
ammm…
I cannot use fragment_programs, because of my gf2gts.

I dont know what your goal with implementing per-pixel lighting is but if you just want learn/try it out, I suggest going with NV30 emulation until you can invest in a DX9 card. If you have a decent CPU and by using a small viewport it is not that bad.With fragment programs you can do and learn so much more too. They might not render in hundreds/thousands of fps, but they sure can create some amazing effects. This is just my opinion though. I am all for programmability.

2roffe: maybe you right, using nv30 emulator is not that bad…
thanks

I tend to like fragment programs even less than register combiners since fragment programs is supported on a very limited range of hardware today.

DOT3 is the way to go. Lots of hardware supports the ARB_texture_env_dot3 extension (at the very least, all GeForce cards and all Radeon cards). You need more passes with texture_env_dot3+texture_env_combine+multitexture than register_combiners, but still it is possible.

I hope new 3d cards will become really cheap really fast.

I like texture shaders and i like register combiners. Fragment programs are way better however…
The point is that all those things are powerful but most people still cannot get it…
I once saw a radeon which supported NV_register_combiners in the extension string… no wait. Maybe I was dreaming.
Sigh.

EDIT: dorbie, please, can you post a url to the image? I am really curious! Please! I looked at this ext some months ago I was really impressed…

[This message has been edited by Obli (edited 05-23-2003).]

The NV_register_combiners functionality is easily emulated by fragment programs. As an example, take a look at www.opengl.org where a recent news has been posted that shows a NVIDIA demo runnning on ATI Radeon 9800. Really impressive emulation work !

Is 100 USD/Euros “cheap” enough for you ? GeForceFX5200 cards do support DX9 and pricing starts at around $100. If DX9 is supported, I think that ARB_fragment_program is supported too (need to check though).

[edit]I’ve checked at the unofficial but pretty useful page : http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_fragment_program
and it seems that ARB_fragment_program IS supported by ALL GeForceFX cards, even the FX5200 series.

[This message has been edited by vincoof (edited 05-23-2003).]

Like I said, I no longer have the image, it’s one thing I wish I’d kept a copy of. Maybe some engineer who worked on “Bali” has a copy of it somewhere. AFAIK it’s gone forever, along with the OpenGL source code that drew it using the extinct extensions.

It mapped different textures to various lighting components, including the normal, diffuse rgb and a color gloss map, about the only thing I haven’t seen done using fragment programs that this did was a specular exponent map (a.k.a. shininess). The m&m bumps had a high exponent making them look plastic while the rest of the object had a low exponent with a little bit of noise, making it look more metalic, done with the simple application of a texture to the shininess fragment lighting input using the light texture extension.

[This message has been edited by dorbie (edited 05-23-2003).]

Originally posted by dorbie:
It mapped different textures to various lighting components, including the normal, diffuse rgb and a color gloss map, about the only thing I haven’t seen done using fragment programs that this did was a specular exponent map (a.k.a. shininess). The m&m bumps had a high exponent making them look plastic while the rest of the object had a low exponent with a little bit of noise, making it look more metalic, done with the simple application of a texture to the shininess fragment lighting input using the light texture extension.

I’m pretty sure it could be done in a fragment program by a simple 1D-texture lookup from the specular lighting contribution (in fact, the secondary color).

But if I’m interpreting your words correctly, you’re not telling that “it’s not possible with fp”, you’re telling that “you’ve never seen it with fp”.

[This message has been edited by vincoof (edited 05-23-2003).]

Correct, I’ve never seen it. OTOH a simple lookup wouldn’t suffice. A lookup can get you any exponent, but a lookup cannot get you a range of exponents that varies with texture. You really need to use a true fragment power function with an input from a texture unit.

pseudocode:

fragment_specular = pow( V.H, texture3_fetch(fragment_s,fragment_t) )

It’s the texture3_fetch(fragment_s,fragment_t) that’s difficult to place in the exponent

[This message has been edited by dorbie (edited 05-23-2003).]

Ok. Thanks for the explanations. It must look awesome !

It should then be able to write such shader in a fragment program, using a POW instruction after the texture lookup.

The NV_register_combiners functionality is easily emulated by fragment programs…
…Is 100 USD/Euros “cheap” enough for you ?..

NV_reg_comb are not just emulated using VP. They are simply surpassed. BTW, the fact is that ATi cards can probably support it in HW since 7500. The point here is that if the extension is not listed in the ext string it’s simply not there.

100euros is enough for me but not for most consumers. I fear we’ll find crappy hw for a long time, at least here were I live (some pcs are getting sold with integrated graphics which is not nForce2).
Another problem is the installed base.

I fear we’ll find crappy hw for a long time

That’s a very old problem, and is not to be resolved soon. At least, when you pay 500 USD/Euros for a graphics card, you’d better have something that low-end hardware does not have.

Mixed feelings on that…
4x the performance may be enough. We all know how much pain it is to support different renderpaths, to choose extensions to support or not.
VP and FP alone can do most things so as soon they are estabilished we won’t have to worry anymore. For the time being however…

Example: the GF2MX can do everything the GF2 does, only slower. This is nice. Developers are happy because they need to worry only on performance tweaking since the features are the same…

Same thing goes for rd9500/9600/9700/9800 and FX5200/5600/5700/5800 (or whatever it’s numbered).

Customer is happy just by watching the FPS count and reading three-digits numbers. Luckly, looks like very soon all the video cards from Ati and nv will have similar functionalities so in the future there will be no problem. The problem is now since DX8.1 graphics is rocking and you need to go for it. You can do it using VP and FP but right now, you have to still worry about NV_r_c and NV_tex_shad, which is not avaiable on Ati cards but still has a very wide installed base. Ugh. What a pain.

Forget this, I am just doing some blah blah blah…

[This message has been edited by Obli (edited 05-24-2003).]

I know what the vendor-specific extension crap looks like. But currently, if your card does not support ARB_fragment_program, you can still use widely supported ARB_texture_env_combine, ARB_texture_env_dot3 and such. Just be a little bit patient. Not so long ago, you couldn’t assume that even AB_multitexture was supported !