[Fieldtrip] Adding lighting to FieldTrip

[David Sankel]

Hello All,

I'm working on adding lighting to the FieldTrip library (ticket http://trac.haskell.org/FieldTrip/ticket/16). I have some initial data types here:

http://hpaste.org/12975

I'm thinking that the GContext will keep track of which of the 8 opengl lights are used and enable them if they are.

I was wondering what ideas folks have had with lighting. Some issues that are on my mind:

• OpenGL limits the number of lights to 8.
• It would be nice, for a spotlight primitive, to allow the light's position and a point it is pointing toward to go through different transformations. This would allow a fixed light to follow an object, for example. I don't know yet how to provide this functionality.
  

Thanks,

David

[Conal Elliott]

In TBAG, ActiveVRML/DirectAnimation, and Fran, I embedded lights into geometry, which allows them to be spatially transformed.  Looking in Graphics.FieldTrip.Geometry3, you'll see a comment placeholder for lights.

OpenGL is a temporary implementation convenience, so I wouldn't design the API around it.  If more lights get added to a geometry than the current implementation can handle, we can document the limitation and drop some of them at run-time.

  - Conal

_______________________________________________
FieldTrip mailing list
Fiel...@haskell.org
http://www.haskell.org/mailman/listinfo/fieldtrip

[Peter Verswyvelen]

I'm think 8 is the minimum number of lights hardware must support to be OpenGL compiant, but hardware can support more.

Most games use some kind of "light virtualization technique", were any number of lights are allowed but only the closest lights are used for doing the shading.

I'm not sure if the maximum number of lights applies when using custom GPU shaders... 

[David Sankel]

On Thu, Dec 11, 2008 at 4:43 PM, Peter Verswyvelen <bug...@gmail.com> wrote:

I'm think 8 is the minimum number of lights hardware must support to be OpenGL compiant, but hardware can support more.

Most games use some kind of "light virtualization technique", were any number of lights are allowed but only the closest lights are used for doing the shading.

Thanks for the input Peter (& Conal).
 

I'm not sure if the maximum number of lights applies when using custom GPU shaders... 

I looked into this. An example shader application [1] used normal glLight* commands to set up the lighting.  This tutorial [2] shows that shaders have access the light information via. the gl_LightSource array and have the option to use it or not. I can imagine someone defining unlimited light parameters with uniform variables in glsl if they really wanted to.

[1] http://cs.anu.edu.au/Student/comp4610/2007/labs/gpu.html
[2] http://www.clockworkcoders.com/oglsl/tutorial5.htm

David

[Ivan Tomac]

Hi David,

Adding lighting in this way makes sense for the fixed function OpenGL
pipeline but it is too restrictive and redundant for shaders.
gl_LightSource was provided in GLSL for backwards compatibility, mostly
for those who want to add shaders to their existing applications that
use legacy OpenGL.

With shaders, rather than rely on several fixed functions for lighting
it is now possible to implement all kinds of different forms of lighting
and the 8 light limitation of the fixed function pipeline is no longer
there either.

One final thing to note is that as of OpenGL 3.0, all lighting functions
have been deprecated.

Regards,

Ivan

>> I'm not sure if the maximum number of lights applies when using
custom GPU
>> shaders...
>>
>
> I looked into this. An example shader application [1] used normal
glLight*
> commands to set up the lighting. This tutorial [2] shows that
shaders have
> access the light information via. the gl_LightSource array and have the
> option to use it or not. I can imagine someone defining unlimited light
> parameters with uniform variables in glsl if they really wanted to.
>
> [1] http://cs.anu.edu.au/Student/comp4610/2007/labs/gpu.html
> [2] http://www.clockworkcoders.com/oglsl/tutorial5.htm
>
> David

[Peter Verswyvelen]

Thanks Ivan! 

If the Khronos group had the courage to make OpenGL 3.0 a complete redesign as DirectX 10 was, it would all be much easier wouldn't it?