This is my first blog post evar, so be gentle :)
I'm tasked to rewrite the haskell package OpenGL this summer. The main task is to move it towards shaders and removing all the functionality that dissapeared with OpenGL 3.1. As it stands now the library on hackage is mostly undocumented and way too big. The library should shrink considerably in size when the project is over. You will also be able to use matrices as shader variables (yay! finally!). I don't know yet which version of OpenGL to depend upon. From what i can gather so far it seems like 2.1 + extensions or 3.2 are the best choices.
In my proposal I mentioned the creation of a library OpenGLRaw-Nice, which would be like OpenGLRaw, but more easy to use (there are some really nasty type signatures in OpenGLRaw). I know this could be useful for a variety of purposes (i.e. learning OpenGL in haskell using a C tutorial or writing your own bindings like fieldtrip or gpipe). If this is going to be done is the subject to community discussion. Work on this won't start until I've had a proper look at OpenGLRaw.
Once work is done with the Raw bindings the work on the main library will commence. There is a lot of code that will stay, but I figure a lot might need rewriting for whatever ideas for the bindings that eventually is decided on. One of my main goals with the project as a whole is to have proper documentation within the library. What exists now is that each sub-module has "look at chapter X.Y in the red book". I remember this not being very helpful when i first used the library. Another main goal is that the library should be usable by haskell beginners. Anyone who finished this course and has a linear algebra book should be able to use the library. This means that there probably won't be any type families or numeric types (exposed at least!). If you're into that stuff you can lobby for me to make OpenGLRaw-Nice so that you more easily can make those bindings yourself ;)
Another thing that i need input on is what to do about deprecation. I see two ways of doing this. The first is to create a sub-tree within OpenGL for deprecated modules (Graphics.Rendering.OpenGL.Deprecated). This will probably require a lot of work as I need to check all existing functions. The second way would be to say "fuck it!" and just remove everything. If anyone depends on old functionality they can always change their .cabal files to "OpenGL < 3" (this would of course be announced at least a month before happening, giving maintainers plenty of time to do this).
With GL 3.X the whole matrix stack dissapeared. Effectively OpenGL is no longer is providing any matrices for the users. So as a convenience for users a matrix and quaternion library will have to be built. So far i've looked at hmatrix, which seems promising.
tl;dr:
OpenGL needs rewriting. Problems:
Depend on 2.1 or 3.2?
Write a haskell-y wrapper for OpenGLRaw?
Have a deprecation model or tell people to update their .cabal files?
How to make a GLU-replacement?
Don’t use hmatrix, it’s overkill for this purpose, and it would introduce new dependencies on native libraries. Instead, look into the vect library, it was created specifically for 3D programming by a demoscener no less. We just switched to it in LambdaCube (from Vec), and life is much easier now.
ReplyDeleteI don't like the old OpenGL interface anymore than anyone else, but do you mean to remove all support for pre-OpenGL2.0 hardware, or just separate the deprecated api somehow?
ReplyDeleteSeparating the old api would help be helpful IMO, but I'm less keen on dropping support entirely. There are a lot of netbooks and so on that don't have OpenGL 2+ support yet. But then again, I doubt this situation will exist for much longer.
Apologies for the bikeshedding but wouldn't OpenGLRaw-Simple be clearer and somewhat kinder on the author of OpenGLRaw?
ReplyDeletePlease depend on OpenGL 4.1 this will make your work in the long end run fine on both embedded devices that uses fixed point for example Android and run fine on high-end desktops since OpenGL 4.1 unify all the different OpenGL variants into one.
ReplyDeleteI also prefer OpenGL 4.x . Better for the future
ReplyDeleteIf you need to automate things from the spec files, I have some code to parse them: https://github.com/noteed/opengl-api
ReplyDeleteIf you don't plan to suppor all of opengl, a new name for the library would be better.
Also I don't understand how a rewrite of a major library can be conceived by only supporting older specs.
I wish you good luck!