- FieldTrip - Haskell.org

Fwd: [Fieldtrip] Lighting Patch for Fieldtrip
by David Sankel 07 Jan '09

07 Jan '09

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

3 5

Lighting in FieldTrip
by Conal Elliott 07 Jan '09

07 Jan '09

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 >

1 0

Lighting Patch for Fieldtrip
by David Sankel 07 Jan '09

07 Jan '09

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

2 3

A non-reactive animation-only adapter for FieldTrip
by David Sankel 05 Jan '09

05 Jan '09

In case anyone might find it useful. See comments at the top of LegacyAdapterAnim.hs and code in examples.hs. -- David Sankel

1 0

Re: Adding lighting to FieldTrip
by Ivan Tomac 12 Dec '08

12 Dec '08

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

2 1

Adding lighting to FieldTrip
by David Sankel 11 Dec '08

11 Dec '08

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

3 3

Re: [HOpenGL] noticing freeglut vs not
by Conal Elliott 07 Dec '08

07 Dec '08

Thanks for the pointers. I'm looking for some way to program my library so that a graceful exit is made where possible and still runs, though exits less gracefully with non-free glut. I'd be happy with either a new API entry for that case or a change to the meaning of MainLoopReturns. - Conal On Thu, Nov 20, 2008 at 5:33 AM, Sven Panne <sven.panne(a)aedion.de> wrote: > On Thursday 13 November 2008 03:24:29 Conal Elliott wrote: > > I'm looking for a way to use MainLoopReturns when freeglut is present and > > not when it isn't. I could use some help. I figure that the > > implementation has some way to generate that error message, and maybe we > > could similarly just do a standard ungraceful exit if freeglut is > missing. > > > > The great thing about MainLoopReturns is that it plays nicely with ghci. > > Closing a window returns to ghci for more fun. > > > > Some more info at http://trac.haskell.org/FieldTrip/ticket/8 . > > > > Any ideas? > > Currently the GLUT binding uses dynamic lookup to get freeglut-only API > entries (see /GLUT/Graphics/UI/GLUT/Extensions.hs, cbits/HsGLUT.c, > include/HsGLUTExt.h) and uses throwIfNull to test for non-existent API > entries. Therefore, e.g. actionOnWindowClose should throw an exception when > "classic" GLUT is used. I am not sure if I understand your request: Do you > want a new API entry for the GLUT binding or a different behavior of the > current entries? > > Cheers, > S. > >

2 4

Re: [reactive] windowPoint function in Reactive/GLUT/SimpleGL.hs
by Peter Verswyvelen 01 Dec '08

01 Dec '08

Ah yes, true, I only used this function for orthographic (aka parallel) projection. With perspective projection, it makes more sense to return a ray, not a point. With this ray, one can do all kinds of intersections. One could use the Z-buffer to figure out the closest object, but reading from the z-buffer with the CPU is rather slow, and might be rather inaccurate, but for testing purposes, that might work fine. I guess it all comes down to what kind of "picking" interface one wants. It certainly would be nice to have an Event in reactive-fieldtrip for picking objects :) Since most (if not all?) geometry in fieldtrip is procedural, picking could be made exact? On Mon, Dec 1, 2008 at 3:28 PM, David Sankel <camior(a)gmail.com> wrote: > It looks like Peter's function assumes a parallel projection where the > camera is facing -z. I wonder what would be useful in a 3 dimensional space. > I can imagine the following scenarios with mapping mouse coordinates: > > - Intersection of the ray of that pixel's position/direction in 3D > coordinates with the XY, YZ, or XZ planes depending on the camera position > and type (parallel or perspective). > - Intersection of the ray of that pixel's position/direction and an > object that it touches. If it doesn't intersect an object it could either > return a point at infinity or an intersection with a plane. > > Implementation would probably involve inspection of the z buffer at that > pixel along with Peter's reverse projection. What would a nice interface > look like? > > David > > > 2008/11/29 Peter Verswyvelen <bugfact(a)gmail.com>: > > > The windowPoint function in Reactive/GLUT/SimpleGL.hs has the following > > comment: > > -- | Convert a window position to a logical X,Y. Logical zero is at the > > -- origin, and [size??]. > > -- > > -- TODO: this def is completely broken. What do I even want? Probably > to > > -- go backward through the viewing transform to the XY plane. > > The function I made in the past for doing this is: > > > > windowPoint :: GL.Position -> IO (Double,Double) > > windowPoint pos(a)(GL.Position x y) = > > do > > viewport(a)(_,GL.Size _ height) <- get GL.viewport > > modelviewMatrix <- getMatrix $ GL.Modelview 0 > > projectionMatrix <- getMatrix $ GL.Projection > > let pos3 = GL.Vertex3 (fromIntegral x) (fromIntegral (height-y)) 0 > > GL.Vertex3 vx vy _ <- GLU.unProject pos3 modelviewMatrix > > projectionMatrix viewport > > return (vx,vy) > > where > > getMatrix :: GL.MatrixMode -> IO(GL.GLmatrix Scalar) > > getMatrix mode = get $ GL.matrix $ Just mode > > > > > > _______________________________________________ > > Reactive mailing list > > Reactive(a)haskell.org > > http://www.haskell.org/mailman/listinfo/reactive > > > > > > > > -- > David Sankel >

1 0

windowPoint function in Reactive/GLUT/SimpleGL.hs
by Conal Elliott 01 Dec '08

01 Dec '08

forwarding from reactive(a)haskell.org : ---------- Forwarded message ---------- From: David Sankel <camior(a)gmail.com> Date: 2008/12/1 Subject: Re: [reactive] windowPoint function in Reactive/GLUT/SimpleGL.hs To: Peter Verswyvelen <bugfact(a)gmail.com> Cc: reactive(a)haskell.org It looks like Peter's function assumes a parallel projection where the camera is facing -z. I wonder what would be useful in a 3 dimensional space. I can imagine the following scenarios with mapping mouse coordinates: - Intersection of the ray of that pixel's position/direction in 3D coordinates with the XY, YZ, or XZ planes depending on the camera position and type (parallel or perspective). - Intersection of the ray of that pixel's position/direction and an object that it touches. If it doesn't intersect an object it could either return a point at infinity or an intersection with a plane. Implementation would probably involve inspection of the z buffer at that pixel along with Peter's reverse projection. What would a nice interface look like? David 2008/11/29 Peter Verswyvelen <bugfact(a)gmail.com>: > The windowPoint function in Reactive/GLUT/SimpleGL.hs has the following > comment: > -- | Convert a window position to a logical X,Y. Logical zero is at the > -- origin, and [size??]. > -- > -- TODO: this def is completely broken. What do I even want? Probably to > -- go backward through the viewing transform to the XY plane. > The function I made in the past for doing this is: > > windowPoint :: GL.Position -> IO (Double,Double) > windowPoint pos(a)(GL.Position x y) = > do > viewport(a)(_,GL.Size _ height) <- get GL.viewport > modelviewMatrix <- getMatrix $ GL.Modelview 0 > projectionMatrix <- getMatrix $ GL.Projection > let pos3 = GL.Vertex3 (fromIntegral x) (fromIntegral (height-y)) 0 > GL.Vertex3 vx vy _ <- GLU.unProject pos3 modelviewMatrix > projectionMatrix viewport > return (vx,vy) > where > getMatrix :: GL.MatrixMode -> IO(GL.GLmatrix Scalar) > getMatrix mode = get $ GL.matrix $ Just mode > > > _______________________________________________ > Reactive mailing list > Reactive(a)haskell.org > http://www.haskell.org/mailman/listinfo/reactive > > -- David Sankel _______________________________________________ Reactive mailing list Reactive(a)haskell.org http://www.haskell.org/mailman/listinfo/reactive

1 0

Re: [reactive] Transforming Behaviors
by Conal Elliott 25 Nov '08

25 Nov '08

The instances would get added to the reactive-fieldtrip package. That package is currently very small, but I anticipate lots of goodies going in that relate to the combined use of Reactive and FieldTrip. On Mon, Nov 24, 2008 at 11:18 AM, Conal Elliott <conal(a)conal.net> wrote: > Hi Greg, > > I don't think anyone has implemented an instance for static transformations > of dynamic geometry. Ought to be easy, though. Also dynamic transformation > of static geometry and dynamic transformation of dynamic geometry. And the > corresponding three additional instances for 2D geometry. All six would be > very useful. > > So I don't forget, would you please submit a ticket to either > http://trac.haskell.org/reactive or http://trac.haskell.org/FieldTrip ? > > You might also enjoy adding these instances yourself. Patches are very > welcome. > > Thanks, - Conal > > > On Mon, Nov 24, 2008 at 10:27 AM, Greg Fitzgerald <garious(a)gmail.com>wrote: > >> Should it be possible to write this: >> >> spinningTorusPair :: Double -> Behavior Geometry3 >> spinningTorusPair sz = uscale3 sz *% spinningG torusPair >> >> Instead of this: >> >> spinningTorusPair :: Double -> Behavior Geometry3 >> spinningTorusPair sz = (uscale3 sz *%) <$> spinningG torusPair >> >> >> That is, should a Behavior of something transformable be an instance >> of Transform as well? Has anyone tried to implement this instance? >> >> Thanks, >> Greg >> _______________________________________________ >> Reactive mailing list >> Reactive(a)haskell.org >> http://www.haskell.org/mailman/listinfo/reactive >> > >

2 4