Jump to content


Per pixel lighting without register combiners


20 replies to this topic

#1 Vifani

    New Member

  • Members
  • PipPip
  • 22 posts

Posted 11 September 2003 - 04:20 PM

Hi guys,

someone have some ideas about how realize a per pixel lighting model in OpenGL without using nVidia register combiners ?

#2 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 11 September 2003 - 06:11 PM

if you don't want to use register combiners you're not in for fragment programs as well, right ? but first of all... why do you need to do this ?
If Prolog is the answer, what is the question ?

#3 Vifani

    New Member

  • Members
  • PipPip
  • 22 posts

Posted 11 September 2003 - 10:22 PM

I have an ATi Radeon 9800 Pro graphic card so I can't use nVidia Registers Combiner.

I want to realize a good lighting system for my game engine and I have decided to use a per pixel lighting instead of per vertex light and lightmap that I think are obsolete.

#4 Dia

    DevMaster Staff

  • Administrators
  • 1120 posts

Posted 11 September 2003 - 10:48 PM

Well, you don't have to use the nVidia register combiners. You can simply use normal vertex and fragment shaders.

If you are implementing Phong lighting, check this link.

Hope it helps.

#5 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 12 September 2003 - 12:22 AM

i have several fragment shader implementations ready for different lighting models. i was going to use them in my demo, which i won't be able to complete. so if you want to see them feel free to contact me...
If Prolog is the answer, what is the question ?

#6 davepermen

    Senior Member

  • Members
  • PipPipPipPip
  • 1306 posts

Posted 12 September 2003 - 09:47 AM

just run ARB_fragment_program. its great, and on all new radeons and gfFX cards supported.
davepermen.net
-Loving a Person is having the wish to see this Person happy, no matter what that means to yourself.
-No matter what it means to myself....

#7 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 12 September 2003 - 09:32 PM

even on gf4 i think
If Prolog is the answer, what is the question ?

#8 davepermen

    Senior Member

  • Members
  • PipPipPipPip
  • 1306 posts

Posted 13 September 2003 - 11:30 PM

no. gf4 cannot run it.

reason one: it does not have floatingpoint but only 9bit fixedpoint math (or 10bit)
reason two: it cannot excecute that much instructions
reason three: it cannot do programable texture fetches, only confiruable predefined settings, and thats it

but the main reason: its no dx9 card. because ARB_fragment_program == ps2.0
davepermen.net
-Loving a Person is having the wish to see this Person happy, no matter what that means to yourself.
-No matter what it means to myself....

#9 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 13 September 2003 - 11:39 PM

oi mate, my per pixel lighting code just ran on a gf4 using the ARB_fragment_program extension. i saw it and for once i believe my eyes
If Prolog is the answer, what is the question ?

#10 baldurk

    Senior Member

  • Members
  • PipPipPipPip
  • 1057 posts

Posted 14 September 2003 - 02:12 PM

from my glxinfo output:

OpenGL renderer string: GeForce4 Ti 4600/AGP/SSE/3DNOW!
OpenGL version string: 1.4.0 NVIDIA 43.49
OpenGL extensions:
  GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multisample, 
  GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, 
  GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
  GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
  GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, 
  GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, 
  GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, 
  GL_S3_s3tc, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
  GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, 
  GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, 
  GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, 
  GL_EXT_rescale_normal, GL_EXT_secondary_color, 
  GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, 
  GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture3D, 
  GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, 
  GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
  GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
  GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, 
  GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, 
  GL_HP_occlusion_test, GL_IBM_texture_mirrored_repeat, 
  GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color, 
  GL_NV_depth_clamp, GL_NV_fence, GL_NV_fog_distance, 
  GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, 
  GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, 
  GL_NV_point_sprite, GL_NV_register_combiners, GL_NV_register_combiners2, 
  GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, 
  GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_texture_shader, 
  GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_array_range, 
  GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, 
  GL_NVX_ycrcb, GL_SGIS_generate_mipmap, GL_SGIS_multitexture, 
  GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow

So anubis, you must be mistaken. Unless you were running in software mode.
baldurk
He who knows not and knows that he knows not is ignorant. Teach him.
He who knows not and knows not that he knows not is a fool. Shun him.

#11 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 14 September 2003 - 05:03 PM

i swear to god i saw it running on a gf4 smoothly...
If Prolog is the answer, what is the question ?

#12 Vifani

    New Member

  • Members
  • PipPip
  • 22 posts

Posted 14 September 2003 - 10:56 PM

Hi guys,

I have some news for you. I have used Cg for a simple Per Pixel lighting system (specular + diffuse) and it works very well.

#13 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 14 September 2003 - 11:18 PM

i have tried using cg but droped it again...
you should rather rely on fragmen/vertex programs. you could use the cg compiler to generate those and hand optimize them. please don't use the cg runtime. also writing the assembler programs isn't much harder if you are used to it, believe me. i won't touch a hlsl again until glslang is out.
If Prolog is the answer, what is the question ?

#14 Noor

    Senior Member

  • Members
  • PipPipPipPip
  • 503 posts

Posted 15 September 2003 - 02:13 AM

Why? What's wrong with Cg?
"What ever happened to happily ever after?"

#15 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 15 September 2003 - 03:05 AM

- their runtime library sux ( imo ). it's way overcomplicated for no good reason
- it's still buggy
- looking at the glslang spec you will notice that it's design is much clearer
- overall CG is just a big PR campaing to promte nvidias line of gforce cards
If Prolog is the answer, what is the question ?

#16 Noor

    Senior Member

  • Members
  • PipPipPipPip
  • 503 posts

Posted 15 September 2003 - 03:28 AM

But Cg supports both OpenGL and DirectX.
glslang is only for opengl.

ain't I right?
"What ever happened to happily ever after?"

#17 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 15 September 2003 - 03:34 AM

i was being ignorant about DirectX since i don't use it... you are right if you want to write shaders for both you could make use of cg... but still i would use it just as a compiler and run the generated shaders after i went through them by hand
If Prolog is the answer, what is the question ?

#18 Vifani

    New Member

  • Members
  • PipPip
  • 22 posts

Posted 15 September 2003 - 07:51 AM

I think Cg is very easy to use. I have implementated a per pixel lighting (diffuse + specular without bump mapping) in only 3 hours. So I haven't found it overcomplicated.

Where can I find glslang spec ?

#19 baldurk

    Senior Member

  • Members
  • PipPipPipPip
  • 1057 posts

Posted 15 September 2003 - 05:34 PM

Unless it's changed since I checked, the Cg toolkit for linux is terrible. The documentation also seemed quite poor, although to be fair I didn't really look into that much after the toolkit. Assuming this is still true, this negates the quality of OpenGL I like (second) best - portability. GLSlang will be true OpenGL, and won't require any additional libraries. I never like having too many libraries hanging around.
baldurk
He who knows not and knows that he knows not is ignorant. Teach him.
He who knows not and knows not that he knows not is a fool. Shun him.

#20 CyraX

    Valued Member

  • Members
  • PipPipPip
  • 144 posts

Posted 04 October 2003 - 07:22 AM

baldurk you are right about only a part of the complaint regarding the CG tookit for GNU/LINUX. The documentation is bad wrt getting CG started on GNU/Linux. The rest of it is just a matter of being able to read thru the standard CG Toolkit pdf.

However you should understand one thing - CG is not supported for Fragment shaders (or pixel shaders) by ATI. So that puts you pretty much in a fix.
Cg is elegant yes. It helps in faster coding - not really.
GLSlang - find it in opengl.org its a link on the right.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users