[Haskell-cafe] GSoC proposal

[minh thu]

2009/4/2 Csaba Hruska <csaba.hruska at gmail.com>:
> 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

Hi,

All this sounds very good but I'm not sure I understand the complete goal.

Is it more about rendering or (game) engine ? Ok, the title is Engine, but is
it more a library or a complete framework (with archive loading,
saving/load state, behaviors (ai, user interaction, ...), sound
placement, networking, ...) ?

You mention Yampa. Is it just for the example or do you plane to rely on it ?

What is the part of state-of-the-art rendering ? I'm not really aware
of all of this, but I think
current focus is on non-fixed pipeline (i.e. vertex and fragment
program), how is taken into account here ? By the OGRE material files
?

Or what about frustum culling and space partitioning ? Is it up to the
user of you code ?

Do you use an extant engine or scene graph library as inspiration ?

I'm sure I had other questions by reading your proposal but I forgot...

Anyway, this is very interesting and I wish you good luck, ... and success.

Cheers,
Thu