[Fieldtrip] Lighting Patch for Fieldtrip

[David Sankel]

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

[Conal Elliott]

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

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

[Conal Elliott]

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.

   - Conal

[David Sankel]

On Tue, Jan 6, 2009 at 6:33 PM, Conal Elliott <co...@conal.net> wrote:
> Thanks, David! I'm glad for lights in FieldTrip. The code looks mostly
> good to me. A few comments:

<snip>

> Would you mind addressing these issues and resending?

Thanks for the suggestions. I also wanted renderLightsIO to be in
unary style, but didn't think of using >=>.

My work at the moment is switching directions so I won't be continuing
with this at the moment. Maybe someone else would be interested in
making these changes?

> Happy new year,

Thanks. Same to you & your family.

- David

[David Sankel]

Oops, forgot to "reply to all".

---------- Forwarded message ----------
From: David Sankel <cam...@gmail.com>
Date: Wed, Jan 7, 2009 at 9:06 AM
Subject: Re: [Fieldtrip] Lighting Patch for Fieldtrip
To: Conal Elliott <co...@conal.net>

On Tue, Jan 6, 2009 at 10:43 PM, Conal Elliott <co...@conal.net> 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.

David

[Ivan Tomac]

Hi David,

David Sankel wrote:
> On Tue, Jan 6, 2009 at 10:43 PM, Conal Elliott <co...@conal.net> 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

[David Sankel]

On Wed, Jan 7, 2009 at 10:31 AM, Ivan Tomac <to...@pacific.net.au> wrote:
> 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

[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

[Ivan Tomac]

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

Regards,

[Conal Elliott]

Thanks, Ivan.  This is the kind of simplicity/generality/GPU-friendliness I'm looking for.  - Conal