- HOpenGL - Haskell.org

Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL
by Tillmann Vogt 04 May '09

04 May '09

Sven Panne schrieb: > > * a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class > (In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy > here.) How about Data.GraphicsObjects ? > > * a package containing most of the data types/newtypes in OpenGL's > VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the > base classes like Eq, Ord, Show, etc. I really don't know a good name for this > package and what a good place in the hierarchy would be (probably something > like "Data.Foo", but what is Foo?) Now that you mention it. I just looked through haskell hierachical libraries and there seems to be no standard data types for vector math. Am I getting something wrong or is every library that is using linear algebra stuff using its own data types? So if I use a numeric library for matrices inside HOpenGL I have to convert around? I think it would be nice to have data types and functions for dot produkt, scalar product, norms, ... together with HOpenGL types. Currently I am trying to embed a triangulation library from a ten year old diploma thesis (http://www.dinkla.net/fp/cglib.html) in my libary (I know that glu has tesselation). The author has developed a quite big and abstract type structure for all sorts of computer graphics algorithms and I didn't wanted to copy this into my library just for triangulation. But it is reasonable. It could be combined with HOpenGL types to maybe Data.VectorMath or Data.LinearAlgebra . I would favour the second. > > The point is: The first two package would be very small. Would this be OK? > Does anybody see other alternatives? What would be good names for those > packages and where in the naming hierarchy should they really go? > > Cheers, > S. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

4 4

abstract linear algebra interface (was: Decoupling OpenAL/ALUT packages from OpenGL)
by Balazs Komuves 04 May '09

04 May '09

> These libraries are different in the way they store data and in the > interface. vectors-space is abstract, while your library offers an easier > interface. For example vector-space defines an additive group and an affine > space while you have a function translate3x. No, I too have an additive group (well, it's called AbelianGroup, not AdditiveGroup); translate3 and the like are just utility functions, in a separate module. But yes, I see now that this part of the vector-space interface is actually not that far from mine (though the linear maps part is very different). I think the best would be to have one abstract library. Then hmatrix imports > this library and overloads the functions. > Here are some random questions to think about, regarding a general abstract interface: - do you want to use type families? It's not really portable - what about type inference? The more abstract the interface, the more type annotations the user have to write (for example, with the current OpenGL binding you cannot simply write (Vertex3 1 0 0), which is somewhat annoying). - vectors are bimodules over both scalars and matrices. How would you encode this? If you want to go with the abstract way, you would want modules over rings. But that can be problematic. - are there performance costs associated with the abstraction? - the more concrete the types, the more operations and/or more efficient algorithms are possible. It's pretty hard to encode things like `algorithms working with matrices over principal ideal domains' with the Haskell type system. - what about dense/sparse matrices? How would the interface handle the fact that you would want to have different realizations of the same abstract type in the same program? - clearly one cannot expect a general interface to cover all the possible use cases. How to make it extensible? etc etc. Of course, prove me wrong if you can! I'm not at all against abstraction, just being pragmatic here. Balazs

1 0

FYI: Haskell Platform release candidates
by Claus Reinke 03 May '09

03 May '09

Having stumbled over recent activities on the long-silent Haskell Platform mailing list, I have noticed few OpenGL voices. So, for those here who haven't yet seen the Haskell Platform (HP) discussions: - now is the time to make sure that using OpenGL with Haskell will once again be as easy on all platforms as it used to be before GHC dropped the ball. This is what your clients will use to run your code (at least those clients who don't install OpenGL/GLUT themselves just to try out your code), so it might be a good idea to check that it works on your platforms. - initial release appears imminent, so it is too late to get bug fixes in now, but you could test the installer release candidates. - a bug fix release of the HP seems planned within a few weeks, and Sven is obviously working through old emails/bug reports, prompted by the surprising change in gear for the HP, so this would be a good time to bring out any hidden bug reports, or OpenGL issues with the HP (I understand that Sven's recent patches will be in the first bug fix release of the HP, not in the initial release - HP policy arguments). - I'm not sure whether the HP policy arguments would affect Sven's recent feature additions - they won't be in the initial HP release, but the question is whether they'll be in the planned bug-fix release, soon, or in the next major HP release, which is nowhere near. OpenAL/ALUT seem to be in the latter category, if at all: http://projects.haskell.org/pipermail/haskell-platform/2009-April/000120.ht… http://projects.haskell.org/pipermail/haskell-platform/2009-April/000140.ht… Just thought you might want to know, Claus http://www.haskell.org/haskellwiki/Haskell_Platform http://trac.haskell.org/haskell-platform/wiki/Library/VersionMatrix http://trac.haskell.org/haskell-platform/ Release dates: http://projects.haskell.org/pipermail/haskell-platform/2009-April/000123.ht… Mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Windows installer RC (does *not* include glut32.dll): http://projects.haskell.org/pipermail/haskell-platform/2009-May/000147.html

2 2

Decoupling OpenAL/ALUT packages from OpenGL
by Sven Panne 03 May '09

03 May '09

I'd like to get some feedback from the Haskell community about some packaging issues, so here is my problem: As a medium-term goal, I'd like to decouple the OpenAL/ALUT packages from the OpenGL package, because there are very sensible use cases where you might need some sound, but not OpenGL. The current coupling has mostly historic reasons. The OpenAL package depends on the OpenGL package in 3 areas: * OpenAL uses OpenGL's notion of StateVars all over the place. * OpenAL's Buffer and Source are instances of OpenGL's ObjectName class. * OpenAL's sources and listeners have some properties like velocity, orientation, direction and position which are modeled by OpenGL's Vector3 and Vertex3 data types. The ALUT package depends on the OpenGL package because of GettableStateVars. The packages are supposed to fit nicely together, so using the same types is a must, but the actual packaging is not nice. So the obvious idea is to introduce 3 new packages which lift out functionality from the OpenGL package: * a small "StateVar" package, consisting only of OpenGL's StateVar module (in a better place in the name hierarchy, of course, perhaps "Data.StateVar"?) * a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class (In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy here.) * a package containing most of the data types/newtypes in OpenGL's VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the base classes like Eq, Ord, Show, etc. I really don't know a good name for this package and what a good place in the hierarchy would be (probably something like "Data.Foo", but what is Foo?) The point is: The first two package would be very small. Would this be OK? Does anybody see other alternatives? What would be good names for those packages and where in the naming hierarchy should they really go? Cheers, S.

2 1

ANNOUNCE: GLUT 2.1.2.1
by Sven Panne 03 May '09

03 May '09

A new version of the GLUT package has been uploaded to Hackage. This is a bug fix only release, containing only tiny changes: * Include missing aclocal.m4 and examples in source distribution * Removed unused Makefiles and prologue.txt Cheers, S.

1 0

Fwd: [Haskell] ANNOUNCE: GLUT 2.1.2.0
by Sven Panne 01 May '09

01 May '09

[ Forgot to CC: to the hopengl mailing list... ] ---------- Weitergeleitete Nachricht ---------- Betreff: [Haskell] ANNOUNCE: GLUT 2.1.2.0 Datum: Dienstag, 28. April 2009 Von: Sven Panne <Sven.Panne(a)aedion.de> An: Haskell Mailing List <haskell(a)haskell.org> A new version of the GLUT package has been uploaded to Hackage. This is a feature release, adding all the shiny new features of the upcoming freeglut 2.6.0 C library plus a few older bits and pieces which had been missing: * Minor tweaks for recent Cabal versions * Removal of old GHC build system relics. * Added support for OpenGL 3.x context creation (freeglut only) * Added support for getModeValues (freeglut extension) * Added freeglut-specific full screen API * Added freeglut-specific (de-)initialization API * Added support for multisampling with given samples per pixel (freeglut) * Added support for mouse wheel callback (freeglut) * Added support for window state callback (freeglut) * Added support for captionless/borderless windows (freeglut 2.6.0) * Handle special keys introduced by freeglut 2.6.0 The most important addition is the ability to create versioned context, so you can use forward compatible OpenGL 3.1 contexts. Death to the fixed function pipeline!! ;-) Cheers, S.

1 0

Fwd: [Haskell] ANNOUNCE: OpenGL 2.2.2.0
by Sven Panne 01 May '09

01 May '09

[ Forgot to CC: to the hopengl mailing list... ] ---------- Weitergeleitete Nachricht ---------- Betreff: [Haskell] ANNOUNCE: OpenGL 2.2.2.0 Datum: Dienstag, 28. April 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. This is mainly a bug fix release, containing the following changes: * Minor tweaks for recent Cabal versions. * Removal of old GHC build system relics. * Handle "invalid framebuffer operation" error. * Terminate GLSL attribute names with NUL in various functions. * Access 3D texture functions via their core API names, improving portability (e.g. for MacOS X). * Added a workaround for a bug in the SGI tessellator. * Fixed marshalling of control points for evaluators. * Added mapBuffer/unmapBuffer and beginQuery/endQuery to exported API. Cheers, S.

1 0

GL.BufferObjects patch request (1-liner)
by Neal Alexander 01 May '09

01 May '09

I think withMappedBuffer does not cover all the use cases of mapped PBO - please add mapBuffer, unmapBuffer to the list of module exports. They come in handy when trying to do concurrent/async texture streaming.

4 5

Re: Opengl Patch
by Sven Panne 29 Apr '09

29 Apr '09

Am Freitag, 24. April 2009 13:53:16 schrieb Hugo Gomes: > Hey, > i stumbled upon this patch in the internets: > http://code.haskell.org/~bkomuves/ > Why isn't it applyed to the Opengl package ? Basically because I wasn't aware of those patches... ;-) I'm currently having a look at them, initially at the bug fixes only. I was planning to add support for generic vertex attribute arrays and frame buffer objects anyway, because they are part of the OpenGL 3.1 core. The API for those parts will probably be similar to the one in the patches, but it has to fit into the "3.1 picture", so I'll have to think about it a bit. Thanks for pointing me to those patches, Cheers, S.

2 1

Re: [HOpenGL] GLU.Tessellator crashes
by Sven Panne 26 Apr '09

26 Apr '09

[ redirecting to the HOpenGL list ] Am Sonntag, 26. April 2009 15:53:31 schrieb Balazs Komuves: > I see that you are again working on the OpenGL binding, so I would like > to advocate the patches I wrote during the last year, which can be found > here: http://code.haskell.org/~bkomuves/hopengl_2009-03-13.patch I am just wading through my email backlog, and found a mail pointing me to those patches. Thanks for you work! > In particular, there is a bugfix in Shaders.hs I would like to see > committed, > and some additional features (for example framebuffer objects) to be at > least considered. The bug fixes should be in the main repository quite fast (or are already there), the API additions need some thought, but they hopefully won't take long, either. Generic vertex attribute arrays and FBOs are important nowadays. > Also, we were talking about having a separate branch of the OpenGL > library to allow fast and easy access to bugfixes and more experimental > features, with the long-term goal of eventually merging them with the > main branch. What's your opinion about this? It would be especially useful > if you decide not to put the FBO / Vertex-Attributes-in-Vertex-Arrays into > the main branch now. Branching has always a high organizational cost associated with it, and I currently don't see a need to do this for the features you mention. I definitely *will* branch the OpenGL package into a "legacy" version (i.e. the current pre-OpenGL-3.x version) and a shiny new OpenGL 3.1 version, which will not be backwards compatible (deprecated stuff removed). But before I'll do this, I'll have to figure out the right way to do this, as there are quite a few things to consider (relationship to the Haskell platform releases, repository locations, bug tracker, etc.). Cheers, S.

1 1