[Bf-committers] Softbody revisited :)

[Ton Roosendaal]

Hi,

This is all going to be too complex... what I try to find is the  
simplest access possible, with the least settings & variables involved.

Currently I'm halfway coding work for softbody (like moving data out of  
object into a persistant SoftBody struct), so will play a bit with all  
possibilities to find something optimal.

My prediction is that we need 2 different things;

1- a simulation stage for finetuning all settings, for all frames, with  
instant updates
2- a method to bake the result, and edit that (like allow layered in  
NLA)

What I was talking about is only stage 1. Below some questions still;


>> 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.

Define "if the above situation doesn't work". If that is "very wild  
movements" the solution we simply offer is a full 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).

If you want initial velocities you just create an initial animation  
that cause such velocties. Then - after baking - you should be simply  
allowed to to cut off that part.

> 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.

Maybe, should need testing if it is required. I can't see useful  
situations for it yet...

> 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.

I've already removed the global SB option, which will become a per  
object setting. And yes, this is the way I meant a reset to be. :)

-Ton-


------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org