[Haskell-cafe] GSoC proposal

[Csaba Hruska]

Abstract:   The objective of this project is to create a useful, fast and
feature rich 3D rendering engine in Haskell which supports advanced
rendering features like level of detail, material state sorting, geometry
instancing, scene handling, fast vertex buffer handling and so on. This
would be beneficial for various applications, e.g. AI or virtual reality
environments, simulation, games, and scientific applications.
Current version available at http://code.google.com/p/lambdacube/   Content:


*== Project Overview ==*

This project aims to be the first general purpose 3D rendering engine
written in a pure functional language. There is no graphics library
available for Haskell that would be suitable as a basis for a complex
graphical program. My Haskell rendering engine (called Lambda Cube
Engine) uses the same model and material format as Ogre3D
(http://www.ogre3d.org). This choice is motivated by the fact that
Ogre3D has well-designed mesh model and material formats, and it also
provides exporter plugins for nearly every significant 3D modeling
software (3DS-Max, Maya, XSI, Blender etc.). This design decision lets
us reuse existing 3D content and Ogre3D exporter plugins with ease. My
knowledge of the Ogre3D architecture will help in making correct
design decisions during development.
*
= Current State =*

The source code is surprisingly small considering the current feature
list. The program consists of 9 small Haskell modules and 2 script
scanner description files. It can load a model from Ogre XML format
and it parses the material definition scripts. It prevents model and
material duplication using a cache. However, the features implemented
are still just a subset of what these files can describe.

Here is a list of (mainly) partially working features:
 - mesh loading from XML file
 - parsing material script (see its format:
  http://www.ogre3d.org/docs/manual/manual_14.html#SEC23)
 - caching loaded data
 - loading resource files from zip archive or filesystem
 - rendering data

There is already an example available, which demonstrates all listed
features. The example also uses Yampa FRP (Functional Rective
Programming) library.

One of the core ideas of the design was separating the high and
low-level data representations. The high-level representation provides
a convenient interface for the user and the low-level representation
ensures efficient rendering on hardware.

The Lambda Cube Engine depends on some (platform independent)
libraries:
 - OpenGL binding
 - uulib - Utrecht Parser Combinator library used for script parsing
 - HXT - Haskell XML Toolkit is used for reading XML representation of
  mesh files. There is a more efficient binary version of the mesh
  format that will be supported later.
 - zip-archive - used for loading files from zip files. This helps
  decerase the number of media files.
 - stb-image - this is a temporary solution to support loading various
  image files. A more professional freeimage (freeimage.sf.net)
  loader is planned later.

*= Goals for the Summer =*

Fortunately the current state of the engine is advanced enough to
start adding some more interesting functionality, such as:

 - Skeletal Animation
  This covers keyframe animation of objects. With skeletal animation
  we can create a very dynamic and alive environment (e.g. walking
  people). Outcome: interpolation function (spline), vertex buffer
  update functions

 - Level Of Detail support
  This is required for good performance and it is a very commonly
  used technique. With this feature we will be able to build
  high-complexity scenes. Outcome: vertex buffer switcher function in
  render pipeline.

 - Shadow Mapping (shadow support)
  Shadows are very a basic requirement of a modern 3D
  application. Shadow mapping is a technique that fits modern
  graphics hardware. Outcome: changes in the render function.

 - Post Processing Effects support (e.g. Motion Blur, HDR)
  This is a relatively new technique. It is widely used in present
  games because it increases visual quality very much.
  Outcome: compositor script parser functions. Some changes in the
  render function.

 - Particle System support
  Particle systems are used to create nice effects like explosions,
  rain, smoke. This is also a very basic technique of computer
  graphics. Outcome: particle system parser functions.

 - Optimization function for rendering
  It is required to minimize the state changes of graphical hardware
  during the rendering process to get top performance. This is one
  of the most important parts of a rendering engine. A well-chosen
  ordering of rendering batches could increase the performance
  considerably. Outcome: a new low-level (incremental) data structure
  and an update function for it.

 - The most interesting planned feature and possibly the most
  difficult one is the mesh modifier combinator set. This will let
  the user build a mesh in runtime. This extends the range of
  usability of the library (e.g. tesselation of impicit surfaces,
  subdivision, smoothing). Only an initial interface and some example
  mesh modifier combinator will be implemented until September.
  Outcome: high-level mesh data structure which contains the
  adjacency information of vertices and faces, plus some related
  modifier functions.

Many components required for these functions are already available in
the current implementation (e.g. vertex buffer handling, script
parsing, resource framework).

Having these working components will help us deal with the high-level
part of a visual application. And possibly it will enable compiler
developers to find out about the weak points of the compiler through
interactive user application benchmarks.

*== Rough Schedule ==*

I'll start the implementation of smaller features as it is shown in
the feature list. The example programs will be created after adding
each feature. The overview documentation will be written in late July,
I hope to have a stable interface by that time. I'll have exams at the
university in June, so the development will advance at a moderate pace
during that time. But judging by my experience since beginning this
project it seems realistic to achieve the project goals by mid-August.
*
== Documentation ==*

The documentation will include a short overview for every submodule
(e.g. material system or scene management) and a system wide overview
which aims to introduce the library to a newbie user. The provided
example programs will be written in literate Haskell, so a text
document can be generated from each of them. This will provide a
detailed use case tutorial for user. A full API documentation will be
generated with Haddock (http://www.haskell.org/haddock/).

*== Testing ==*

During the implementation of each feature a small demo example will be
written. These examples can be used as documentation as well as test
cases. These would be quite similar to Ogre3D examples and they could
be used for performance comparison. I would also like to build a more
complex example (a mini game) which should be able to show off all
features and strengths of the engine. It will also serve as a baseline
for the expected performance.

*== Platform ==*

The library does not contain platform dependent code, it is portable
to every platform with a suitable Haskell compiler (currently GHC) and
OpenGL. This currently means Windows, Linux, Mac OS X. In the future,
I'd like to support other Haskell compilers than GHC, but for the time
being GHC is the only compiler that can cope with all required
libraries.

*== Resulting Code ==*

As a result of the summer project there will be a functional rendering
engine, several small example programs and one bigger mini game. All
documentation and source code including examples will be hosted on the
project page. (http://code.google.com/p/lambdacube/)

*== Licensing ==*

The Lambda Cube Engine library is free software. The source code is
covered by GPLv3. This gives maximum freedom to the community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090402/12d98249/attachment-0001.htm