<br><br><div class="gmail_quote">2009/4/2 minh thu <span dir="ltr">&lt;<a href="mailto:noteed@gmail.com">noteed@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/4/2 Csaba Hruska &lt;<a href="mailto:csaba.hruska@gmail.com">csaba.hruska@gmail.com</a>&gt;:<br>
<div><div></div><div class="h5">&gt; Abstract:<br>
&gt; The objective of this project is to create a useful, fast and feature rich<br>
&gt; 3D rendering engine in Haskell which supports advanced rendering features<br>
&gt; like level of detail, material state sorting, geometry instancing, scene<br>
&gt; handling, fast vertex buffer handling and so on. This would be beneficial<br>
&gt; for various applications, e.g. AI or virtual reality environments,<br>
&gt; simulation, games, and scientific applications.<br>
&gt; Current version available at <a href="http://code.google.com/p/lambdacube/" target="_blank">http://code.google.com/p/lambdacube/</a><br>
&gt; Content:<br>
&gt;<br>
&gt; == Project Overview ==<br>
&gt;<br>
&gt; This project aims to be the first general purpose 3D rendering engine<br>
&gt; written in a pure functional language. There is no graphics library<br>
&gt; available for Haskell that would be suitable as a basis for a complex<br>
&gt; graphical program. My Haskell rendering engine (called Lambda Cube<br>
&gt; Engine) uses the same model and material format as Ogre3D<br>
&gt; (<a href="http://www.ogre3d.org" target="_blank">http://www.ogre3d.org</a>). This choice is motivated by the fact that<br>
&gt; Ogre3D has well-designed mesh model and material formats, and it also<br>
&gt; provides exporter plugins for nearly every significant 3D modeling<br>
&gt; software (3DS-Max, Maya, XSI, Blender etc.). This design decision lets<br>
&gt; us reuse existing 3D content and Ogre3D exporter plugins with ease. My<br>
&gt; knowledge of the Ogre3D architecture will help in making correct<br>
&gt; design decisions during development.<br>
&gt;<br>
&gt; = Current State =<br>
&gt;<br>
&gt; The source code is surprisingly small considering the current feature<br>
&gt; list. The program consists of 9 small Haskell modules and 2 script<br>
&gt; scanner description files. It can load a model from Ogre XML format<br>
&gt; and it parses the material definition scripts. It prevents model and<br>
&gt; material duplication using a cache. However, the features implemented<br>
&gt; are still just a subset of what these files can describe.<br>
&gt;<br>
&gt; Here is a list of (mainly) partially working features:<br>
&gt;  - mesh loading from XML file<br>
&gt;  - parsing material script (see its format:<br>
&gt;   <a href="http://www.ogre3d.org/docs/manual/manual_14.html#SEC23" target="_blank">http://www.ogre3d.org/docs/manual/manual_14.html#SEC23</a>)<br>
&gt;  - caching loaded data<br>
&gt;  - loading resource files from zip archive or filesystem<br>
&gt;  - rendering data<br>
&gt;<br>
&gt; There is already an example available, which demonstrates all listed<br>
&gt; features. The example also uses Yampa FRP (Functional Rective<br>
&gt; Programming) library.<br>
&gt;<br>
&gt; One of the core ideas of the design was separating the high and<br>
&gt; low-level data representations. The high-level representation provides<br>
&gt; a convenient interface for the user and the low-level representation<br>
&gt; ensures efficient rendering on hardware.<br>
&gt;<br>
&gt; The Lambda Cube Engine depends on some (platform independent)<br>
&gt; libraries:<br>
&gt;  - OpenGL binding<br>
&gt;  - uulib - Utrecht Parser Combinator library used for script parsing<br>
&gt;  - HXT - Haskell XML Toolkit is used for reading XML representation of<br>
&gt;   mesh files. There is a more efficient binary version of the mesh<br>
&gt;   format that will be supported later.<br>
&gt;  - zip-archive - used for loading files from zip files. This helps<br>
&gt;   decerase the number of media files.<br>
&gt;  - stb-image - this is a temporary solution to support loading various<br>
&gt;   image files. A more professional freeimage (<a href="http://freeimage.sf.net" target="_blank">freeimage.sf.net</a>)<br>
&gt;   loader is planned later.<br>
&gt;<br>
&gt; = Goals for the Summer =<br>
&gt;<br>
&gt; Fortunately the current state of the engine is advanced enough to<br>
&gt; start adding some more interesting functionality, such as:<br>
&gt;<br>
&gt;  - Skeletal Animation<br>
&gt;   This covers keyframe animation of objects. With skeletal animation<br>
&gt;   we can create a very dynamic and alive environment (e.g. walking<br>
&gt;   people). Outcome: interpolation function (spline), vertex buffer<br>
&gt;   update functions<br>
&gt;<br>
&gt;  - Level Of Detail support<br>
&gt;   This is required for good performance and it is a very commonly<br>
&gt;   used technique. With this feature we will be able to build<br>
&gt;   high-complexity scenes. Outcome: vertex buffer switcher function in<br>
&gt;   render pipeline.<br>
&gt;<br>
&gt;  - Shadow Mapping (shadow support)<br>
&gt;   Shadows are very a basic requirement of a modern 3D<br>
&gt;   application. Shadow mapping is a technique that fits modern<br>
&gt;   graphics hardware. Outcome: changes in the render function.<br>
&gt;<br>
&gt;  - Post Processing Effects support (e.g. Motion Blur, HDR)<br>
&gt;   This is a relatively new technique. It is widely used in present<br>
&gt;   games because it increases visual quality very much.<br>
&gt;   Outcome: compositor script parser functions. Some changes in the<br>
&gt;   render function.<br>
&gt;<br>
&gt;  - Particle System support<br>
&gt;   Particle systems are used to create nice effects like explosions,<br>
&gt;   rain, smoke. This is also a very basic technique of computer<br>
&gt;   graphics. Outcome: particle system parser functions.<br>
&gt;<br>
&gt;  - Optimization function for rendering<br>
&gt;   It is required to minimize the state changes of graphical hardware<br>
&gt;   during the rendering process to get top performance. This is one<br>
&gt;   of the most important parts of a rendering engine. A well-chosen<br>
&gt;   ordering of rendering batches could increase the performance<br>
&gt;   considerably. Outcome: a new low-level (incremental) data structure<br>
&gt;   and an update function for it.<br>
&gt;<br>
&gt;  - The most interesting planned feature and possibly the most<br>
&gt;   difficult one is the mesh modifier combinator set. This will let<br>
&gt;   the user build a mesh in runtime. This extends the range of<br>
&gt;   usability of the library (e.g. tesselation of impicit surfaces,<br>
&gt;   subdivision, smoothing). Only an initial interface and some example<br>
&gt;   mesh modifier combinator will be implemented until September.<br>
&gt;   Outcome: high-level mesh data structure which contains the<br>
&gt;   adjacency information of vertices and faces, plus some related<br>
&gt;   modifier functions.<br>
&gt;<br>
&gt; Many components required for these functions are already available in<br>
&gt; the current implementation (e.g. vertex buffer handling, script<br>
&gt; parsing, resource framework).<br>
&gt;<br>
&gt; Having these working components will help us deal with the high-level<br>
&gt; part of a visual application. And possibly it will enable compiler<br>
&gt; developers to find out about the weak points of the compiler through<br>
&gt; interactive user application benchmarks.<br>
&gt;<br>
&gt; == Rough Schedule ==<br>
&gt;<br>
&gt; I&#39;ll start the implementation of smaller features as it is shown in<br>
&gt; the feature list. The example programs will be created after adding<br>
&gt; each feature. The overview documentation will be written in late July,<br>
&gt; I hope to have a stable interface by that time. I&#39;ll have exams at the<br>
&gt; university in June, so the development will advance at a moderate pace<br>
&gt; during that time. But judging by my experience since beginning this<br>
&gt; project it seems realistic to achieve the project goals by mid-August.<br>
&gt;<br>
&gt; == Documentation ==<br>
&gt;<br>
&gt; The documentation will include a short overview for every submodule<br>
&gt; (e.g. material system or scene management) and a system wide overview<br>
&gt; which aims to introduce the library to a newbie user. The provided<br>
&gt; example programs will be written in literate Haskell, so a text<br>
&gt; document can be generated from each of them. This will provide a<br>
&gt; detailed use case tutorial for user. A full API documentation will be<br>
&gt; generated with Haddock (<a href="http://www.haskell.org/haddock/" target="_blank">http://www.haskell.org/haddock/</a>).<br>
&gt;<br>
&gt; == Testing ==<br>
&gt;<br>
&gt; During the implementation of each feature a small demo example will be<br>
&gt; written. These examples can be used as documentation as well as test<br>
&gt; cases. These would be quite similar to Ogre3D examples and they could<br>
&gt; be used for performance comparison. I would also like to build a more<br>
&gt; complex example (a mini game) which should be able to show off all<br>
&gt; features and strengths of the engine. It will also serve as a baseline<br>
&gt; for the expected performance.<br>
&gt;<br>
&gt; == Platform ==<br>
&gt;<br>
&gt; The library does not contain platform dependent code, it is portable<br>
&gt; to every platform with a suitable Haskell compiler (currently GHC) and<br>
&gt; OpenGL. This currently means Windows, Linux, Mac OS X. In the future,<br>
&gt; I&#39;d like to support other Haskell compilers than GHC, but for the time<br>
&gt; being GHC is the only compiler that can cope with all required<br>
&gt; libraries.<br>
&gt;<br>
&gt; == Resulting Code ==<br>
&gt;<br>
&gt; As a result of the summer project there will be a functional rendering<br>
&gt; engine, several small example programs and one bigger mini game. All<br>
&gt; documentation and source code including examples will be hosted on the<br>
&gt; project page. (<a href="http://code.google.com/p/lambdacube/" target="_blank">http://code.google.com/p/lambdacube/</a>)<br>
&gt;<br>
&gt; == Licensing ==<br>
&gt;<br>
&gt; The Lambda Cube Engine library is free software. The source code is<br>
<br>
</div></div>Hi,<br>
<br>
All this sounds very good but I&#39;m not sure I understand the complete goal.<br>
<br>
Is it more about rendering or (game) engine ? Ok, the title is Engine, but is<br>
it more a library or a complete framework (with archive loading,<br>
saving/load state, behaviors (ai, user interaction, ...), sound<br>
placement, networking, ...) ?</blockquote><div>It is about rendering. A complete game engine implementation is not fitting into one summer project.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
You mention Yampa. Is it just for the example or do you plane to rely on it ?</blockquote><div>The library must be as independent as possibe so it is not using Yampa. Only the current example depends on it.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
What is the part of state-of-the-art rendering ? I&#39;m not really aware<br>
of all of this, but I think<br>
current focus is on non-fixed pipeline (i.e. vertex and fragment<br>
program), how is taken into account here ? By the OGRE material files<br>
?</blockquote><div>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.<br>The format does not limit the functionality. <br>
Modern approach is base concept of Lambda Cube Engine.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Or what about frustum culling and space partitioning ? Is it up to the<br>
user of you code ?</blockquote><div>These are definitely included in the engine&#39;s scene handling module. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Do you use an extant engine or scene graph library as inspiration ?</blockquote><div>I&#39;ve checked frag (<a href="http://www.haskell.org/haskellwiki/Frag">http://www.haskell.org/haskellwiki/Frag</a>) and scenegraph (<a href="http://www.haskell.org/haskellwiki/SceneGraph">http://www.haskell.org/haskellwiki/SceneGraph</a>) source code but just for collect some info and I will not use them. Scenegraph&#39;s scene combinators seems good maybe I&#39;ll reuse its concept in scene module. But firstly I&#39;d like implement the low level part of the engine.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
I&#39;m sure I had other questions by reading your proposal but I forgot...<br>
<br>
Anyway, this is very interesting and I wish you good luck, ... and success.<br>
<br>
Cheers,<br>
<font color="#888888">Thu<br>
</font></blockquote></div><br>