Hi Cam, On Sat, May 21, 2011 at 4:16 AM, Campbell Barton <[email protected]>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 [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
