[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36779] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: modify fcurve evaluation for bool/enum/ int values.

Michael Fox mfoxdogg at gmail.com
Sat May 21 01:33:48 CEST 2011


Campbell you have gone too far this time, you are not an animator and 
have no businesss fiddling in there, return it bat to the way it was, 
which is how it was designed, it was no where near unituitive before, if 
anything add an option to the curves of rounding value/settings, give 
use some control over it

On 21/05/11 03:12, Dan Eicher wrote:
> On Thu, May 19, 2011 at 5:34 PM, Matt Ebb<matt at mke3.net>  wrote:
>> On Fri, May 20, 2011 at 10:17 AM, Campbell Barton<ideasman42 at gmail.com>wrote:
>>
>>> Aligorith and I discussed this before committing, and are aware of the
>>> implications.
>>>
>>> To me if you are editing floats, but have them converted to ints later
>>> it makes most sense (on a user level), to round them. If the GUI makes
>>> it unintuitive then it should be made intuitive (grid lines when
>>> zoomed in for example), if you want I can add this.
>>>
>> Rounding them to whole numbers, sure, I totally agree, and if floor() works
>> better then I'm all for it. But when animating bool values it makes perfect
>> sense that as soon as your curve crosses from 0 to 1 (not 0 to 0.5), the
>> value is switched on. Same goes for integer values, animating my curve from
>> 4.0 to 4.51 should not switch the value to 5.
>>
>> cheers
>>
>> Matt
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> I totally agree,<  1 == false and>= 1 == true is how I always thought
> it worked.
>
> Dan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



More information about the Bf-committers mailing list