* 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 :-)

* 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.

* 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.

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.]

[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.]

Line 140:

Line 147:

* 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.

* 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]

* A 3D render engine written in Haskell: [http://www.haskell.org/haskellwiki/LambdaCubeEngine Lambda-Cube]

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.

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.

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.

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.

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.

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.

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.

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)

A collaborative modeler. Take a look at the 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.