December 2008 - FieldTrip

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