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

Better ignore the zero crossing since the glitch is easily fixed
separately, though it does show this area wasn't well reviewed.

Noticed another issue, fcurve values below 0 cause boolean to become
true (since its nonzero).

Uploaded a patch.
http://codereview.appspot.com/4539076

- Booleans don't round like ints (below 1.0 are false)
- Negative numbers also evaluate to false, this means if you have a
sine wave it will give predictable true/false when crossing the 1.0
value no matter the amplitude.

double checked and driven booleans work the same way.

On Sat, May 21, 2011 at 3:57 AM, Matt Ebb <matt at mke3.net> wrote:
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell