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...mpmapping_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...
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.Originally posted by gvm:
ammm...
I cannot use fragment_programs, because of my gf2gts.
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).]
Posting Permissions
