Hi,

I found the cause of the crashes. A patch which should solve the problem
(but changes the API, see below) is attached.

The problem is that the GLU documentation and the GLU implementation
is inconsistent. The GLU documentation claims that:
 
The "combine" or "combineData" callback is invoked to create a
new vertex when the algorithm detects an intersection, or wishes
to merge features.  The vertex is defined as a linear combination
of up to 4 existing vertices, referenced by data[0..3].  The
coefficients of the linear combination are given by weight[0..3];
these weights always sum to 1.0.  All vertex pointers are valid
even when some of the weights are zero.

(emphasis on the last sentence); but the GLU implementation
sets some of those pointers to 0:

static void SpliceMergeVertices( GLUtesselator *tess, GLUhalfEdge *e1,
                 GLUhalfEdge *e2 )
/*
 * Two vertices with idential coordinates are combined into one.
 * e1->Org is kept, while e2->Org is discarded.
 */
{
  void *data[4] = { NULL, NULL, NULL, NULL };
  GLfloat weights[4] = { 0.5, 0.5, 0.0, 0.0 };

  data[0] = e1->Org->data;
  data[1] = e2->Org->data;
  CallCombine( tess, e1->Org, data, weights, FALSE );
  if ( !__gl_meshSplice( e1, e2 ) ) longjmp(tess->env,1);
}

(this is from the SGI GLU code, libtess/sweep.c). By the way, the
the example combiner function in the documentation should crash, too.

Since the vertex annotations are of arbitrary type, there is no default
value we could supply when GLU gives us zero pointers; thus I changed
the type WeightedProperties to

data WeightedProperties v =
  WeightedProperties
    (GLclampf, v)                   
    (GLclampf, v)                   
    (Maybe (GLclampf, v))
    (Maybe (GLclampf, v))

Maybe some other solution, like WeightedProperties2 ... | WeightedProperties4 ...
would be better...
 
Balazs

On Wed, Mar 11, 2009 at 7:15 PM, Jules Bean <jules@jellybean.co.uk> wrote:
Hi,

I've just written some code which uses 'tessellate' from Graphics.Rendering.OpenGL.GLU.Tessellation and whilst it works exactly as expected on simple data sets, it gives a bus error on larger ones (not that large - e.g. 150 points).

This might be a bug in my OS's glu implementation, but I'm also inclined to suspect a bug in all the peeks and pokes HOpenGL uses to handle the data for the callbacks. I don't actually use the callback data (I've set all the data to (0 :: Int) only because there is no storable instance for ()).

Does anyone have a success story with this function? Has anyone used it successfully on larger polygons?

Jules  
_______________________________________________
HOpenGL mailing list
HOpenGL@haskell.org
http://www.haskell.org/mailman/listinfo/hopengl