I think GL lights are too slow for a program The best thing to do is create a light class and calculate every vertex color depending on the distance from every light (could be made faster by bounding boxes also). (Would be per vertex lighting) It works in an awesome way for textured objects and it''s way faster. It''s even cooler knowing if lights don''t move, then, lighting on static object does not have to be recalculated. I just think this is the best way (if you use a lot of bounding boxes (or an octree like stuff)). Anyone uses lights a different way ?

i like to use diffuse lighting:

color*=dotproduct(vertex.normal,normalized(light.pos-vertex.pos));

no distance attentuation..

but mostly i like do all this per pixel (with my nice little geforce2mx )

and even more i like raytracing (real per pixel lighting.. reflections and all this.. all you need is a fastenough pc (700mhz athlon smoothed like chicken..)and the SDL.dll.. (i can give the dll, too)and its running, even with no assembleroptimations..

ok, ihave ONE assembler optimation:

  float __forceinline __fastcall sqr(float f){	__asm{		fld f		fsqrt		fstp f	}	return f;}  

usefull for everyone i think

we wanna play, not watch the pictures

SKSlayer,

Don''t you mean Lightmaps, those things you calculate when you, for instance, are finished building a Quake map and wants them converted into the file format which quake can use (.BSP).

No I mean really to compute the amount of light per vertex
no lightmaps, real software lighting, unlimited lights

www.flipcode.com has a good tutorial on doing your own lighting. The results should be similar to gl''s lighting but you can precalculate the lighting for static objects and use lightmaps and a few gl lights to add dynamic lighting. USE LIGHT MAPS.

Slayer you''re joking, don''t you ?

With hardware lighting there''s no reason not to use vertex lighting, using your brain you can make it way faster than it really is.

And BTW I do think you already know the design of the OctoPort engine about Lighting


-* So many things to do, so little time to spend. *-

I absolutely don''t agree.
If you pregenerate lighting per vertex for static object with static lighting, and use a RGB value per vertex, there is no call to HW lighting, and it will be faster anyway as there is no computing at all.

Well, it wouldn''t work well for insides, but, for outsides, it would be very very good. Expecially because landscapes are static

I agree with SKSlayer, i also find gl''s lighting difficult to manage, and have already implemented diffuse lighting, which does a pretty damn good job.

- Wav

I agree on the fact that precomputed lighting is faster but then why not using dual texturing since it''s almost free on all 3d cards now...

You can still use GL Lights for dynamic lighting, and managing them a bit you could get faster results than letting OpenGL do stupid useless computations.
(And trust me all 3d api are doing lots of useless computation)

I''m working on a fully dynamic engine, and so don''t want to use any static lighting...

-* So many things to do, so little time to spend. *-

--vertex lighting has nothing to do with lightmaps--
where the lightsource does not move its faster to precomputer and store the vertices colours than let opengl calculate the lighting for u.
in cases where the lights do move eg fireball
mytesting on a non hardware tnl shows that calculating the lighting takes about the same speed as opengl does, even though its the same speed with the cost of the extra cpu cycles ild tend to use the opengl lighting.

if u have hardware tnl lighting in practically all cases is opengl gonna do quicker lighting than u can

http://members.xoom.com/myBollux