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.

2009/4/2 minh thu

2009/4/2 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

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, ...) ?

It is about rendering. A complete game engine implementation is not fitting into one summer project.

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

The library must be as independent as possibe so it is not using Yampa. Only the current example depends 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 ?

The material file format can describe both shader programs and fixed function attributes which are optional. But the implementation details are hidden from the user. The format does not limit the functionality. Modern approach is base concept of Lambda Cube Engine.

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

These are definitely included in the engine's scene handling module.

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

I've checked frag (http://www.haskell.org/haskellwiki/Frag) and scenegraph ( http://www.haskell.org/haskellwiki/SceneGraph) source code but just for collect some info and I will not use them. Scenegraph's scene combinators seems good maybe I'll reuse its concept in scene module. But firstly I'd like implement the low level part of the engine.

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