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.