- HOpenGL - Haskell.org

Fwd: [Haskell] ANNOUNCE: OpenGL 2.3.0.0
by Sven Panne 30 Jul '09

30 Jul '09

[ Ooops, I forgot to CC: to the HOpenGL mailing list... ] ---------- Weitergeleitete Nachricht ---------- Betreff: [Haskell] ANNOUNCE: OpenGL 2.3.0.0 Datum: Mittwoch, 29. Juli 2009 Von: Sven Panne <Sven.Panne(a)aedion.de> An: Haskell Mailing List <haskell(a)haskell.org> A new version of the OpenGL package has bee uploaded to Hackage. The main change is that it is now only a convenience layer upon the OpenGLRaw and GLURaw packages, written in in pure Haskell without the FFI. The latter two packages load the native libraries dynamically and do not rely on any C headers, making it possible to build all OpenGL-related packages even on machines without any installed native OpenGL support. Apart from that, a bug in vertexAttribPointer has been fixed. Cheers, S.

1 0

ghci + glut + osx broken?
by Conal Elliott 29 Jul '09

29 Jul '09

When I run a glut progam in os x under ghci, I get strange behavior, including a blank white title bar (no red/orange/green buttons and no title). If I compile with ghc --make and run, i get a normal title bar. Asking on #haskell today [1], I hear that glut and ghci don't get along on os x. What's known about this problem? Is it fixable? I get a lot of value out of having a REPL, so I hope there's a solution. Thanks, - Conal [1] http://tunes.org/~nef/logs/haskell/09.07.26

5 4

Pure, garbage-collected graphics resources
by Conal Elliott 23 Jul '09

23 Jul '09

I'd like to use some OpenGL resources (VBOs, textures, shaders, and shader programs) in a functional way, with immutability, garbage collection, and IO-free creation interfaces. Has anyone played with doing such a thing? I guess the GC part would involve foreign pointers with foreign finalizers (which now run promptly in GHC iiuc). I don't know of any reliable way to add finalizers to Ptr values, because of the unboxing problem [1]. One tricky issue is that graphics context initialization must take place before any of these "pure" resources get evaluated. If the APIs allowed access to to multiple graphics contexts, things would get stickier. Comments? - Conal [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.…

5 7

vertexAttribPointer undefined?
by Conal Elliott 18 Jul '09

18 Jul '09

I found this code in Graphics.Rendering.OpenGL.GL.VertexArrays in the OpenGL package, version 2.2.3.0: vertexAttribPointer :: AttribLocation -> StateVar (IntegerHandling, VertexArrayDescriptor a) vertexAttribPointer location = undefined makeStateVar (getVertexAttribPointer_ location) (setVertexAttribPointer location) Is that "undefined" intentional? When I remove "undefined", it works fine. - Conal

2 1

Querying GL info, including # of texture units.
by Conal Elliott 06 Jul '09

06 Jul '09

I'm looking for a way to query the number of available texture units to shaders. In C, I think the value can be extracted with glGetIntegerv<http://www.opengl.org/sdk/docs/man/xhtml/glGet.xml>passing in GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS. There are also getInteger1 and GetMaxCombinedTextureImageUnits in Graphics.Rendering.OpenGL.GL.QueryUtils, but that module isn't exported from the OpenGL package. Have I missed something? - Conal

2 1

ANNOUNCE: Cal3D animation library
by Gregory D. Weber 27 Jun '09

27 Jun '09

The Cal3D for Haskell project provides a partial binding to the C++ Cal3D animation library. The project homepage is http://haskell.org/haskellwiki/Cal3d_animation There are three packages available on hackage: * cal3d-0.1 is a Haskell binding to the Cal3D library itself. * cal3d-opengl-0.1 adds a few functions for using Cal3D with OpenGL. * cal3d-examples-0.1 provides a simple example based on the Cally Demo. Cal3D is a C++ library for skeletal-based character animation. It is platform-independent and independent of any particular graphics API. In fact, it does not actually render the animation, but provides hooks that the graphics API (such as OpenGL) can use to do the actual drawing. (As far as I know, though, the only graphics API available for Haskell is OpenGL.) For more information about the (C++) Cal3D library, please see * Cal3D FAQ: http://cal3d.sourceforge.net/docs/api/html/cal3dfaq.html * Cal3D Homepage: http://home.gna.org/cal3d/ -- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550

1 0

Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
by Tillmann Vogt 23 Jun '09

23 Jun '09

Sven Panne schrieb: > Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: >> [...] I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems >> redundant to me. [...] > > I forgot to mention one thing here: "OpenGL.GL" is currently *not* redundant, > there is "OpenGL.GLU" in the OpenGL package, too. GL and GLU are separate > libraries, even living in separate DLLs/*.sos, having separate headers, etc., > so they should be kept separate in Haskell at some level, too. > > Nevertheless, with OpenGL 3.1 GLU is dead, Are you sure? glu is mainly for converting an arbitrary polygon into triangles. This is an art and so obviously wasn't put into hardware or driver. From a previous post I remember that tesselation was mentioned. But looking at some presentation slides from AMD/ATI I understand that tesselation in directx11 is using the following primitive patches: Triangles and Tri-patches, Quads and Quad Patches, Lines and Line Patches, see http://ati.amd.com/developer/gdc/2008/Tatarchuk-Tessellation_GDC08.pdf slide 31. I haven't found a lot of information in the OpenGL 3.1 Spec, so I assume they will do it similar to directx11. So, if glu is still needed, until I use a better algorithm in my library. > anyway, so in future versions there > will be no ".GL" part in the package names. > > Cheers, > S. > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

3 2

Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
by Sven Panne 17 Jun '09

17 Jun '09

Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan: > Since this is a new package, is there any possibility that the naming could > be more economical? > > Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long. > > I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems > redundant to me. I'd very much like to encourage the idea that tremendously > long package names ought to be considered poor form. While I consider this a bit long, too, there are a few reasons why it was done this way. The OpenGLRaw package exports 1025 functions, 1673 tokens and 20 types, so one clearly needs some way of structuring this, the only question is how. You rarely import on such a fine-grained level, most of the time you simply use the rather short import Graphics.Rendering.OpenGL import, where you can even add "as GL" if you like for short explicit qualification later. Another example: If you explicitly only want to use pure, modern OpenGL 3.1 "the raw way", use: import Graphics.Rendering.OpenGL.Raw.Core31 If you additionally want to use the ARB_compatibility extension, use: import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB.Compatibility If you want the OpenGL 3.1 core plus all ARB extensions, use import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB And if you are very lazy, you can simply pull in the whole raw binding with import Graphics.Rendering.OpenGL.Raw This leaves the decision about the granularity of the import to the user of the package, which is a good thing IMHO. The ".Raw" part is necessary to distinguish between the raw and the nice interface, leaving the dot out or replacing it with "_" wouldn't really buy us much. One point here is debatable: Do we really need the ".Rendering" part in the package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed the structure of the hierarchy when hierarchical packages were in their infancy, many years ago, and it was consensus then to distinguish between "Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings about ".Rendering" and ".UI", and if the consensus nowadays is to remove it, I'll be happy to change this. But let's move the discussion about this to the libraries mailing list. A few final remarks: Leaving out "Graphics." completely would be a very bad idea, the naming hierarchy should reflect the underlying conceptual hierarchy. The only problem with hierarchies in general is that sometimes the position in it is not very clear. I have e.g. never fully understood why "Monad" and "Applicative" are below "Control", but "Foldable" is below "Data"... Cheers, S.

2 1

[bug] error in unmarshalMouseButton
by Claude Heiland-Allen 17 Jun '09

17 Jun '09

Hi, I'm developing a mouse-driven user interface using HOpenGL/GLUT. However, it sometimes crashes if I'm too clumsy on my laptop's trackpad: $ ./gulci gulci: unmarshalMouseButton: illegal value 5 $ ./gulci gulci: unmarshalMouseButton: illegal value 6 The offending code calls error: --8<-- unmarshalMouseButton :: CInt -> MouseButton unmarshalMouseButton x | x == glut_LEFT_BUTTON = LeftButton | x == glut_MIDDLE_BUTTON = MiddleButton | x == glut_RIGHT_BUTTON = RightButton | x == glut_WHEEL_UP = WheelUp | x == glut_WHEEL_DOWN = WheelDown | otherwise = error ("unmarshalMouseButton: illegal value " ++ show x) --8<-- http://www.haskell.org/ghc/dist/current/docs/libraries/GLUT/src/Graphics-UI… Suggested fix: modify the MouseButton type to have an additional constructor, eg: data MouseButton = ... | OtherMouseButton CInt and handle that case in the obvious way in the (un)marshal code (and suitably adjust any other code that pattern matches on MouseButton) BTW, I noticed I'm not the first to suffer from this crash issue, see for example #haskell IRC log from 2008-05-16. Claude -- http://claudiusmaximus.goto10.org

2 2

ANNOUNCE: OpenGLRaw 1.0.0.0
by Sven Panne 12 Jun '09

12 Jun '09

As a first step to make the OpenGL package easier to install, more modular and a bit more flexible, a low-level binding for OpenGL has been uploaded to Hackage. From OpenGLRaw's package description: ------------------------------------------------------------ OpenGLRaw is a raw Haskell binding for the OpenGL 3.1 graphics system and lots of OpenGL extensions. It is basically a 1:1 mapping of OpenGL's C API, intended as a basis for a nicer interface. OpenGLRaw offers access to all necessary functions, tokens and types plus a general facility for loading extension entries. The module hierarchy closely mirrors the naming structure of the OpenGL extensions, making it easy to find the right module to import. All API entries are loaded dynamically, so no special C header files are needed for building this package. If an API entry is not found at runtime, a userError is thrown. OpenGL is the industry's most widely used and supported 2D and 3D graphics application programming interface (API), incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. For more information about OpenGL and its various extensions, please see http://www.opengl.org/ and http://www.opengl.org/registry/. ------------------------------------------------------------ Version 1.0.0.0 covers the OpenGL 3.1 core, all ARB extensions and all EXT extensions. Great care has been taken to introduce as few build dependencies as possible, so neither autoconf is required, nor any OpenGL headers. Future versions of the OpenGL package will basically be a convenience layer above this package, but you can always fall back to the raw binding if required. To get a taste for it, have a look at http://aedion.de/haskell/SmoothRaw.hs, which should look extremely familiar to anyone who has used OpenGL's C API. Any feedback is highly appreciated. Cheers, S.

2 2