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

[Matt Ebb]

On Saturday, May 21, 2011, Campbell Barton <
> How about have boolean values use a different truth test then
> converting to an int and checking == 0?

Personally I'm in two minds, on one hand I think the previous
behaviour is the only one that makes sense for animating booleans, so
that would be an improvement over it currently, but on the other hand
the same arguments can still apply for integers (value becomes 3 when
it passes the 3.0 mark, easier to predict what the final integer value
will be by just looking at the digits before decimal point).

I guess I'm wondering what's the problem that's trying to be solved
here- is it float inaccuracy? Is it the behavior when crossing zero?
They both seem quite abstract to me, relating to corner cases that
aren't terribly likely to be run into day to day. I'm not opposed to
the idea of fixing these issues somehow but I really don't think it
should be done at the expense of having sensible fundamental behaviour
that's encountered much more frequently.

Regardless of what happens though it is *absolutely* essential that
it's consistent across the entire animation system - setting values
via RNA, python, drivers, fcurves, expressions, anything, all must
behave the same way. I can't stress this enough. So the current
situation of drivers evaluating differently has to be resolved.

cheers

Matt