>> the problem i'm encountering is that the movement of the blobs are confined in such a small area. is there anyway to make their area of movement any larger?

Yup, the movement of the balls is restricted to the area you are scanning with your cubes. Or to be more precise: You only get polygons in the area you are scanning so if the ball moves out you won´t render it anymore. Increase the scanning-range (it was GRIDROOT in the sample source you presented before) so you can increase the area where the balls can be in. This will not affect your polycount but it will still affect speed since you have to compute a lot more gridpoints if you stay at the same resolution (being 1 in your sample code).
This is where optimisation can start. All I said above was about polygonizing isosurfaces of ANY scalar field. Once you restrict the ANY you can use these restrictions for optimizing. Let´s for example say that your scalar field f is the sum of N scalar fields fi(x,y,z) = ri/((x-xi)²+(y-yi)²+(z-zi)²) with all ri>0 and xi,yi,zi being the position of ball i :

In this case you know where you expect your surface so you only calculate cubes in that area. Imho best way of doing this:
a) There is a closed isosurface around every (xi,yi,zi)
b) If the ball i is isolated you know the distance r0i your surface would have from the origin (depends on ri and what you had called THRESHOLD). Since all ri>0 the actual distance of the isosurface can only be bigger. So you start checking a cube with a distance of r0i from (xi,yi,zi). If this cube isn´t intersected by the isosurface continue going outwards. a) will ensure you that you will hit a cube that is intersected by the isosurface. Mark all cubes claculated as being calculated
c) If you hit a cube that is intersected by the isosurface and not already been calculated then draw the polygon mark the cube as calculated and calculate all neighbouring cubes.
d) repeat c) until all cubes are calculated (you don´t have to go outwards further once you hit a cube intersected).
e) repeat b) until you did it for all balls. You can skip this step if you know that you isosurface is a single entity (the balls do not seperate).

This would be a first idea on optimizing. Further analytical threatment (knowing how many/which seperate blobs you have for example) might optimize this further.
The basic concept -only calculate the cubes than can be intersected- depends on the type of scalar field you want to polygonize.


>> my current blob structure only keeps track of the blob coordinates. what can i add to this to control, for example, the length and width of the blob?

Not quite sure what you mean by that but: I think you currently have each ball (=blob?) defined by a scalar field of r = 1.0/((x-x0)²+(y-y0)²+(z-z0)²) where (x0,y0,z0) is the position of your ball. First thing you might change is the 1.0 to be any real value X (even negative ones - this results in cavities). X would be something like the radius of the ball. However f = 1/R² (R = SQUAREROOT(x²+y²+z²)) isn´t THE equation to render a ball. Any equation that is raising or falling (falling if you want a result like the balls merging) as a function of only R will do this (X*exp(-R) for example).


[edited by - Atheist on July 31, 2003 9:53:38 AM]

Linear to what ?