[Bf-committers] Softbody revisited :)

[bjornmose]

Ton Roosendaal wrote:
...
> The simplest solution I first like to check on is just putting the  
> Blender animation system in (time+10), and do 10 simulation steps for  
> softbody.
Should work fine. Exception : There a 'very' wild movements of the 
object (goals) from one frame to the next. But i think we can ignore 
that for now ( and forever ).
I 'd call this "1 frame time distance per simulation step call 
convention". (1)

> 
>  > So i'd propose to make it a task of the caller to split the "up to 
> 10  frame step" to
>  > nice "user desired accuracy in time evolution (means how precise  
> should the goal
>  > target be moved in time; eg 1/10 .. 10 frames)
> 
> I don't understand this... guaranteeing accuracy on large time steps  
> doesn't have be done for me, it should just be possible - for the  
> animator - to quickly walk through an animation with larger steps to  
> 'get the picture', or to 'advance to a new frame for editing'.
> Accuracy on simulation we can restrict (per definition) to single frame  
> steps. .. see (1)
Sorry for beeing knitpicking here .. tzzzzzzzzzzz..  scientists ..
Still, that would be an extra option if the above solution doesn't work. 
Making  more than one simulation step per frame. Just for feeding in the 
proper goal positions, if they did not take a approximatly straight path 
from frame to frame.

> 
> * proposed: On frame advance, larger than 10 steps, softbody doesn't  
> refresh
> 
>  > having a reasonable algo for hop forward as stated above, this  
> restricion could be
>  > weakend by user option
> 
> Maybe larger time steps should also fully reset the softbody system...  
> needs to be checked on if a "not refresh" is useful. For me the "not  
> refresh" means just don't call the simulator, and signal the softbody  
> to be "OK" for that new time.
Having the "1 frame time distance per simulation step call convention" 
we could go forward in time as far as we like in a consistent way. The 
only restriction here is CPU usage to get there :)

> 
> 
> *proposed:
>     - On frame steps back, Softbody resets completely.
>     - On exit editmode, reset completely
>     - While transform Softbody in object mode, do simulation steps, but  
> reset at end
>     - And of course a button in the Panel causing a reset
> 
>  >  ... hum on resetting .. there's still the question : what's the  
> correct state
>  > ( position and velocity vector ) to be reset to ? ( to say it the  
> math way: a dynamic
>  > system is defined by the differential equations ruling time 
> evolution  AND the state to
>  > start from [called initial conditions] .. which (in most cases) 
> needs  all time
>  > dependant variables to have a predefined value at time == t0 )
>  > May be that was not that clear until now, but having keys in the past
>  > (frame_numbers  < 0 )when defining actions was doing that .. so 
> reset  to the first
>  > available key and run time from there ?
> 
> A "Reset" is just setting all speed vectors to zero, and put the  
> body-point locations on desired "goal" for the current frame. Isn't  
> that sufficient?

I am afraid no, as LetterRip said in an other mail on this topic:
 >It is quite possible that the individual might want an initial
 >velocity or accelleration (I think this is generally called prerolling
 >in other simulation packages), so probably a toggle of (initial
 >conditions are 0 OR initial conditions are user defined).

And things get really nasty here. Manual input for inital conditions for 
all vertices is out of reasons here ( unless you want to get killed by 
people throwing marshmellows at you ).

May be we should try a button 'make SB key' which stores current 
positions and velocity vectors and frame number to a 'SB key' data 
structure? When ever timeline (in 1 frame steps) crosses such a key it 
sets SB data. Since we need to do a 'bake' ( which only has to store SB 
vertex positions and frame number ) we're half way there.

finally: ATM if SB simulation is disabled (in 3d header [nasty i know] ) 
but the object itself is 'soft' and intitialized ( by leaving edit mode 
once ) it writes current goal position and velocity vectors to softbody 
data on frame changes, which is a more 'natural' way of setting initial 
conditions IMHO.

BM ( bjornmose AKA jens ole wund )