[Haskell-cafe] GSoC proposal
noteed at gmail.com
Thu Apr 2 03:01:25 EDT 2009
2009/4/2 Csaba Hruska <csaba.hruska at gmail.com>:
> 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/
> == 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:
> - 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)
> - 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
> == 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
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.
More information about the Haskell-Cafe