From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA21091; Fri, 9 Apr 2004 01:43:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA20938 for ; Fri, 9 Apr 2004 01:43:05 +0200 (MET DST) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i38Nh4YM001195 for ; Fri, 9 Apr 2004 01:43:04 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1BBjAl-000Ofq-ES for caml-list@inria.fr; Thu, 08 Apr 2004 23:43:03 +0000 From: Jon Harrop Organization: University of Cambridge To: caml-list@inria.fr Subject: Re: [Caml-list] OpenGL Date: Thu, 8 Apr 2004 23:25:33 +0100 User-Agent: KMail/1.5.4 References: <200404081611.25475.jdh30@cam.ac.uk> <200404081735.48692.jdh30@cam.ac.uk> <20040408201909.GC13940@mev> In-Reply-To: <20040408201909.GC13940@mev> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404082325.33350.jdh30@cam.ac.uk> X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 issac:01 trotts:01 lablgl:01 lablgl:01 deallocated:01 callbacks:01 callbacks:01 callback:01 callback:01 allocates:01 vertices:01 vertices:01 texture:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 188 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