- 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 -
-
It's not obvious to me that there exists a sensible way of telling the IK solver to partially reach a target.
That's fair, it may indeed be infeasible. Nevertheless, I think the current…
I've tracked down the source of the bug, which turns out to be pretty simple. The issue is as follows:
There is a buffer channeldriver_copypaste_buf in drivers.cc that stores any copied…
Minor nit: might be a little more readable to have the data members at the top. But not a big deal either way.
Looks great to me! Huge improvement to the code. Just a couple nits.
Naming nit: I would expect these to be called get rather than set, since they're getting something from the object rather than setting something in the object. As in "getters and setters".
I think I slightly prefer the call being in draw_fcurve_curve_bezts() as it is now. It keeps things a little "flatter" (you aren't chasing functions that call functions that call functions).
Bu…
That's fair. I think we have a bit different sensibilities here, but that's fine. And as I said, I don't feel strongly about it.
Over all this looks great! Just some minor comments, and a suggestion about how to compute curve resolution a bit more robustly.
Is this redundant with the code in the if (bounding_indices[0] == bounding_indices[1]) block below? Or rather, I think that code handles a superset of this code. If there's only one vertex, then bounding_indices[0] == bounding_indices[1] will be true (I think?) and it will be added there anyway.
I believe this note about immBeginAtMost should now be moved to draw_fcurve_curve_bezts(), since this function no longer makes any graphics calls.
It took me a bit of thinking to realize the conditions that this handles:
I'm not sure I agree. (I've used a lot of words below, but I don't actually feel strongly about this, so feel free to ignore. I just wanted to present a different point of view in case it's…
Re: maximums and minimums, never mind. It looks like those are in add_bezt_vertices(), which probably makes more sense.
Definitely doesn't need to be part of this PR, but it sounds to me like either using Kahan summation or simply switching to doubles (just for the computations) in the forward differencing code would make sense. Then we won't need to have an arbitrary and (IMO) too-low maximum here.
