Are there any plans to add rich 2D rendering support to fieldtrip?
So that we can have text, lines, fills, curves etc?
So that we can get rid of the Render monad in GTK and other libs?
Thanks,
Peter
Oops, forgot to "reply to all".
---------- Forwarded message ----------
From: David Sankel <camior(a)gmail.com>
Date: Wed, Jan 7, 2009 at 9:06 AM
Subject: Re: [Fieldtrip] Lighting Patch for Fieldtrip
To: Conal Elliott <conal(a)conal.net>
On Tue, Jan 6, 2009 at 10:43 PM, Conal Elliott <conal(a)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
>
> - Conal
>
> On Tue, Jan 6, 2009 at 3:33 PM, Conal Elliott <conal(a)conal.net> 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 <camior(a)gmail.com> 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(a)haskell.org
>>> http://www.haskell.org/mailman/listinfo/fieldtrip
>>>
>>
>
>
--
David Sankel
I second David's invitation, widening it to the list. If you have ideas
about interfaces for lighting, please chime in. Particularly, elegant,
general, functional (unlike the usual steful GL & scene-graph models), and
GPU-friendly.
A model (denotational semantics) and interface for lights is given in the
paper "Programming Graphics Processors Functionally" (
http://conal.net/papers/Vertigo/) As Ivan also suggested, a light is a
function.
- Conal
On Wed, Jan 7, 2009 at 8:30 AM, David Sankel <camior(a)gmail.com> wrote:
> On Wed, Jan 7, 2009 at 10:31 AM, Ivan Tomac <tomac(a)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
> _______________________________________________
> FieldTrip mailing list
> FieldTrip(a)haskell.org
> http://www.haskell.org/mailman/listinfo/fieldtrip
>
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
