Search on "implicit surfaces" for more information than you want.

Marching cubes computes a polygonal approximation to an implicit surface (i.e., an isovalue of a scalar field). Your method deforms independent polyhedra, the *union* of which (assuming your method works) gives that approximation (for the scalar field resulting from the summation of the field functions associated with each particle/sphere). The union operation here is performed by depth testing which can cause problems, e.g., the degenerate case of two co-incident spheres results in worst-case z-fighting.

Your method is O(N^2) for N "metaballs" and also scales linearly with the number of vertices used for each metaball. Marching cubes is linear in the number of grid nodes and screamingly fast in practice due to lookup-tables. Scan-converting metaballs to a grid is, of course, linear in the number of metaballs.

So, yes, there are good reasons people don''t use your method: marching cubes is more general, faster, and topologically correct.

Don''t be discouraged, though, there''s been over 15 years of research on this stuff.

Thanks for the constructive criticism. I''m not discouraged because I think it''s cool and that''s all that really counts.

Just a minor clarification (is it possible to write sentences like this with it sounding snide or sarcastic?! I''m really not trying to...): when used in character modeling, for example, you aren''t going to have every metaball influence every other metaball, because you aren''t going to want the character''s earlobes and toes stretching toward each other. Granted they''re too far apart to matter anyway, but the general idea is to make self-contained metaball groups, like a finger for example, where the metaballs in that group are influenced by eachother but not by any of the other metaballs in the model except for few metaballs that are designated as "join sites," e.g. the finger joint that attaches to the hand. This allows the computations to be lessened and provides a more controlable modeling experience. The resulting run-time is O(kV) where V is the total number of vertices in the model and k is the average number of metaballs in a group.

Of course this still scales up linearly as you increase the number of vertices. But it should provide great control. For example, you could use the system to build volume-correct bones, connect those with tendons (or is it ligaments?), then build muscles and attach them to the bones with ligaments/tendons, and then either skin the whole thing, or simply allow the muscles to blend with eachother which would result in a skin. The bones would be created at design time and the muscles would deform and the skin would blend in real time; the connection sites for ligaments/tendons would be assigned to bone vertices in the modeler. You could also have fat by creating a 3D spring mesh and attaching massy metaballs to it. Most of the metaballs in this implementation wouldn''t be rendered; their vertices would be calculated and used to render the top layer, i.e. the skin unless there''s a compound fracture. I imagine this would be processor heavy, but it would also be awesome. Anyway, this is my vision. Don''t know if I''ll ever actually code a demo, but I want to.

*bump*

Been done. Check out "blobtree" and other implicit surface modeling techniques.

I did a Google search on Blobtrees and it looked like it went back to Marching Cubes for polygonization which is what I was trying to avoid in the first place.

Marching Cubes is a patented algorithm, and I think that''s why nobody has made commercial use of it.

Okay, fair enough. But my point is that I''m trying to find alternatives to marching cubes. Instead of marching through a volume (3D), I want to march across a surface (2D) and deform it based on a reasonable approximation to a metaball field. I''m working on a second approach that should be faster than the first algorithm I posted, but homework comes first.

Have you seen or heard of metaball rendering algorithms that DO NOT use marching cubes (or any similar algorithm)?

Blobtrees are a method for modelling implicit surfaces. You can polygonize them any way you want. You were talking about grouping metaballs to limit their influence; blobtrees are a generalization of this idea.

There are many methods of implicit surface polygonization. Search on "implicit surface polygonization" or similar for info.