[Bf-committers] Softbody revisited :)

[Ton Roosendaal]

Hi BM,

Maybe it's easier to move the discussion to this list then.
Below I've put your text in ">" quotes. (For those who didn't read the  
wiki page, it's about conventions for how a user can control simulation  
steps, or actually control "time").

* Proposed: On frame advance, lesser than 10 steps, softbody simulates  
time steps

 > Is fine, but see : origT is interpolated linear from previous calling
 > object_softbody_step(...) to calling it this time .. so it is  
completely unaware of
 > the nonlinear movements the goal targets made within the (up to 10  
frames time line ).
 > What I want to say is : it's on the callers side to care for  
correctness of the goal's
 > evolution in time. Otherways we'd need to carry all that IPO stuff in  
here.

It will depend on speed of course, but my idea was that steps of 10  
frames should still give a softbody simulation "as close as possible"  
to what should have been achieved with doing (in Blender UI) 10 single  
frame steps. How this will be achieved needs to be experimented... I  
still don't really grasp your wiki text about what "time" means for the  
simulator...
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.

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

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


*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?


-Ton-



On 31 Mar, 2005, at 1:00, bjornmose wrote:

> Ton Roosendaal wrote:
>> Hi,
>> I've appended my last mail about the topic, with 3 strategies, and a   
>> proposal to the wiki page here;
>> http://wiki.blender.org/bin/view.pl/Blenderdev/Softbodies
>> -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
> some more thinking about it
>  http://wiki.blender.org/bin/view.pl/Blenderdev/Softbodies
> cheese == :)
> BM
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org