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

Example of before an after the change.
http://www.graphicall.org/ftp/ideasman42/fcu.png

@Michael, this is still discussion, I made this change with the module
owners approval (and after some private mail), so don't think this
goes too far.

@Matt,
How about have boolean values use a different truth test then
converting to an int and checking == 0?

What you suggest seems fine, < 1.0 == False.
This will keep old files with boolean animation working the same, as
you can see in the image above, existing int behavior isn't really
great.

Since users can add their own rna, it very likely that users will end
up animating large numbers - though I see your point that its not a
common use case for animating blender values.

On Sat, May 21, 2011 at 12:07 AM, Matt Ebb <matt at mke3.net> wrote:
> Hi Cam,
>
> On Sat, May 21, 2011 at 4:16 AM, Campbell Barton <ideasman42 at gmail.com>wrote:
>
>> 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.
>>
>
> It would be good to know exactly in which cases this rounding would happen -
>  I can imagine there could be lots of other places where this could confound
> things - fcurves with modifiers, drivers, creating fcurves from python,
> expressions if blender ever gets that capability. Also inconsistencies
> between how one part of the animation system treats these inputs to another
> could cause problems for people too - I see that drivers currently evaluate
> floats to True when they pass 1.0, not 0.5.
>
> The 0-1 behaviour is very clear (once the curve passes the 1.0 point, it's
> True), understandable for users, and every other application I know of at
> least behaves this way.
>
> 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.
>>
>
> This is such a minor issue in the scheme of things I don't think it's very
> relevant compared to the others things mentioned. Most of the integer values
> people will be animating are 0/1 or at least numbers with very few digits. I
> really don't believe that this is enough to warrant it. And even in the imo
> quite unlikely case that maybe it does become a problem in practice, it
> would be better to solve this technical problem internally in a way that
> doesn't change behaviour for users, or old files.
>
> cheers
>
> Matt
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell