[Bf-committers] Softbody revisited :)
ton at blender.org
Fri Apr 1 17:44:43 CEST 2005
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
2- a method to bake the result, and edit that (like allow layered in
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
> 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
>> > (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 Roosendaal Blender Foundation ton at blender.org
More information about the Bf-committers