hmm... it´s a little slow on my comp (20fps, 1GHz Athlon, GF2Pro) and looks a little blocky.What gridsize (number of gridpoint in every dimension) do you use? How many balls do you have? How do you compute the normals for your vertices (you should calculate vertex normals by using the derivative of your function not face normals, imho)?

I´m running 30fps on a gridsize of 40, 6 balls with 3.9k to 5k triangles and 4.2k to 5k cubes being computed.

I also have some questions about what you wrote on your HP:

>> 1 - The function MarchCube() takes 3 char values (x,y,z) which define the bottom-left-front vertex of the cube to be tested, the edge length of the cube is assumed to be one.

This sounds like you don´t precompute the positions of your gridpoints during initialisation but instead make them whole numbers for easier acces. Is that right? So you also don´t have a definite area where the balls have to be?


>> A stack of structures that contain (x,y,z) coords is used to simulate recursion ( stack overflows can occur if the surface is beyond a certain size, so this way is safer than pure recursion ).

That sounds like a good idea. However I never encoutered any stack overflow. I either have a smaller recursion depth or you have a lot of local variables in your recursion-function.

>> For each metaball, cubes are tested starting at the center and working outwards along all three axes ( just to be safe ) as soon as an intersecting cube is found, the entire surface is recursively rendered.

I don´t think it´s nessecary to check in more than one direction because you definitely will hit the surface in any direction due to it´s a closed surface.

ok, not much said till here, but:

// metaballs stored in an array
// metaball_t mb[NUM_METABALLS]
for( c = 0; c < NUM_METABALLS; c++ ) {
for( int d = 0; d <= mb[c].effective_rad; d++ ) {
MarchCube( mb[c].x + d, mb[c].y, mb[c].z );
MarchCube( mb[c].x, mb[c].y + d, mb[c].z );
MarchCube( mb[c].x, mb[c].y, mb[c].z + d );
}
}

If I get this right you are starting at the positions of each ball then going outwards till you reach the radius the ball would have if it was alone (no other balls influencing the field). Well, assuming that all of your radii are >0 this is totally wrong (unless I´m completely misunderstanding something). The distance of the isosurface (I assume it´s 1) from the center of the ball is always >= radius! So instead you should start at the effective radius (perhaps with a little less to avoid rouding errors) and then go outwards until you hit the surface.

k, one last thing: I was referring to the non-textured version in everthing I said above. For this I´d think it looks much better with single-color and lighting (since you don´t seem to use lighting my question about your normals above might be answered).

Very nice looking, though I was annoyed at the fact that you obtain the mouse in exclusive mode and then hide the mouse pointer, resulting in an invisible mouse pointer if you run the program in windowed. It makes your program much friendlier to acquire the mouse in FOREGROUND/NONEXCLUSIVE mode.