Difference between revisions of "H3D"

From HaskellWiki
Jump to navigation Jump to search
(Added OpenSG link and comment on my own code.)
m
 
(30 intermediate revisions by 15 users not shown)
Line 1: Line 1:
= H3D =
 
 
 
Welcome to the H3D wiki. This page is meant for gathering ideas and suggestions for a 3D modelling application written in Haskell.
 
Welcome to the H3D wiki. This page is meant for gathering ideas and suggestions for a 3D modelling application written in Haskell.
 
Writing it should be about exploring the possibilites of Haskell, and adding stuff no other language else has.
 
Writing it should be about exploring the possibilites of Haskell, and adding stuff no other language else has.
   
  +
Current work:
Current work: getting L-systems (["HaskLS"]) working in Haskell, and going on from there...
+
* Getting L-systems (["HaskLS"]) working in Haskell, and going on from there.
  +
* Haskell [[SceneGraph]]
   
===== Contributors =====
+
== Contributors ==
   
 
'''Please mention your nickname on #haskell, for future reference.
 
'''Please mention your nickname on #haskell, for future reference.
Line 14: Line 14:
 
If you're willing to contribute (in any way: code, idea's, feedback, even money ;)) to this project, please add your name below. (no strings attached)
 
If you're willing to contribute (in any way: code, idea's, feedback, even money ;)) to this project, please add your name below. (no strings attached)
   
* [http://haskell.org/hawiki/KennethHoste boegel] (project idea, creator of this wiki)
+
* [http://haskell.org/hawiki/KennethHoste boegel] (project idea, creator of this wiki)
* bourbaki (L-systems and Ogre3D idea)
+
* bourbaki (L-systems and Ogre3D idea)
* sylvan (scene graph idea)
+
* sylvan (scene graph idea)
* Also, it might be worthwhile to exploit the ongoing convergence of high-end scanline renderers (a la Pixar) and consumer hardware. Next gen hardware (and even current high-end) could definatly produce movie-quality (honestly!) renderings with about the same throughput as a 1000-machine rendering farm, but with much less latency (one computer producing frames every two seconds, instead of a thousand computers producing one frame each every thirty minutes) which is definatly preferably from an artists standpoint.
+
** Also, it might be worthwhile to exploit the ongoing convergence of high-end scanline renderers (a la Pixar) and consumer hardware. Next gen hardware (and even current high-end) could definatly produce movie-quality (honestly!) renderings with about the same throughput as a 1000-machine rendering farm, but with much less latency (one computer producing frames every two seconds, instead of a thousand computers producing one frame each every thirty minutes) which is definatly preferably from an artists standpoint.
* ["shelarcy"] (introduce Japanese page and write that summary)
+
* [[User:Shelarcy|shelarcy]] (introduce Japanese page and write that summary)
* Pseudonym (follow Renderman interface)
+
* Pseudonym (follow Renderman interface)
* pipe (wolfgang8k):
+
* pipe (wolfgang8k):
* write your own scanline renderer in Haskell, use OpenGL for real-time stuff (or write a renderer yourself)
+
** write your own scanline renderer in Haskell, use OpenGL for real-time stuff (or write a renderer yourself)
* start with a scenegraph (Haskell type) and a simple command line interface
+
** start with a scenegraph (Haskell type) and a simple command line interface
* use the CLI for basic operations on the scenegraph (adding stuff)
+
** use the CLI for basic operations on the scenegraph (adding stuff)
* create a GUI with buttons which are bound to function like addSphere :: Scene -> Scene
+
** create a GUI with buttons which are bound to function like addSphere :: Scene -> Scene
* keep a list a scenes for undo/redo purposes (a lot of memory, but very simple)
+
** keep a list a scenes for undo/redo purposes (a lot of memory, but very simple)
* figure out a system for selecting objects (selection = list of integers, indices of objects in the scene)
+
** figure out a system for selecting objects (selection = list of integers, indices of objects in the scene)
* functions like translate, scale, rotate of type Scene -> [Int] -> (dx,dy,dz) -> Scene
+
** functions like translate, scale, rotate of type Scene -> [Int] -> (dx,dy,dz) -> Scene
* system for editing attributes of objects (radius of a Sphere, intensity of a light source)
+
** system for editing attributes of objects (radius of a Sphere, intensity of a light source)
* with OpenGL, you only need a function in IO monad which takes a Scene value and renders it
+
** with OpenGL, you only need a function in IO monad which takes a Scene value and renders it
  +
* marcusl : maybe interested in providing some scene graph bindings.
  +
* markw: See [[SceneGraph]]. Currently looking at OpenSceneGraph and started looking at CrystalSpace. Both of these target different uses - OSG is for virtual landscapes whilst CS is for games (and so includes 'out of the box' interaction and entity control). Both of these are C++ libraries and libraries to scripting languages have been developed using SWIG (hence my post on Haskell cafe asking if anyone had used SWIG with Haskell). They look like well crafted class libraries but but a missing the next level of abstraction. Haskell can offer a bridge to a higher level of abstraction; what that is doesn't seem to be obvious but a least Haskell will enable experimentation using, for instance, Conal's work. I am particularly interested in algorithmic generation of landscapes and game maps and how you can mimic the natural (and non-natural) process that sculpt the land (ie as the next level of abstraction).
  +
* lazor: I like the idea. I'm just generally interested in 3D modelling, I'm using wings3d right now. I would use whatever comes out of this effort, test it, write bug reports, etc., maybe even code some stuff. The possibility of collaborative modelling would make me happy.
  +
* hcube: [http://www.haskell.org/haskellwiki/Bullet bullet physics haskell wrapper], blender developer and user, fun project [http://stuntcarracer.sf.net stunts remake], 3d render engine in haskell: [http://www.haskell.org/haskellwiki/LambdaCubeEngine LambdaCube]
  +
* subw: I have had an interest in 3D (rendering & modelling) for a long time. I've used several different 3D packages (Cinema 4D, Lightwave) a few years back, I could test, and file bugs. Coding maybe when I know more math :-)
  +
* jfischoff: New to Haskell. I've been in the game industry for a few years now. Used to work for Emergent Game Technologies on their Gamebryo Engine. Written two little game engines for different companies. I think getting a COLLADA importer written and a pure way to render to images are two tasks I would like to work on first.
  +
* harrison: tracing instead of rasterization. perhaps a sierpinski flythrough demo. code exists in another language.
 
== Open questions and suggestions ==
   
 
* ''What do we want ?''
=== Open questions and suggestions ===
 
   
 
** An open source application that has to do with 3D modelling. Probably something real-time (like Maya and Blender), but not just another 3D modeller. We want to show off Haskell's strengths, and use techniques unique to Haskell and functional programming.
* ''What do we want ?''
 
   
  +
** Library of geometric processing functions. Delaunay triangulation, triangle stripification, subdivsion, etc.
An open source application that has to do with 3D modelling. Probably something real-time (like Maya and Blender), but not just
 
  +
** Pure Haskell linear algebra
another 3D modeller. We want to show off Haskell's strengths, and use techniques unique to Haskell and functional programming.
 
  +
** Interpolated curve and surface library. Bézier, NURBS, subdivision surfaces, etc.
  +
** Mesh deformation library: smooth skinning, morph target, ffd, etc.
  +
** Pure Haskell Renderer. Texture mapped meshes as base, build towards shader based global illumination.
  +
** Key-frame based animation library. Various forms of interpolation. Build to clip based non-linear animation.
  +
** Transform hierarchies for bones, scenes, etc.
   
* ''What can we use that is already available ?''
 
   
Ogre3D: open source graphics engine; G3D: http://g3d-cpp.sourceforge.net/; L-systems: technique to create plants, feathers and the lot; SDL bindings (Lemmih); HOpenGL: OpenGL binding for Haskell; Monads (in Haskell) -> http://haskell.org/hawiki/MonadsAsContainers
 
   
* ''Where do we begin ?''
+
* ''What can we use that is already available ?''
  +
  +
** Ogre3D: open source graphics engine;
  +
** G3D: http://g3d-cpp.sourceforge.net/;
  +
** Horde3D: http://www.horde3d.org, written in C++, but it seems to come with a C interface, also, someone already started writing a haskell binding for it: http://open-projects.net/~shahn/index.cgi?seite=code
  +
** L-systems: technique to create plants, feathers and the lot; SDL bindings (Lemmih);
  +
** HOpenGL: OpenGL binding for Haskell;
  +
** Monads (in Haskell) -> http://haskell.org/hawiki/MonadsAsContainers
  +
  +
  +
  +
* ''Where do we begin ?''
   
 
First idea: build an L-system, then create a simple Ogre3D binding to visualize stuff
 
First idea: build an L-system, then create a simple Ogre3D binding to visualize stuff
Line 48: Line 70:
 
Second idea: start with a scene graph, and implement simple stuff like polygon soups and parametric surfaces at first
 
Second idea: start with a scene graph, and implement simple stuff like polygon soups and parametric surfaces at first
   
* How do we use Ogre3D from within Haskell ?
+
* How do we use Ogre3D from within Haskell ?
   
 
Use a C interface that doesn't exist yet :-)
 
Use a C interface that doesn't exist yet :-)
Line 56: Line 78:
 
or use Hacanon to call C++ code from within Haskell: [http://haskell.org/hawiki/Hacanon]
 
or use Hacanon to call C++ code from within Haskell: [http://haskell.org/hawiki/Hacanon]
   
* ''How far will we go with this ?''
+
* ''How far will we go with this ?''
   
 
Don't know, as long as it's fun !
 
Don't know, as long as it's fun !
   
* ''More open questions ?''
+
* ''More open questions ?''
   
 
boegel
 
boegel
Line 70: Line 92:
 
just push the meshes and such into the engine.
 
just push the meshes and such into the engine.
   
  +
Peter Althainz:
* http://www.cs.wpi.edu/~emmanuel/courses/cs563/write_ups/bradg/feathers/featherpaper.htm#intro
 
  +
There are different wrappers existing for Ogre on hackage:
* http://www.geocities.com/blenderdungeon/lsystem/
 
  +
HOgre (http://hackage.haskell.org/package/hogre)
* http://www.nbb.cornell.edu/neurobio/land/OldStudentProjects/cs490-94to95/hwchen/
 
  +
HGamer3D-Ogre-Binding (http://hackage.haskell.org/package/HGamer3D-Ogre-Binding)
* http://en.wikipedia.org/wiki/L-system
 
  +
In my opinion, to get started with 3D graphics/animation, using an existing library is a good approach. Writing an own one has its own interesting aspects, but will use up a lot of time and resource. Also with a well structure library, usage can be quite granular.
* http://algorithmicbotany.org/papers/
 
  +
* http://algorithmicbotany.org/virtual_laboratory/
 
  +
[The problem with this approach is that it constrains one to use the features of that engine. It is far more interesting to write new kinds of renderers.]
* http://citeseer.lcs.mit.edu/deussen98realistic.html
 
  +
 
* http://www.cs.wpi.edu/~emmanuel/courses/cs563/write_ups/bradg/feathers/featherpaper.htm#intro
 
* http://www.geocities.com/blenderdungeon/lsystem/
 
* http://www.nbb.cornell.edu/neurobio/land/OldStudentProjects/cs490-94to95/hwchen/
 
* http://en.wikipedia.org/wiki/L-system
 
* http://algorithmicbotany.org/papers/
 
* http://algorithmicbotany.org/virtual_laboratory/
 
* http://citeseer.lcs.mit.edu/deussen98realistic.html
   
 
This would make it necessary to write a good and flexible mesh class.
 
This would make it necessary to write a good and flexible mesh class.
Line 85: Line 115:
 
bourbaki
 
bourbaki
   
=== Suggestions - idea's - stuff we can use ===
+
== Suggestions - idea's - stuff we can use ==
   
 
Here are some ideas (feel free to add !):
 
Here are some ideas (feel free to add !):
* boegel's ray tracing application HRay: http://www.elis.ugent.be/~kehoste/Haskell/HRay
+
* boegel's ray tracing application HRay: http://www.elis.ugent.be/~kehoste/Haskell/HRay
* boegel's HaskLS (L-System implementation in Haskell): http://www.elis.ugent.be/~kehoste/Haskell/HaskLS
+
* boegel's HaskLS (L-System implementation in Haskell): http://www.elis.ugent.be/~kehoste/Haskell/HaskLS
* bourbaki's spline renderer: http://codemages.sf.net/homotopy1.hs
+
* bourbaki's spline renderer: http://codemages.sf.net/homotopy1.hs
* benny's ray tracing application hrayt: http://benny.kramekweb.com/hrayt/
+
* benny's ray tracing application hrayt: http://benny.kramekweb.com/hrayt/
* Andy's Htrace: http://www.nobugs.org/developer/htrace/
+
* Andy's Htrace: http://www.nobugs.org/developer/htrace/
* Bernie's bjpop-ray: http://www.cs.mu.oz.au/~bjpop/code.html
+
* Bernie's bjpop-ray: http://www.cs.mu.oz.au/~bjpop/code.html
* tanakh's glexcess demo: http://d.hatena.ne.jp/tanakh/20050324
+
* tanakh's glexcess demo: http://d.hatena.ne.jp/tanakh/20050324
* summary for this page: tanakh port http://www.glexcess.com/ demo for haskell (http://fxp.infoseek.ne.jp/haskell/glexcess_haskell.zip). He knows that is ported for D language by yaneurao (http://www.sun-inet.or.jp/~yaneurao/) too. He ported only Scene1 and Scene2. He is tired this work - port C code to Haskell by functionality code. He already developed demo framwork, so he hope other person try to develop full scene.
+
** summary for this page: tanakh port http://www.glexcess.com/ demo for haskell (http://fxp.infoseek.ne.jp/haskell/glexcess_haskell.zip). He knows that is ported for D language by yaneurao (http://www.sun-inet.or.jp/~yaneurao/) too. He ported only Scene1 and Scene2. He is tired this work - port C code to Haskell by functionality code. He already developed demo framwork, so he hope other person try to develop full scene.
* tanakh and his friend - nushio made Haskell shooting game. this game use only wireframe for character : http://www.geocities.jp/takascience/
+
* tanakh and his friend - nushio made Haskell shooting game. this game use only wireframe for character : http://www.geocities.jp/takascience/
* summary for this page: this game name is Shu-thing. this page has 4 screen shot and game with source (http://www.geocities.jp/takascience/windows/shu-thing.zip). Command : move - cursor key, shoot - y, quite this game - q. english translation of the page available at(http://www.geocities.jp/takascience/index_e.html).
+
** summary for this page: this game name is Shu-thing. this page has 4 screen shot and game with source (http://www.geocities.jp/takascience/windows/shu-thing.zip). Command : move - cursor key, shoot - y, quite this game - q. english translation of the page available at(http://www.geocities.jp/takascience/index_e.html).
* wolfgang's POV-Ray's object viewer VOP: http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html
+
* wolfgang's POV-Ray's object viewer VOP: http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html
* Conal Elliot's Vertigo: (http://conal.net/Vertigo/). Could ideas be taken from this to get a flexible material system?
+
* Conal Elliott's Vertigo: (http://conal.net/Vertigo/). Could ideas be taken from this to get a flexible material system?
* Marcus' HSpark: http://www.yar.nu/macke/hspark/ . But you can't get latest code, you can get only older version that can't use with sample code. (Code on semi-broken HDD. Will try to get some data off it. /Marcus)
+
* Marcus' HSpark: http://www.yar.nu/macke/hspark/ . But you can't get latest code, you can get only older version that can't use with sample code. (Code on semi-broken HDD. Will try to get some data off it. /Marcus)
* You might check out [http://www.cairographics.org/hscairo hscairo]. From Cairo's description: "Cairo is a vector graphics library designed to provide high-quality display and print output. Currently available backends include the X Window System, OpenGL (via [WWW]glitz), Quartz, win32, in-memory image buffers, PNG images, PostScript, and PDF files."
+
* You might check out [http://www.cairographics.org/hscairo hscairo]. From Cairo's description: "Cairo is a vector graphics library designed to provide high-quality display and print output. Currently available backends include the X Window System, OpenGL (via [WWW]glitz), Quartz, win32, in-memory image buffers, PNG images, PostScript, and PDF files."
* Lemmih's [http://www.libsdl.org SDL] binding: darcs get http://scannedinavian.org/~lemmih/SDLstable/
+
* Lemmih's [http://www.libsdl.org SDL] binding: darcs get http://scannedinavian.org/~lemmih/SDLstable/
* Check out Wings 3d, open source modeler written in Erlang: http://www.wings3d.com/
+
* Check out Wings 3d, open source modeler written in Erlang: http://www.wings3d.com/
* Banyan: a 3D modeller with shared repository http://www.schemearts.com/banyan/wiki
+
* Banyan: a 3D modeller with shared repository http://www.schemearts.com/banyan/wiki
* open source modeller: http://k3d.sourceforge.net/ (Pseudonym)
+
* open source modeller: http://k3d.sourceforge.net/ (Pseudonym)
* Pseudonym's fluid simulator
+
* Pseudonym's fluid simulator
* Another simple raytracer, written by someone (can't remember who) and extended by Pseudonym to use proper sampling strategies: http://andrew.bromage.org/rt.hs
+
* Another simple raytracer, written by someone (can't remember who) and extended by Pseudonym to use proper sampling strategies: http://andrew.bromage.org/rt.hs
* follow the RenderMan interface: http://www.rendermanacademy.com
+
* follow the RenderMan interface: http://www.rendermanacademy.com
* sylvan mentioned OpenSceneGraph as a possible inspiration: http://www.openscenegraph.org/
+
* sylvan mentioned OpenSceneGraph as a possible inspiration: http://www.openscenegraph.org/
* shelarcy mentioned Open Inventor, yet another 3D toolkit (C++,Java)
+
* shelarcy mentioned Open Inventor, yet another 3D toolkit (C++,Java)
* marcusl thinks http://opensg.vrsource.org/ is a very nice open source scene graph.
+
* marcusl thinks http://opensg.vrsource.org/ is a very nice open source scene graph.
  +
* [http://hackage.haskell.org/trac/PolyFunViz/wiki Lazy Polytypic Functional Visualisation] Includes implementation of Marching Cubes algorithm in Haskell.
 
  +
* [http://verse.blender.org Verse] support would be interesting.
  +
* A collaborative modeler. Take a look at the [http://www.cubeengine.com Cubeengine], it features a mode where you can edit the map, even in a cooperative way in multiplayer. Something like that but as a real modeler would be great.
  +
* Try to be modular: Ability to combine different modelers, rendering engines &c. built on a minimal shared base (SceneGraph?) with also minimal interfaces. This helps innovation, because if you rewrite one part of the pipeline, the rest doesn't break.
  +
* A 3D render engine written in Haskell: [http://www.haskell.org/haskellwiki/LambdaCubeEngine Lambda-Cube]
  +
* HGamer3D Ogre Binding - http://hackage.haskell.org/package/HGamer3D-Ogre-Binding
   
 
Any suggestions are welcome !
 
Any suggestions are welcome !
  +
   
   
Line 127: Line 163:
 
* http://www.inf.ed.ac.uk/teaching/courses/inf1/fp/assignments/ex3.pdf
 
* http://www.inf.ed.ac.uk/teaching/courses/inf1/fp/assignments/ex3.pdf
 
* http://planet.plt-scheme.org/
 
* http://planet.plt-scheme.org/
* http://matt.blissett.me.uk/uni/course/computing/firstyear/declarative_programming/lSystem/
+
* http://matt.blissett.me.uk/programming/haskell/lsystem/
   
 
Useing Hray to render the Lsystems
 
Useing Hray to render the Lsystems
 
maybe useing metaballs for the branches
 
maybe useing metaballs for the branches
  +
  +
[[Category:Applications]]
  +
[[Category:3D]]
  +
  +
  +
-------------

Latest revision as of 01:33, 25 June 2012

Welcome to the H3D wiki. This page is meant for gathering ideas and suggestions for a 3D modelling application written in Haskell. Writing it should be about exploring the possibilites of Haskell, and adding stuff no other language else has.

Current work:

  • Getting L-systems (["HaskLS"]) working in Haskell, and going on from there.
  • Haskell SceneGraph

Contributors

Please mention your nickname on #haskell, for future reference.

Also, that way we can determine how many people are willing to work on this project in the future.

If you're willing to contribute (in any way: code, idea's, feedback, even money ;)) to this project, please add your name below. (no strings attached)

  • boegel (project idea, creator of this wiki)
  • bourbaki (L-systems and Ogre3D idea)
  • sylvan (scene graph idea)
    • Also, it might be worthwhile to exploit the ongoing convergence of high-end scanline renderers (a la Pixar) and consumer hardware. Next gen hardware (and even current high-end) could definatly produce movie-quality (honestly!) renderings with about the same throughput as a 1000-machine rendering farm, but with much less latency (one computer producing frames every two seconds, instead of a thousand computers producing one frame each every thirty minutes) which is definatly preferably from an artists standpoint.
  • shelarcy (introduce Japanese page and write that summary)
  • Pseudonym (follow Renderman interface)
  • pipe (wolfgang8k):
    • write your own scanline renderer in Haskell, use OpenGL for real-time stuff (or write a renderer yourself)
    • start with a scenegraph (Haskell type) and a simple command line interface
    • use the CLI for basic operations on the scenegraph (adding stuff)
    • create a GUI with buttons which are bound to function like addSphere :: Scene -> Scene
    • keep a list a scenes for undo/redo purposes (a lot of memory, but very simple)
    • figure out a system for selecting objects (selection = list of integers, indices of objects in the scene)
    • functions like translate, scale, rotate of type Scene -> [Int] -> (dx,dy,dz) -> Scene
    • system for editing attributes of objects (radius of a Sphere, intensity of a light source)
    • with OpenGL, you only need a function in IO monad which takes a Scene value and renders it
  • marcusl : maybe interested in providing some scene graph bindings.
  • markw: See SceneGraph. Currently looking at OpenSceneGraph and started looking at CrystalSpace. Both of these target different uses - OSG is for virtual landscapes whilst CS is for games (and so includes 'out of the box' interaction and entity control). Both of these are C++ libraries and libraries to scripting languages have been developed using SWIG (hence my post on Haskell cafe asking if anyone had used SWIG with Haskell). They look like well crafted class libraries but but a missing the next level of abstraction. Haskell can offer a bridge to a higher level of abstraction; what that is doesn't seem to be obvious but a least Haskell will enable experimentation using, for instance, Conal's work. I am particularly interested in algorithmic generation of landscapes and game maps and how you can mimic the natural (and non-natural) process that sculpt the land (ie as the next level of abstraction).
  • lazor: I like the idea. I'm just generally interested in 3D modelling, I'm using wings3d right now. I would use whatever comes out of this effort, test it, write bug reports, etc., maybe even code some stuff. The possibility of collaborative modelling would make me happy.
  • hcube: bullet physics haskell wrapper, blender developer and user, fun project stunts remake, 3d render engine in haskell: LambdaCube
  • subw: I have had an interest in 3D (rendering & modelling) for a long time. I've used several different 3D packages (Cinema 4D, Lightwave) a few years back, I could test, and file bugs. Coding maybe when I know more math :-)
  • jfischoff: New to Haskell. I've been in the game industry for a few years now. Used to work for Emergent Game Technologies on their Gamebryo Engine. Written two little game engines for different companies. I think getting a COLLADA importer written and a pure way to render to images are two tasks I would like to work on first.
  • harrison: tracing instead of rasterization. perhaps a sierpinski flythrough demo. code exists in another language.

Open questions and suggestions

  • What do we want ?
    • An open source application that has to do with 3D modelling. Probably something real-time (like Maya and Blender), but not just another 3D modeller. We want to show off Haskell's strengths, and use techniques unique to Haskell and functional programming.
    • Library of geometric processing functions. Delaunay triangulation, triangle stripification, subdivsion, etc.
    • Pure Haskell linear algebra
    • Interpolated curve and surface library. Bézier, NURBS, subdivision surfaces, etc.
    • Mesh deformation library: smooth skinning, morph target, ffd, etc.
    • Pure Haskell Renderer. Texture mapped meshes as base, build towards shader based global illumination.
    • Key-frame based animation library. Various forms of interpolation. Build to clip based non-linear animation.
    • Transform hierarchies for bones, scenes, etc.


  • What can we use that is already available ?


  • Where do we begin ?

First idea: build an L-system, then create a simple Ogre3D binding to visualize stuff

Second idea: start with a scene graph, and implement simple stuff like polygon soups and parametric surfaces at first

  • How do we use Ogre3D from within Haskell ?

Use a C interface that doesn't exist yet :-)

http://www.ogre3d.org/phpBB2/viewtopic.php?p=76429#76429

or use Hacanon to call C++ code from within Haskell: [1]

  • How far will we go with this ?

Don't know, as long as it's fun !

  • More open questions ?

boegel


One suggestion i would like to make is to use an existing 3D engine like www.ogre3d.org and just write a wrapper in haskell. So one can do all the fancy math stuff in haskell and just push the meshes and such into the engine.

Peter Althainz: There are different wrappers existing for Ogre on hackage: HOgre (http://hackage.haskell.org/package/hogre) HGamer3D-Ogre-Binding (http://hackage.haskell.org/package/HGamer3D-Ogre-Binding) In my opinion, to get started with 3D graphics/animation, using an existing library is a good approach. Writing an own one has its own interesting aspects, but will use up a lot of time and resource. Also with a well structure library, usage can be quite granular.

[The problem with this approach is that it constrains one to use the features of that engine. It is far more interesting to write new kinds of renderers.]

This would make it necessary to write a good and flexible mesh class. I would prefer something with which you can do fancy things like glueing two meshes. Maya has some interesting features that could easily be implemented that way.

bourbaki

Suggestions - idea's - stuff we can use

Here are some ideas (feel free to add !):

Any suggestions are welcome !


boegel


Note to self:

L-system information

* http://www.inf.ed.ac.uk/teaching/courses/inf1/fp/assignments/ex3.pdf
* http://planet.plt-scheme.org/
* http://matt.blissett.me.uk/programming/haskell/lsystem/

Useing Hray to render the Lsystems maybe useing metaballs for the branches