I think I can speed it up a bit.  By applying the 3D grid screening process odf introduced for TDMT Match, the time was cut almost in half.  The marching cubes code requires eight calculations for each corner of a "box" in the marching cubes grid, and I can speed things up more if I pre-compile the corners and do lookups for the shared points.  Unfortunately I'll slow things down again when I apply rotations and axial scaling for each ball, which will require a matrix transform of the entire grid, per ball.

I'm trying to find a way to speed things up using Numeric functions on large arrays, but so far I haven't come up with a fully feasible approach.

I've tested four different falloff formulas for the metaball surface blending.  Of the two that worked, one had apparently well-known (but undisclosed, in most mentions of the process) flaws which prevent it from returning a smooth surface.  The other one seems to have all balls/particles int eh field exerting influence on one another even if they're out of range, which means all balls have to be processed for each box corner.  Unless I can find another function which works.

So the speed problems may be significant, ultimately.  Calculating the particle positions for animation wouldn't be the problem, assuming I can come to understand the math required.  The trouble would be creating the geometry once the particles were calculated.  If the idea is to recalculate the geometry on the fly during animation, there would be problems if each frame took several minutes or longer to generate the geometry.

Hmm, hmm.  Working at it, anyway.

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking.  He apologizes for this.  He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below.  His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.