Fix #105329: Keyframe handles staying in place when using slider operators #105401
@ -224,6 +224,18 @@ void clean_fcurve(struct bAnimContext *ac, bAnimListElem *ale, float thresh, boo
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
static void move_key(BezTriple *bezt, const float key_y_value)
|
||||||
|
{
|
||||||
|
const float delta = key_y_value - bezt->vec[1][1];
|
||||||
|
bezt->vec[1][1] = key_y_value;
|
||||||
|
/* When handle type is HD_ALIGN handles would get stuck unless we move them along with the key.
|
||||||
|
*/
|
||||||
|
if (ELEM(HD_ALIGN, bezt->h1, bezt->h2)) {
|
||||||
|
|||||||
|
bezt->vec[0][1] += delta;
|
||||||
|
bezt->vec[2][1] += delta;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* Find the first segment of consecutive selected curve points, starting from \a start_index.
|
* Find the first segment of consecutive selected curve points, starting from \a start_index.
|
||||||
* Keys that have BEZT_FLAG_IGNORE_TAG set are treated as unselected.
|
* Keys that have BEZT_FLAG_IGNORE_TAG set are treated as unselected.
|
||||||
@ -309,7 +321,9 @@ void blend_to_neighbor_fcurve_segment(FCurve *fcu, FCurveSegment *segment, const
|
|||||||
}
|
}
|
||||||
/* Blend each key individually. */
|
/* Blend each key individually. */
|
||||||
for (int i = segment->start_index; i < segment->start_index + segment->length; i++) {
|
for (int i = segment->start_index; i < segment->start_index + segment->length; i++) {
|
||||||
fcu->bezt[i].vec[1][1] = interpf(target_bezt->vec[1][1], fcu->bezt[i].vec[1][1], blend_factor);
|
const float key_y_value = interpf(
|
||||||
|
target_bezt->vec[1][1], fcu->bezt[i].vec[1][1], blend_factor);
|
||||||
|
move_key(&fcu->bezt[i], key_y_value);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
@ -367,11 +381,13 @@ void blend_to_default_fcurve(PointerRNA *id_ptr, FCurve *fcu, const float factor
|
|||||||
|
|
||||||
const float default_value = get_default_rna_value(fcu, prop, &ptr);
|
const float default_value = get_default_rna_value(fcu, prop, &ptr);
|
||||||
|
|
||||||
/* Blend selected keys to default */
|
/* Blend selected keys to default. */
|
||||||
for (int i = 0; i < fcu->totvert; i++) {
|
for (int i = 0; i < fcu->totvert; i++) {
|
||||||
if (fcu->bezt[i].f2 & SELECT) {
|
if (!(fcu->bezt[i].f2 & SELECT)) {
|
||||||
fcu->bezt[i].vec[1][1] = interpf(default_value, fcu->bezt[i].vec[1][1], factor);
|
continue;
|
||||||
}
|
}
|
||||||
|
const float key_y_value = interpf(default_value, fcu->bezt[i].vec[1][1], factor);
|
||||||
|
move_key(&fcu->bezt[i], key_y_value);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
@ -411,7 +427,8 @@ void ease_fcurve_segment(FCurve *fcu, FCurveSegment *segment, const float factor
|
|||||||
normalized_y = pow(normalized_x, exponent);
|
normalized_y = pow(normalized_x, exponent);
|
||||||
}
|
}
|
||||||
|
|
||||||
fcu->bezt[i].vec[1][1] = left_y + normalized_y * key_y_range;
|
const float key_y_value = left_y + normalized_y * key_y_range;
|
||||||
|
move_key(&fcu->bezt[i], key_y_value);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
@ -424,7 +441,8 @@ void breakdown_fcurve_segment(FCurve *fcu, FCurveSegment *segment, const float f
|
|||||||
segment->start_index + segment->length);
|
segment->start_index + segment->length);
|
||||||
|
|
||||||
for (int i = segment->start_index; i < segment->start_index + segment->length; i++) {
|
for (int i = segment->start_index; i < segment->start_index + segment->length; i++) {
|
||||||
fcu->bezt[i].vec[1][1] = interpf(right_bezt->vec[1][1], left_bezt->vec[1][1], factor);
|
const float key_y_value = interpf(right_bezt->vec[1][1], left_bezt->vec[1][1], factor);
|
||||||
|
move_key(&fcu->bezt[i], key_y_value);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user
"one handle would get stuck" → "handles get stuck unless we move it along with the key".
It's a bit more generic, but does avoid some questions, like "if you now which handle gets stuck, why move both?", or "why not mention which one?". I think the approach of simply updating both is the right one, so that's why I think the slightly more generic comment is better.
Also it describes the issue, instead of the history of the code.
The rest LGTM, so this can be addressed before merging the PR.