Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Announce: glome-0.2 (ocaml-based raytracer)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-01-12 (12:18)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer)
On Friday 12 January 2007 01:24, Jim Snow wrote:
> I've been working on a raytracer for awhile, and recently decided to
> remove a lot of experimental code that doesn't work well anyways and
> release the rest under the gpl version 2.  Currently, glome renders some
> of the scenes from the standard procedural database
> (  I thought that, aside from the
> practical utility of generating pretty pictures, some people on this
> list might be interested in using it to benchmark the quality of code
> generated by various versions of the ocaml compiler.

I have altered the code to be more idiomatic OCaml, although it is still very 
not-OCaml. I've removed OOP from the hot path and virtual function dispatch 
has been replaced with pattern matches.

The code is now 1390LOC instead of 1746 (20% shorter). Performance is also 
better. Building the Kd-tree is down from 7.0s to 6.3s.

I have many suggestions for what to do next:

1. Use records instead of float arrays: stronger type inference, more concise, 
purely functional.

2. Get rid of almost all mutation. The core ray tracer has no reason to use 
mutation and all those refs and assignments are confusing and probably slow.

3. Restructure the program again: put independent definitions related to 
triangles in Triangle, put related definitions like the intersection routine 
in Intersect.

Primarily, the program is far too verbose and convoluted. As an algorithm, ray 
tracing is very functional in nature. I think the functionality provided by 
this program could be achieved in half as many lines of code. It could also 
be a lot faster.

> Supported primitives are spheres and triangles.  It uses a kd-tree as an
> acceleration structure.  There is limited joystick support (moving works
> fine, but turning can have unexpected results) for those patient enough
> to tolerate the low framerates.
> I use lablgl for screen output, but there aren't any other libraries
> required outside of the standard ocaml distribution.

Rather than rendering dots, you could generate a polygon mesh. To make things 
more interesting, you could include the depth value in the mesh, so when you 
rotate the scene it gets distorted by OpenGL without needing to ray trace 

> I'm not a very experienced ocaml programmer, so I'm sure there are some
> things I'm doing inefficiently just because I don't know better.  I
> welcome any suggestions that would make my code faster, or reduce the
> memory footprint of my scene representation.

My impression is that you are optimising prematurely. Get the program <1/2 the 
size that it is before you even think about optimising anything. You're doing 
all sorts of manual resource allocation and mutation thinking that it will 
make things faster when, I think, it just makes the program unnecessarily 

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists