
Oops, forgot to "reply to all".
---------- Forwarded message ----------
From: David Sankel
Also, I'd also like to see some response to Ivan's last message on the thread "Adding lighting to FieldTrip". I appreciate Ivan's focus on GPU execution, which I hope will soon replace CPU execution in the implementation of FieldTrip. I expect we'll get a quite dramatic boost in performance as well as having more flexibility.
The FieldTrip.Light structure, from a semantic point of view, gives access to a lot of common light models and is independent of the underlying OpenGL operations. If the back-end code is completely replaced with GLSL, it will just be a matter of setting "uniform variables" instead of glLight calls in renderLightIO and possibly expanding the Light structure with more funky light forms. David
- Conal
On Tue, Jan 6, 2009 at 3:33 PM, Conal Elliott
wrote: Thanks, David! I'm glad for lights in FieldTrip. The code looks mostly good to me. A few comments:
* renderLightsIO's 'h' definition could use some prettying up: I'd prefer a unary style (e.g. 'h Empty = return') and using Kleisli composition ((>=>)) for the Union case.
* You've mostly aligned "=", ",", "::", and "$=", which I appreciate, as removing surface irregularities helps me see and fix deeper irregularities. You missed some, in renderLightsIO, pltToGL ("i"), LightType, and a few others. If you look carefully at the .patch, you'll find them all.
* I see lights getting enabled. How do they get disabled?
Would you mind addressing these issues and resending?
Happy new year,
- Conal
On Tue, Jan 6, 2009 at 2:28 PM, David Sankel
wrote: Hello Folks,
I've attached patch that will allow FieldTrip full access to omni, spot, and directional lights with varying parameters. It works much the same way as geometry does. See examples.hs for neat examples (the LegacyAdapterAnim.hs file is required for the examples and is different from the one I posted earlier).
I'll be updating the ticket (http://trac.haskell.org/FieldTrip/ticket/16) shortly.
David
-- David Sankel
_______________________________________________ FieldTrip mailing list FieldTrip@haskell.org http://www.haskell.org/mailman/listinfo/fieldtrip
-- David Sankel

Hi David, David Sankel wrote:
On Tue, Jan 6, 2009 at 10:43 PM, Conal Elliott
wrote: Also, I'd also like to see some response to Ivan's last message on the thread "Adding lighting to FieldTrip". I appreciate Ivan's focus on GPU execution, which I hope will soon replace CPU execution in the implementation of FieldTrip. I expect we'll get a quite dramatic boost in performance as well as having more flexibility.
The FieldTrip.Light structure, from a semantic point of view, gives access to a lot of common light models and is independent of the underlying OpenGL operations.
If the back-end code is completely replaced with GLSL, it will just be a matter of setting "uniform variables" instead of glLight calls in renderLightIO and possibly expanding the Light structure with more funky light forms.
Yes the code behind it could be changed to use shaders and all that would do is emulate legacy OpenGL. These concepts are tied to legacy OpenGL. The lighting models are just simple functions and with shaders they are best represented as such. Ivan

On Wed, Jan 7, 2009 at 10:31 AM, Ivan Tomac
David Sankel wrote:
The FieldTrip.Light structure, from a semantic point of view, gives access to a lot of common light models and is independent of the underlying OpenGL operations.
If the back-end code is completely replaced with GLSL, it will just be a matter of setting "uniform variables" instead of glLight calls in renderLightIO and possibly expanding the Light structure with more funky light forms.
Yes the code behind it could be changed to use shaders and all that would do is emulate legacy OpenGL.
The shaders themselves could render using a variety of styles besides Blinn-Phong using these light structures while also allowing procedural textures and special material simulations like skin. Of course the parameters of a light, specifically the color parameters, may be different for different shader models.
These concepts are tied to legacy OpenGL.
I think the concept of a light (omni/directional) goes beyond OpenGL. The exposed parameters make most sense for Blinn-Phong models which are the most common. Like I mentioned, it would be easy to expand on these structures.
The lighting models are just simple functions and with shaders they are best represented as such.
Perhaps you could post a haskell interface of the alternative light structure you have in mind. I think it'd help the discussion. David -- David Sankel

Hi David, David Sankel wrote:
I think the concept of a light (omni/directional) goes beyond OpenGL.
Sure. As do the concepts of shadows, reflection, refraction, etc, none of which have specialized constructs in OpenGL. You could add them which would increase complexity. An alternative is to get rid of special cases without losing any functionality, quite the opposite in fact. That was hard before shaders but much easier now.
The lighting models are just simple functions and with shaders they are best represented as such.
Perhaps you could post a haskell interface of the alternative light structure you have in mind. I think it'd help the discussion.
A function! Ivan

Formating of my previous email came out horrible - my apologies. It looked fine in Thunderbird. Regards, Ivan

Thanks, Ivan. This is the kind of simplicity/generality/GPU-friendliness
I'm looking for. - Conal
On Wed, Jan 7, 2009 at 9:20 AM, Ivan Tomac
Hi David,
David Sankel wrote:
I think the concept of a light (omni/directional) goes beyond OpenGL.
Sure. As do the concepts of shadows, reflection, refraction, etc, none of which have specialized constructs in OpenGL. You could add them which would increase complexity. An alternative is to get rid of special cases without losing any functionality, quite the opposite in fact. That was hard before shaders but much easier now.
The lighting models are just simple functions and with shaders they are
best represented as such.
Perhaps you could post a haskell interface of the alternative light structure you have in mind. I think it'd help the discussion.
A function!
Ivan
_______________________________________________ FieldTrip mailing list FieldTrip@haskell.org http://www.haskell.org/mailman/listinfo/fieldtrip
participants (3)
-
Conal Elliott
-
David Sankel
-
Ivan Tomac