[Haskell-cafe] GSoC proposal

Thu Apr 2 03:56:24 EDT 2009

2009/4/2 minh thu <noteed at gmail.com>

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090402/ad478427/attachment.htm