[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.

[Campbell Barton]

The way fcurve editing tools work right now the curves are clamped to
whole numbers, so in practice I don't think users entering fractional
fcurves for int inputs is such a problem.

We can make it so Ctrl+Clicking and the panel clamp the points to int
too (current ways I could find to set fractions).

float precision error makes me think rounding at 0.5 this is worth keeping,
with larger values and some modifiers applied I bet values over say -
10000 can become 9999.999 which then would get rounded down to 9999.0.
Rounding at 0.5 means just means its less error prone even after
driver, modifiers, unit-scaling.

Really large float values too can't represent whole numbers and get
rounded down wrongly, managed to redo this but was somewhere around
220000 though this isn't really such a normal use case and at these
values drawng fcurves starts to go strange too.

Even so, IMHO rounding this way is best kept and any chance of users
to encounter rounding as an issue they have to deal with can be solved
on the tool/ui level.

On Fri, May 20, 2011 at 5:12 PM, Dan Eicher <dan at trollwerks.org> 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
>



-- 
- Campbell