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

[bjornmose]

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)