2009/4/2 Csaba Hruska <[email protected]>: > 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
