Building on what Hugh was getting at, beyond better opengl bindings, I'd be interested in what a modern real-time graphics engine would look like in Haskell; not a game engine, just a very flexible and well made universal graphics engine. I think there's already a lot of ground work already broken in with a practical example of Yampa via Frag, http://aegisknight.org/papers/Renaissance%202005.pdf and http://conal.net/papers/Vertigo/ for purely functional programming of shaders, etc. At the same time, however, there's still a decent amount of work to be explored outside that core with the: * Representation of objects - internal scene graph description and optimization for different types of scenes such as indoor (bsp?), landscapes (octree?) as well as issues wrt a scene or collection of scenes' actual definition. * Perhaps questions relating to collections of objects (hierarchical issues). * Procedural texture and model generation - some interesting work with Pan and derivatives, but certainly nothing incorporated into a 3d engine afaik. That being said, it's important to be able to design it separately besides just having the engine render it, but the popular demoscene (http://www.werkkzeug.com/), professional (http://www.profxengine.com/), and open source (http://www.fxgen.org/) tools all use artist oriented design methods (linking literal function boxes with arrows or "stacking" them upon each other) and thus are inherently crippled in functionality (and they become incomprehensible with any large size). A proper DSL incorporating some of Pan's features with the larger math libraries of the 3 examples above would allow a superior tool by simply combining [text editor of your choice] and a small app using the engine's procedural generation libraries to compile your MaterialDescriptionLanguage code and provide a preview window. * Somewhat related matters such as plugin based texture rendering (ie rendering a video to texture via external video decoding plugin). * Automatically generated LOD meshes and detecting when to apply them optimally. Haven't personally read anything on this, but a quick search on citeseer gives a large number of promising papers. Beyond the graphics aspect there are also somewhat related networking issues (simulation visualizers, multiplayer games) if you're more interested in that. * Animation - I know little about this. (I'm told) Yampa could be of great use, but I'm not sure how it ties in with standard animation techniques with key frames, IK bones, and whatnot. * Effects such as particle systems, post processing, and cloth simulation seem like a great place to exploit the easy concurrency inherent to purity (see "Particle animation and rendering using data parallel computation" for a start), although post processing would be very simple if you incorporated a good shader DSL similar to vertigo as noted above. * Ability to query the scene for integration with other code for object picking, that is, translating 2d->3d to figure out what the user clicked, for apps, AI if used with a simulation or game of sorts (ie accurate response to shadows cast by other actors), etc. You might be able to prevent this from forcing the rendering to pause, but nothing comes to mind. AFAIK, if STM retried your query you would get the next frame's data (or later), which may still be ok, but the delay might be visible to the user. * Resource management for large asset collections. The real trick here is you need to stay real-time and so lazy methods simply won't work. I assume you could apply a good deal of techniques from preemptive/speculative evaluation and garbage collection. If you did something with scene management above you could do a static analysis of all the scenes that need to be processed before the user is willing to wait (ie game->level, simulation->large time chunk?) to optimize when you perform the loads/clears. Dynamically generated data might pose a few extra difficulties. Games such as Halo have hard coded hallways and elevators as times for the graphics engine to load data, but I think a general heuristic for figuring out something similar is feasible with 1-2 passes over a (quasi?)4D scene graph (add [Tree] of the data required to render a collection of scenes over time). Just a few *very* rough ideas I'm thinking of at the moment; certainly more (and more depth) to consider. I apologize for the archaic formatting, I'll try to tex/wiki up a formal list of questions soon. Hope you enjoy whichever project you end up choosing, Joseph Re ________________________________ From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Hugh Perkins Sent: Tuesday, July 10, 2007 4:46 PM To: wp; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Looking for final year project - using Haskell,or another functional language rpc layer, like .Net Remoting or ICE (but preferably without needing configuration/interface files) Course, if you know what you're doing, that's more like 1 week than one year, but you could do that and then see where it takes you. If you want something really challenging, rewrite OSMP (http://metaverse.sf.net) in Haskell, and get it better than http://secondlife.com If you want a commercial idea, try convincing http://lindenlab.com to let you implement Haskell as a scripting language within SecondLife. If you're interested in designing human-computer interfaces, make a version of Haskell that is easy to use: eg do something so that the "nasty bits" are hidden. Why can you write a function both in lambda notation and in the non-lambda notation? Make it so that there is only one way to write a function. That means less stuff to learn! Get rid of all the nastiness with using Transformer monads etc: make it so we can just provide a couple of monads as our environment, and not have to think about the underlying maths. Implement the entire opengl 1.3 interface specifications in Haskell. Make Glade work in Haskell as easily as it works in mono. Create a topcoder-like algorithm competition. Convince at least 100 people to participate each week. Find a sponsor to provide a 16-core server. Let people write their algorithms in both threaded C# and threaded Haskell. Create algorithm problems that consistently bring out the best in Haskell, so that the Haskell competitors win. Work with Simon Peyton Jones to implement automatic threading in ghc. -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

just be sure to ignore http://www.haskell.org/HOpenGL/ , which should be moved to the wiki or to /dev/null. sorry for the basic question: why is hopengl so bad?

Yes, for a newbie like me it was actually the reason to abandon Haskell initially; none of the examples at http://www.haskell.org/HOpenGL compiled! Another very cool albeit difficult project would be automatic retargeting of Haskell code to the graphics processor unit (GPU), or IBM Synergistic Processor Unit (SPU aka Cell processor, if you can get your hands on such a board...). I think IBM has been working on something like that for imperative languages, but it would be interesting to see how far you one can go with Haskell. If this is not yet done of course... -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Stefan O'Rear Sent: Friday, July 13, 2007 3:37 AM To: wp Cc: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] Looking for final year project - using Haskell, or another functional language On Fri, Jul 13, 2007 at 02:31:58AM +0100, wp wrote:

...

just be sure to ignore http://www.haskell.org/HOpenGL/ , which should be moved to the wiki or to /dev/null.

sorry for the basic question: why is hopengl so bad?

HOpenGL, the library, isn't bad at all. It's the website that's absolutely horrible. Stefan

Donald Bruce Stewart wrote:

We've got people working on it. Sean Lee[1] was running Haskell functions on his Nvidia GPU as of yesterday :-)

Just the other day I was reading about nVidia's CUDA technology - and wishing I could compile Haskell to run on it. ...and then I find *this* in my inbox! ;-)

Can someone post either a simple Hopengl example or a link to one please? (Something that displays a triangle or two, preferably rotatign slowly, ideally rotating when you move the mouse).

in addition to HOpenGL, check out the GLUT binding as well (same mailing list): http://darcs.haskell.org/packages/GLUT/ http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT.... in particular, Sven made sure to fill the examples directory (just below GLUT/) with lots of examples, including those from the red book (comparing the original examples for an opengl feature with the haskell version is a good way to familiarize oneself with the few differences and many commonalities). claus

Hi Claus, Well, I read the website and it stated that it doesnt support alpha blending yet. Thats a pretty basic operation, so I assumed no-one is using hopengl for anything more than a few triangles. I'll check the docs you've linked to. On 7/13/07, Claus Reinke wrote:

...

Building on what Hugh was getting at, beyond better opengl bindings,

i'm curious: just what do you think is missing in haskell's opengl binding?

just be sure to ignore http://www.haskell.org/HOpenGL/ , which should be moved to the wiki or to /dev/null. instead, look at the implementation, mailing list and and api docs (which need to be read side-by-side with the specs):

http://darcs.haskell.org/packages/OpenGL http://www.haskell.org/mailman/listinfo/hopengl

http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render...

I've already sent an email to the haskell.org admin requesting that /HOpenGL be made publically unviewable.

Stefan

in the interim, there's now a bare-bones wiki page: http://www.haskell.org/haskellwiki/Opengl quite dreary, but at least visitors will no longer thing that the binding should be "upgraded" to OpenGL 1.3, or wonder where the sources are, or whether there are any examples that build with those sources.. while Sven keeps improving the implementation, perhaps others can help out improving that entry page. some fancy success stories, up-to-date tutorials, applications, libraries (a binding for text perhaps?-). claus