[Haskell-cafe] Looking for final year project - using Haskell, or another functional language

[Re, Joseph (IT)]

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 at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Hugh Perkins
Sent: Tuesday, July 10, 2007 4:46 PM
To: wp; haskell-cafe at 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.