GLU Tesselator

BlitzMax Forums/OpenGL Module/GLU Tesselator

matibee

(Posted 2012) [#1]

The glu tesselator was only partially covered by pub.mod/opengl.mod/glu.bmx in that the callback functions weren't supported. So I've added them by adding the following code and rebuilding the modules..

Const GLU_TESS_BEGIN =         100100
Const GLU_TESS_VERTEX =        100101
Const GLU_TESS_END =           100102
Const GLU_TESS_ERROR =         100103
Const GLU_TESS_EDGE_FLAG =     100104
Const GLU_TESS_COMBINE =       100105

Function gluTessCallback(tobj:Byte Ptr, enum_which, callback:Byte Ptr )

~~Everything seems to work.~~
The only thing that concerns me is that I nicked the constant values from my Visual studio gl/glu.h and wasn't sure if they'd be current.

Did I do the right thing?

Last edited 2012

matibee

(Posted 2012) [#2]

It refuses to tesselate anything more than simple convex polygons.

I've tried it in C++ and thrown all kinds of weird shapes at it, and it's been fine.

matibee

(Posted 2012) [#3]

It looks like this is a Windows issue..

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=268952

Basically the calling convention for the callbacks is wrong.

Can anyone help?

Thanks in advance

matibee

(Posted 2012) [#4]

Hey all, thanks for listening :)

The problem was down to the Windows calling conventions and I proved it by running the same code faultlessly on Linux.

I don't know if it's possible to change Blitz function types so I wrote the tesselation routine and all it's callbacks in C.

Works a treat.

AdamRedwoods

(Posted 2012) [#5]

interesting, glad its working. i haven't gotten around to tesselation.

matibee

(Posted 2012) [#6]

Here's the code (not tested too heavily tho!) and it doesn't support the "combine" callback so fails if the polygons are intersecting. (I don't need intersecting polygons in my app yet and I've not decided how to deal with them.)

Of course this means my original mods to pub.mod/opengl.mod/glu.bmx aren't required. Almost seems as if the original author knew something about this issue. Strange...

BMax function defs..

Extern "C"

	'---------------------------------------------------------------------------------------------
	'	Tesselate a buch of double precision vertices...
	'
	'	pDoubles : 	Pointer to the start of the vertices array.  It must be a contiguous
	'				array of doubles... ie [x,y,z,x,y,z,x,y,z,x,y,z...]
	'
	'	pIntegers :	Pointer to an array of integers.  Each value in the array is the number
	'				of vertices to use for each contour.
	'
	'	contours :	The number of contours (also the number of values in the integer array).
	'
	'
	'	Returns :		If successful, the number of indices created.  Otherwise zero.
	'
	Function Tesselate:Int ( pDoubles:Double Ptr , pIntegers:Int Ptr , contours:Int )

	'---------------------------------------------------------------------------------------------
	'	Get the created indices from the previous tesselation operation
	'
	'	Returns : 	A pointer the start of the integer indices back into the original array.
	'				Each triangle is formed by [Triangle1_1,Triangle1_2,Triangle1_3,..].
	'  
	Function TesselatedIndices:Int Ptr( )
		
		
	'---------------------------------------------------------------------------------------------		
	' 	Get the previous index count.
	'	
	'	Returns : 	Same value as the tesselate operation. (defunct really)
	'
	Function IndexCount:Int ()
		

	'---------------------------------------------------------------------------------------------
	'	Free memory used by tesselation
	'
	'	Once you have copied the results of the tesselation you must clean up the memory 
	'	it allocated by calling this.
	'
	Function CleanUpTesselation( )

End Extern

Tesselator.c :

#include <math.h>
#include <gl\gl.h>			// Header File For The OpenGL32 Library
#include <gl\glu.h>			// Header File For The GLu32 Library

#ifndef NULL
#define NULL	0
#endif 

#ifndef BOOL	
#define BOOL	int
#endif 

#ifndef TRUE
#define TRUE	1
#endif 

#ifndef FALSE
#define FALSE	0
#endif 


//  globals
int*	indices = NULL;
int		indicesSize = 0;
int		indexCount = 0;
BOOL	gInvalidPolygon = FALSE;

// callbacks
void __stdcall BeginCallback( int type )
{

}
 
void __stdcall EdgeCallback( int flag )
{

}
 
void __stdcall VertexCallback( GLvoid * i )
{
	indices[ indexCount ] = (int)i;
	indexCount++;
	if ( indexCount == indicesSize )
	{
		indicesSize += 1024;
		indices = (int *)realloc( indices, indicesSize * sizeof(int) );
	}
}

void __stdcall EndCallback()
{

}

void __stdcall CombineCallback( GLdouble coords[3], GLdouble *vertex_data[4], GLfloat weight[4], GLdouble **dataOut )
{
	gInvalidPolygon = TRUE;
}

void __stdcall ErrorCallback( int errno )
{
	gInvalidPolygon = TRUE;
}

void CleanUpTesselation()
{
	if ( indices != NULL ) {
		free( indices );
		indices = NULL;
	}
	indicesSize = 0;
}

int * TesselatedIndices()
{
	return indices;
}

int IndexCount()
{
	return indexCount;
}

int Tesselate( double * pDoubles, int * pIntegers, int contours )
{
	gInvalidPolygon = FALSE;
	indicesSize = 1024;
	indices = (int *)malloc( indicesSize * sizeof(int) );
	indexCount = 0;

	GLUtesselator * tess = gluNewTess();
	gluTessCallback( tess, GLU_TESS_VERTEX, (GLvoid (*) ())&VertexCallback );
	gluTessCallback( tess, GLU_TESS_EDGE_FLAG, (GLvoid (*) ())&EdgeCallback );
	gluTessCallback( tess, GLU_TESS_BEGIN, (GLvoid (*) ())&BeginCallback );
	gluTessCallback( tess, GLU_TESS_END, (GLvoid (*) ())&EndCallback );
	gluTessCallback( tess, GLU_TESS_ERROR, (GLvoid (*) ())&ErrorCallback );
	gluTessCallback( tess, GLU_TESS_COMBINE, (GLvoid (*) ())&CombineCallback );

	gluTessBeginPolygon( tess, NULL );
	
	int vertex = 0;
	int c;
	for ( c = 0; c < contours; ++c )
	{
		gluTessBeginContour( tess );

		int i;
		for ( i = 0; i < pIntegers[c]; ++i )
		{
			gluTessVertex( tess, &pDoubles[vertex * 3], (void *)vertex );
			vertex++;
		}
		gluTessEndContour( tess );
	}

	if ( !gInvalidPolygon )
	{
		gluTessEndPolygon( tess );
		gluDeleteTess( tess );
		return indexCount;
	}

	return 0;
}

col	(Posted 2012) [#7]

Hiya,

Really cool what youre doing there :D

As regards the calling convention issue...
Are you using "Win32" instead of "C"?

gluTessCallback( tess, GLU_TESS_VERTEX, VertexCallback)

Function VertexCallback([...])"Win32"
[...]
EndFunction

I'm using this approach to connect with COM pointers calling into cpp and back into BMax then back into cpp. This approach seems to work ok. I only use the "C" convention when calling to or from from my own CPP code (wrapped in extern"C"{...} ), and I use "Win32" when I call or get called from library code.

*Edited for punctuation.

Last edited 2012

col	(Posted 2012) [#8]

Oh,

I think the gluTessCallback in the BMax binding would also "Win32" on the end too or be in inside a Extern"Win32" block.
I don't know for a fact if they bindings already have that, but I would think it will need it to work properly.

Last edited 2012

matibee

(Posted 2012) [#9]

Hi Dave,

Since cdecl is the MSVC default could it also be a Win-compiler default? In which case I would have thought that the "Win32" calling convention would also be cdecl. As the link above to the OpenGL forum says, these callbacks have to be stdcall.

I didn't know you could do this though..

Function VertexCallback([...])"Win32"

Anyway I'm happy with the workaround, just not so happy with the confusion the initial problem wrought :)

col	(Posted 2012) [#10]

Hiya,

I actually use the VC++ editor to write my c++ code. I don't compile with it, but its a great editor and serves its purpose for what I'm doing and, as I have it installed already, it's all ready to go.

Look here for a brief explanation of the difference between __cdecl and __sdtcall

__stdcall is usually used for Win32 API calls. __cdecl and __stdcall are perfectly valid with MingW. There are various #defines for them both - for eg for __stdcall :-

STDCALL
WINAPI
APIENTRY
CALLBACK
APIPRIVATE

plus more. If I remember correctly they are defined in mingw/include/windef.h
Could be wrong as I'm guessing that file. I think they are declared in different files under MSVC ( winnt.h ? ). There are other defines that are worthy of looking at too. Its worth looking through the headers if only to quickly browse. Something may catch your eye.

If you use the wrong calling convention then it will alter other variables in BMax ( more than likely caused by a messed up stack ) and can cause mayhem, as you've probably found out already :-)

col	(Posted 2012) [#11]

Since cdecl is the MSVC default could it also be a Win-compiler default? In which case I would have thought that the "Win32" calling convention would also be cdecl.

More than likely C language compilers will compile to the language convention regardless of the operating system they are compiling on. It then allows you to change the calling convention within the code to suit any operating system. But I know what you mean :P

As the link above to the OpenGL forum says, these callbacks have to be stdcall.

Yep, as Win32API functions usually are. In BMax functions use the "Win32" decoration to declare the function the same as the __stdcall convention. Or if you have lots of them then you can use an Extern"Win32"...EndExtern block too.