API design issue: local vs global structure in soft-bodies

[BGB]

well, in my case this is an issue of API design:
do I make a system where each soft-body is a separate solid;
or do I make a system where a single global space is used, and soft-bodies are formed by making collections of points and springs within the space.

former pros:
likely to allow higher performance, since internal effects will be locally constrained, and would also be easier to parallelize, as well as simplifying efficient collision-detection;
gives an object handle that could be used for the entire body.

former cons:
adds extra API complexity (need to manage both the objects themselves, and contained points, leading to an effectively hierarchical object-relation);
would require a separation between soft-bodies and the particle system (the particle system is such a global space);
...


later pros:
allows a single unified interface to manage both soft-body vertices and particle effects (simpler API);
could allow mixing the approaches, for example, creating molecule-like structures;
IMO, generally more "intuitive" for what is being done;
could allow structures to be dynamically linked and unlinked, and allow more more readily hacking things apart;
this seems more like the GL way (me generally following GL-like design aesthetics);
...

later cons:
more difficult to manage performance (likely to require larger spatial partitioning and bounding-volume trees, all intersections are potentially self-intersections, ...);
more difficult to deal with object-related issues (identify a particular softbody, manipulate a softbody connected to a defined model, ...);
would require keeping a lot more information and state per-point, per-spring, and per-face, than is needed with an object-based approach;
...


possible hybrid:
in the case of the particle engine, it could be made such that particle effects are done as part of the softbody system. however, this leads to the case where the complexities of both former approaches need to be dealt with.
some additional new complexities are added as well (in particular, that different soft-bodies would need to deal with charge, pressure, and other effects crossing between objects, ...). however, this may offer a generally more versatile approach than the former, and allow some possibly interesting effects (for example, an ability to have different "particle objects", such as fires or smoke plumes, which could be activated or deactivated, for example, when they pass into and out of view, ...).


initially, I had started on a design where 2 separate systems exist: a particle system and a soft-body system, and where each soft-body is its own object (with many properties being shared throughout the object, such as attenuation factors, ...).

note that soft-bodies in my current pending design share the same handle-space and access functions as rigid-bodies, but also have a few things of their own.

current leaning is towards the 'hybrid' approach.


as for vertex/particle relations, I am currently considering a "spring" system, where each spring relates several vertices (variable per-spring):
2-vertex (line), tension/compression spring;
3-vertex (triangle), tension/compression, conservation of area and flex;
4-vertex (tetrahedron), tension/compression, volume conservation/deformation.

in general, I think this should be sufficient for solid-like constructions (rubber and gel and similar).

fluids could be approximated similarly to how I currently deal with fluids and rigid bodies:
a fluid object is technically non-solid, and rather than generating contact forces, generates pressure and buoyant forces, as well as a uniform viscous drag (so, these 'fluids' neither flow nor conserve volume, but it works...).

potentially combining this with tetrahedral springs could be complicated though, for example, if I wanted to approximate the displacement effects between an object and a tetrahedral structure.

much better would be probably to represent fluids as a kind of "bag of particles" (with some kind of logic for allowing particles or groups to separate and rejoin the group).

however, fluids are not likely something I will deal with right now (as well as their likely unacceptably slow performance...).


note that terminology is under consideration as well, so suggestions for specific terms are also good ('vertex', 'spring', and 'face' could use better terms IMO...).

these terms are reflected in the naming of properties, such as:
BSDE_VERTEX_ORIGIN
BSDE_VERTEX_MASS

BSDE_SPRING_VERTEX0
BSDE_SPRING_VOLUME

BSDE_SPRING_LENGTH_QUADRATIC_ATTN

...


any specific thoughts?...