[Bf-committers] Meeting minutes May 1 + todo for release

[Ton Roosendaal]

Hi,

>>> Are the softbodies still considered WIP and open to proposals and   
>>> changes, or has it basically been locked off now?
>>
>> My suggestion would be that in time we might find ideas how to  
>> present  such a system better for users.
>
> Ok, to rephrase my question more specifically, if I can find the time  
> to write a review doc within the next week about this sort of thing,  
> will it be seriously considered? Or is this decided "finished"  
> already?

Go ahead! The WIP part is not so much in the simulation code, that  
seems to be pretty OK. So if you mean issues like how to present it  
(buttons, names, layout)?

We also need an excellent doc + tuto on this. Once you get the picture  
(mental model :) it's not too bad. Crucial to understand I think is 2  
issues;

- Goal Springs
   Which provides "stifness" and "damping" towards original vertex  
positions.
   Works with vertex weights.
- Edge Springs
   Which provides same for keeping original edge lengths.

The global "Friction" (in media) is also what currently the "Wind"  
force works with.
The global "RKL" is the hardest to grasp... it's derived from a builtin  
error detecting algorithm which tries to give quality results.

For the values as you have to put in forcefields... we choosed to keep  
it as compliant as possible with how currently the particles work with  
it, which isn't the most intuitive interface either.

> The last thing I heard about the softbodies was "it's WIP, things are  
> still being added, we'll work on the interface later when it's all  
> there", but now with this talk of release, it seems like this side of  
> things is has been quite neglected. An attitude of "the feature is  
> done when the code compiles and has no bugs, regardless of how usable  
> it is for people" is not a healthy one, and it would be  very  
> disappointing if this is the case here.

On IRC (a lot) and weekly irc meetings (can find in the minutes too)  
we've regularly discussed ways to improve how the UI will work with  
softbody. The current implementation is definitely more usable than the  
first.
The users that tested it complained initially about the total  
abstraction presented, and after working with it they came back with  
"it's actually pretty understandable, once you tried".

I think Jens Ole really did a tremendous piece of work, on a complex  
topic something that only few people really can do. He was challenged  
by me (and others) all the time to keep things usable & accessible for  
artists. Presuming we neglect that because we're happy "it compiles"  
isn't very nice...

-Ton-





>> The fact our competitors don't really  do that at least tells me it's  
>> not an easy task... if you want to play  with power, you'll have to  
>> become powerful yourself too. :)
>
> I don't know whether to laugh or cry when I hear this phrase repeated  
> - it's such a cheap cop-out :) It's like saying "oh, it's complicated,  
> so we won't even try to make it better", and completely ignores the  
> importance of good UI design can make. Obviously if a certain amount  
> of 'power' took a certain amount of 'UI frustration and confusion',  
> then all applications that performed the same tasks would be equally  
> usable. Of course this is not the case. It's in how you tackle these  
> challenges that makes the difference, and can set an application above  
> the rest.
>
> In any case, it's not about removing power or being powerful or  
> whatever, it's a matter of doing basic analysis to make it more  
> understandable about what it all means and how the settings  
> interrelate, and ordering things to better fit an artist's workflow. I  
> wouldn't be so quick to use Maya's "a MEL programmer needed for every  
> artist" interface as the benchmark for good design. Maybe it's not  
> easy, but that doesn't mean we can't spend a little time at least  
> thinking about it and working through *now* instead of 'in time' after  
> it's released when it's much harder, and in the history of Blender's  
> open source development so far usually means 'never' ;)
>
> Cheers,
>
> Matt
> _______________________________________________
> 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