Hi,
I’m currently coding per-texel lighting in my engine, and I’m going to write many different path for each 3d card. I would like to know why gf3/4 and radeon don’t support the gl_arb_fragment_program, I mean there is pixel shader 1.0 (even 1.3 for radeon) accelerated in hardware on such card in Direct3d. Why with OpenGL, we have to hand code this via ati and nv extension (register combiner, etc …)? I know there is gl_arb_tex_combine but it is less powerfull than register combiner, particulary when per-texel lighting (i.e specular exponent). And Cg (from nvidia) doesn’t support ati extension (incredible is it?) in spite of this is a good idea.
Does anyone know if there is a solution? or solution planned (new driver or arb extension)??
Yes, pixel shaders are supported on GF3/4/Radeon. But they do not all support the same instruction set. Some instructions are not available to have full GL_ARB_fragment_program support. That’s why they implement a sub-set instructions specifically, with extensions.
GL_ARB_fragment_program is much more advanced than DX8 pixel shaders. The closest match is probably DX9’s ps 2.0.
Radeon8500 and GeForce4 have pixel shader capabilities, but the ARB_fragment_program extension goes beyond.
What could be done is an ARB_fragment_program_limited extension that would allow hardware pixel shading capabilities but I doubt this will ever exist since pixel shader capabilities are already exposed via vendor-dependant extension.
So in conclusion, as most user don’t have a DX9 video card class, I must code different for each type of card (GF1/2/2MX, GF3/4, GF FX, radeon 8500, and 9700). BTW thanks you for you answers, I’m just a little bit angry about openGL (but I like it ;-)) cause I don’t own a radeon, and I will have to “blind code”.
I’m sure the community will be more than welcome to test your effects on Radeon graphics card. The point being, you have to be able to provide a preview of what you’re developing, which is a problem for commercial software.
An ARB_texture_shader extension would be nice. (But I’ll digress before this turns into another “where are the ARB notes thread”. Which of course will lead to “how about ARB_VAO” questions)
Is everyone out there writing 4 different paths? Geforce1/2, Geforce3/4, Radeon7xxx, Radeon8xxx. Well 5 different paths with ARB_fp.
What is everyone doing to get per-pixel lighting with a reasonable number of paths while supporting all Geforce and Radeon level cards?
The ARB_VAO and-the-like are always being discussed. Don’t think anything’s forgotten. Just be patient.
Actually, I’d rather say that 2 path is the most common : NVIDIA for register_combiners/vertex_array_range/etc and ATI for texture_env_bumpmap/vertex_array_object/etc.
Actually per-pixel lighting can be vendor-independant thanks to the ARB_texture_env_dot3 and ARB_texture_cube_map . It’s a bit better to use register combiners or fragment shaders, but it’s not really needed.
Originally posted by vincoof:
Actually per-pixel lighting can be vendor-independant thanks to the ARB_texture_env_dot3 and ARB_texture_cube_map . It’s a bit better to use register combiners or fragment shaders, but it’s not really needed.
Hmm, can you do specular ppl with just ARB_texture_env_dot3 and ARB_texture_cube_map? I don’t know if I can calculate 4x(H.N - .75)^2 using glTexEnv. I think I should go read the spec again and see if I can work it out.
I’ve written a (little awful) per-pixel lighting demo with those extensions a while ago. My web space has been deleten (damn free hosts they think they have all rights since they’re free) so I don’t have it online anymore but I could send it by email if you want.
The specular term needs (much) more passes than register combiners but still it’s possible.
Originally posted by PK: Hmm, can you do specular ppl with just ARB_texture_env_dot3 and ARB_texture_cube_map? I don’t know if I can calculate 4x(H.N - .75)^2 using glTexEnv. I think I should go read the spec again and see if I can work it out.