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-15 (18:34)
From: brogoff <brogoff@s...>
Subject: Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer)
On Mon, 15 Jan 2007, Jim Snow wrote:
> Jon Harrop wrote:
> > 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.
> > 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.
> >
> Sorry I'm a bit slow about replying; I was off trying to implement an
> nlogn kd-tree compiler.  Your version seems to have sped up the
> raytracing by about 10%.  However, I think I am going to stick with my
> approach for the time being for the sake of maintainability; I don't
> think putting all the ray-intersection code together in one
> mutually-recursive is going to make the program easy to modify in the
> future.  I am tempted though.  I might also give recursive modules a try.

I haven't coded a ray tracer in a long time, and the one I did was for a
college class, but my recollection is that even in C (the implementation
language I used) the design used classes/objects for the primitives, so
that one could add new primitives and the only piece of code that would
need modification would be the interpreter of scene description files.
I think using classes for that is the right approach. I'm sure you could
do it in a more coreish ML fashion without even using recursive modules,
say by emulating the OO in C approach with ML records of functions, but
it won't be any faster and will be uglier, since the class system
provides a kind of generalized polymorphic record.

This is a nice example for discussing the merits of OO features, and less
complex than the expression problem. A competitive "non-OO" approach
should provide easy extensibility along the same axes as the OO one.
I admit I don't see the need for cross file recursion here.

-- Brian