[Bf-committers] rest spring length for new softbody objects

[Ton Roosendaal]

Hi,

Yeah, if someone commits in your code without verifying you've got all  
the rights to demand a justification! :)
Even whilst he made an error in that commit, I do want to defend Daniel  
though... he has done a tremendous job in cleaning up horrible old  
mess, and has built the groundlayers of code Blender has benefited from  
enourmously. A lot of cool end-user features I've been adding the past  
months wouldn't have been possible then.

The fix for the edge length error is pretty straightforward too, will  
commit that today. :)

The code restructure I think is fine, it's mostly meant to get softbody  
in sync with how all modifying operations in Blender work now. Hope  
you're fine with it too? We can go over this in irc too if you like.

-Ton-


On 19 Nov, 2005, at 1:01, bjornmose wrote:

> Hi ton
>
> Ack! I was using web-email at work --> strange name in from field =  
> 'somw WUND'( i usally don't do blender stuff at office but reading  
> news while i wait for projects to compile .. a complete release build  
> for our mayor product takes 20 min )
> but i was a bit anrgy about beeing blamed for things i did not do.
>
> things went wrong here-->
>
> (1)
> <quote>
>    - some cleanup of softbody code, was rather splintered and call
>      path was twisted and confusing. reworked main object step
>      routine to do things in a more obvious and consistent manner
>      and without duplicate code
> </quote>
>
> http://projects.blender.org/pipermail/bf-blender-cvs/2005-August/ 
> 004285.html
> in detail
> http://projects.blender.org/viewcvs/viewcvs.cgi/blender/source/ 
> blender/blenkernel/intern/softbody.c.diff?r1=1.41&r2=1.42&cvsroot=bf- 
> blender
>
> well i should have been complaining when i saw that, but was too busy  
> and kind of shocked that softbody code should be that bad; with all  
> that meaningfull named helper functions you/me built in, sweeped off  
> by that (1) .
> 'humm.. ' i thought 'if that's the way clean blender code looks like  
> .. may be i'm wrong here'
>
> some Wund wrote:
>>> --- Ursprüngliche Nachricht ---
>>> Von: Ton Roosendaal <ton at blender.org>
>>> An: bf-blender developers <bf-committers at projects.blender.org>
>>> Betreff: Re: [Bf-committers] rest spring length for new softbody  
>>> objects
>>> Datum: Fri, 18 Nov 2005 11:01:26 +0100
>>>
>>> Hi Jens Ole,
>>>
>>> I would appreciate some more comments from you in the code...
>>>
>
> if it was mine there would be, sure!
>
>>> - What are the position vectors origS, origE and origT again?
>> (Goal)Position at Start of frame,  at End of frame , linear  
>> interpolated in
>> Time. The solver needs to take smaller time steps than one frame.
>> Calulating goal spring forces uses the interpolated positions.
>>> - You added a pointer to "rcs" to several calls, it seems to be for   
>>> edge calculus, but why?
>> I did not want to throw away the default calculation, before this  
>> discussion
>> was finished so i used "rcs" to signal if springs are already  
>> calculated or
>> "default" should do it.
>>> We could better define that for each call to "remake softbody", the   
>>> spring lengths should be set OK, and not leave this to some later   
>>> stage... otherwise we don't know for sure the original edge sizes.
>>>
>>> I got confused a bit here, the lattice code you added makes springs,  
>>>  initializes them, but doesn't set the spring length (which is a   
>>> constant even!). The Mesh code does set spring lengths however.
>> It all was there once *sigh*
>> ----------------------------
>> Revision : 1.44
>> Date : 2005/8/18 11:4:22
>> Author : 'zuster'
>> State : 'Exp'
>> Lines : +3 -12
>> Description :
>> - remove redundant calculation of spring length
>> http://projects.blender.org/pipermail/bf-blender-cvs/2005-August/ 
>> 004310.html
>>> You agree with removing the 'rcs' variable, and set spring length in  
>>>  each "make softbody" calls? I can fix that :)
>>>
>>> -Ton-
>>>
>> Definitly, that's how it was before Daniel *optimized* it all away.
>> Well i was a little frustrated then and decided to wait until that  
>> modifier
>> stack hype was over. So now i speak up.
>> jens ole
>
> Please don't get me wrong, i'm the 'manager' of a pro software team,  
> all scientists! *sigh* and i know all that blaming stuff like 'B says:  
> if A didn't do things like i told him/her to do; no wonder my code  
> does not work' (/me extra personal shudder)
>
> Neither i want to blame any coder to commit code in best intentions,  
> but beeing wrong in details he/she did not see. I did that too often  
> :)
>
> To resume:
> I could have fixed it myself, but i did not want to get stuck between  
> opinions the one and the other coder has, on what is the 'good' way to  
> do it. So i did voice up to have a it decided here.
> After all i try to be constructive without choking running development.
>
> jens ole (bjornmose) .. some times (some WUND)
>
>
> _______________________________________________
> 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