- Amsterdam, Netherlands
- https://cessen.com
-
Animator, rigger, and software developer. Currently working at the Blender Institute as a developer on Blender's animation system.
Been using Blender since 1998, and worked on Big Buck Bunny and Sintel (two of Blender's open movie projects).
- Joined on
2003-03-21 -
-
I played around with a build, and this computation of the evaluation_step doesn't seem to be right (it gives very inconsistent drawing resolutions, sometimes extremely low, sometimes very high).
I wrote a new ulps-based function ulp_diff_ff() to implement this fix. I think this new function will generally be useful in resolving certain kinds of floating point issues in the future as…
Point 1 appears to be a floating point precision issue. That particular curve is almost completely flat, but is off just enough for normalizing to try to expand it. However, due to how tiny…
Indeed, #110301 resolves point 2 (curve drawing resolution). Before/after:
However, it does not…
Got it! Indeed, that appears to be a bug. Thank you for the report and the video!
I believe the curve resolution issue (point 2 in the issue description above) will be addressed by #110301. In addition to improving performance, that PR also switches to computing curve…
Got it. Thanks for the explanation! I'll add this to the animation & rigging module meeting agenda (this Thursday), to see which solution people prefer.
I'm definitely liking this direction!
I think we should bring up the name in the next Animation module meeting.
Good call. Added to the agenda.
Ah, interesting. I interpreted it to mean "left/right-most key of the segment". Although that's probably because of the fcurve_segment_*_get names, in my case.
In any case, I think the…
Would it be worth taking the time to switch from r_val_final to just returning the value? (transform_snap_anim_flush_data() is also like this.) Maybe not—maybe better as a separate clean up PR.