[Bf-committers] Softbody revisited :)

[zippy]

How "easy" do you want users to be able to apply the results ? Like if  
they select a mesh and press a button 'soft' will the mesh become a  
soft mesh and once they move the mesh it will if show the 'mushiness'  
of it ?

Or do we have to set all sorts or parameters first .. ?  I vote for  
number one and then have options for tweaking..
So far the test version in cvs is just a mess. How can anyone test it  
out in it's state ?



On Apr 1, 2005, at 10:44 AM, Ton Roosendaal wrote:

> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>