[Bf-committers] Softbody architecture

[bjornmose]

Ton Roosendaal wrote:
> Hi,
> 
> Checking on the softbody status;
> http://wiki.blender.org/bin/view.pl/Blenderdev/Softbodies
Note: this is a proposal for vertex/vertex(goal) forces and other outer 
forces (garivation, friction to environment )interactions. The ODE 
solver takes other forces happyly. So it is on the softbodies team to 
decide what kind of interaction should be simulated. ( which will end up 
in the collision detection discussion again ..  i know )

> I'm still hesitating to make a choice for how to proceed with  
> integrating it... with Blender's animation system in mind we can  
> basically make three choices;
> 
> 1) Integrated in Object types (Mesh, Curve, etc)
> The simplest method is adding the necessary data for softbody (like  
> 'spring' and 'goal' constants) to existing structures in Mesh (like  
> vertex groups). That way it can quickly work, including tools for  
> vertex painting etc.
> Disadvantage; add softbody to Curve, Lattice etc. then is very  cumbersome

This is basicly how the current test implementation works. It already 
shows the lack of flexibility in interacting with other objets.
e.g. 'spring' links are only possible within the (original) objects data.
Still there would be the need for an interactive tool for setting up 
spring links. The rule 'edge becomes spring' is too restrictive for many 
needs.

> 
> 2) Generic Object level Softbody data
> Each Object can get the full data required for softbody, including all  
> vertex information (with indices mapped to actual vertices for 3d  
> coords) and springs. Routines (special editing mode?) are needed to  
> convert Mesh->Softbody, edit springs and 'body points', and new tools  
> have to be written for painting tools.
> This is how Maya does it, including the 'error' that arises when  
> editing the Mesh itself; deleting vertices then screws up the indices  
> in the Softbody structure. We can do better, of course. :)
> Disadvantage: This method is a bit 'un-blenderish', especially because  
> the object itself is extended with a lot of data and editing methods...  
> probably causing clumsy (modal) UI methods as well.
> 
> 3) New Object type
> We can also provide a new type of Object, which then offers a 'soft  
> body construction kit' in editing mode, allowing its own editmode for  
> physically behaving bodypoints to be added, springs, painting weights,  
> etc. Main issue to solve then is establishing relationship(s) with  
> another Object (or Objects). However, this can be done based on a  
> deforming (parent) relationship (like a Lattice), or on a "map indices"  
> method - where the vertex coordinates of a softbody are copied from/to  
> another Object based on index numbers, like in the previous type. Plus  
> it can support Hooks, vertex parents, etc.
> Disadvantage: Making a Mesh Object to "Softbody" then is a bit  
> clumsy... but could be done with an option that automatically converts  
> the Mesh data to a new Object, and inserting it as a Parent...
> 
> Writing down the three choices makes me tend to the third option, which  
> basically is the mythical Emo Object, as being hyped a while during  
> conferences. :)
> Best positive side of the third choice is that it becomes very  
> 'Blenderish', fitting in the current architecture (and UI) nicely.
> 
> -Ton-

humm .. when i read your original code in softbody.c first, i felt those 
questions coming up. Working on it for a while, i saw the entire impact. 
So i decided to commit the code for the physics engine to get this 
discussion running and not making any decition on how to integrate it 
into blender. However, i think there is the need for a higher 
abstraction level than option 1) can offer. Making a choice between 2) 
and 3) is beyond my level of knowledge about 'Blenderish'ness.

-Ole-