Re: [Caml-list] OpenGL

[Jon Harrop <jdh30@cam.ac.uk>]

On Thursday 08 April 2004 9:19 pm, Issac Trotts wrote:
> What it is about lablGL that means it can never be made to work?

I'll give some background information first. The GLU tesselator accepts a 
polygon (as a list of contours) and a winding rule. It uses this to generate 
a set of non-overlapping OpenGL primitives (triangles, triangle fans and 
triangle strips) which cover the regions in the contours which are deemed to 
be interior according to the winding rule.

When I found out that the (old) Mesa GLU tesselator implementation was broken, 
I tried to write my own. I failed miserably: this is a very difficult 
problem, and the subject of numerous maths and computer science PhDs. A few 
years ago, SGI released their implementation as open source and Mesa adopted 
it. It is now a very powerful part of the Mesa library, IMHO.

Unfortunately, the lablGL interface to the tesselator isn't complicated 
enough. Firstly, it isn't clear how tesselator objects should allocated and 
deallocated. The lablGL library currently lets you allocate a tesselator but 
it is immediately available for garbage collection (I believe this erroneous 
pattern appears in other portions of lablGL as well, outside the tesselator, 
such as NURBS). Anyway, even if you could allocate a tesselator and keep it 
around long enough to use it, lablGL has no facility for specifying 
callbacks. Without callbacks, the tesselator can have no "side effects" which 
is, unfortunately, the only purpose of the tesselator.

To make things more interesting, there is a combine callback which is required 
for tesselating all but the simplest of polygons. This callback basically 
allocates new vertices and calculates any related information for the new 
vertices (e.g. texture coordinates).

So I've written a couple of basic interfaces which do what I need. The first 
is the simplest and most efficient. It accepts a list of contours and a 
winding rule and uses the built-in OpenGL commands to render as a 
side-effect. The second uses custom C callbacks to build up lists of OpenGL 
primitives which are then returned to the ocaml caller. In both cases, the 
combine callback pushes new vertices onto a stack which gets deleted at the 
end of each tesselation.

This is nice, but there is a huge amount more which should be done. It should 
be possible to provide ocaml callbacks which use the "void *" that gets 
passed around to handle arbitrary data. Note, however, that although this 
would provide a superset of the functionality of my routines, it is likely to 
be much slower.

Oh yeah, and you want to be using one tesselator for each CPU, 
apparently... :)

> That one is called camlgl, which seems to have been abandoned.

That's the one, yes. I've never used it...

> I already wrote a binding for GLU using CamlIDL, but I don't recommend
> it since GLU relies so much on callbacks.  It would probably be better to
> wrap Jonathan Shewchuck's Triangle code:
>
>     http://www-2.cs.cmu.edu/~quake/triangle.html

That is certainly a very nice looking library, but it seems to be solving a 
related but substantially different problem (Delaunay triangulation vs 
polygon tesselation)?

Also, it would be nice if there was an elegant way to support OpenGL 
extensions. I'm not sure if this is theoretically possible in the general 
case, as it is likely that other non-trivial interfaces will need to be 
thought up.

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners