blender
/
blender
135
420
Fork 603
Code Issues 6.3k Pull Requests 753 Projects 19 Wiki Activity

Anim: Change how Only Insert Needed works #115360

Merged
Christoph Lendenfeld merged 11 commits from ChrisLend/blender:refactor_insert_needed_logic into main 2023-11-30 14:45:59 +01:00
Conversation 2 Commits 11 Files Changed 1 +4 -4
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit cbe686f9ee - Show all commits

8
source/blender/animrig/intern/keyframing.cc
View File

@ -227,7 +227,8 @@ static eFCU_Cycle_Type remap_cyclic_keyframe_location(FCurve *fcu, float *px, fl
/**
* This helper function determines whether a new keyframe is needed.
* A keyframe doesn't get added when it is the same value as it's two neighboring keys.
* A keyframe doesn't get added when it is the same value as it's two neighboring keys,
* or if there is already a key on the frame with the same value.
*/
static bool new_key_needed(FCurve *fcu, const float frame, const float value)
{
@ -243,9 +244,8 @@ static bool new_key_needed(FCurve *fcu, const float frame, const float value)
fcu->bezt, frame, fcu->totvert, &replace);
if (replace) {
/** In case there is a key at the current frame just let
* the keyframe insertion code do its thing. */
return true;
/* If there is already a key, we only need to modify it if the proposed value is different. */
return !IS_EQF(fcu->bezt[bezt_index].vec[1][1], value);
}
nathanvegdahl marked this conversation as resolved Outdated
Nathan Vegdahl commented 2023-11-30 11:32:48 +01:00
Outdated
Review
Copy Link

Is there a particular reason to use compare_ff_relative() for a key that already exists, rather than just a straight == comparison? My intuition is that since there's already a key there, the worst-case with a false positive is that the existing key gets slightly adjusted by a minuscule amount, which seems fine. And then we avoid any risk of false negatives. But I could be missing something.

Is there a particular reason to use `compare_ff_relative()` for a key that already exists, rather than just a straight `==` comparison? My intuition is that since there's already a key there, the worst-case with a false positive is that the existing key gets slightly adjusted by a minuscule amount, which seems fine. And then we avoid any risk of false negatives. But I could be missing something.
Christoph Lendenfeld commented 2023-11-30 14:28:52 +01:00
Outdated
Review
Copy Link

Fair point. Changed it to a simple !=

Fair point. Changed it to a simple `!=`
BezTriple *next = nullptr;