Clean keyframes script?

[Víctor Paredes]

Hello, everyone.
I'm looking to remove many unnecessary keyframes from some files, but the process is tedious and was wondering if in the past anyone has done this or something similar with a script, maybe.
I'm thinking in a script that could remove every keyframe which has no value variation in the frames immediately before and after it.
If the value is the same in the key and its previous and next frame, then it would mean the key is not moving anything (unless I'm not thinking it right).

Do you know if there's something similar to that concept here?

[Breinmeester]

Hi Victor. I think this would be easy enough to code, for rot, pos & scale on bonses at least. If you're pursuing that, i would be interested in such a script. Let me knnow if you need any help.

[chucky]

Sounds like a great keyframe filter idea, for when auto freeze goes bad.

[hayasidist]

I'd done a short think about this some while back - this is where I'd got to.

can be for any keys really -- there are only 6 channel types (7 if you count "unknown") Bool, String, Color, value, vec2 and vec3. so the need is to define what "equality" means for Real numbers (i.e. do you need exact equality to the stored precision or is it ok to be +/- (say) .00001[%] - IOW can 3.0 be considered to be "equal to" 3.00001 and to 2.99999?)

I think the outline logic is

Code: Select all

for all channels with >2 keys
 anchor key = value at **last** key
 for all keys other than last and at 0
  candidate key = value at previous key to anchor { GetClosestKeyID(when) searches backwards thru the timeline }
  if candidate value Equals anchor value then
    delete candidate
  else
    anchor = candidate
  end
  candidate = next (i.e. previous to candidate)
end

hth

[synthsin75]

I don't have time to test this thoroughly, so let me know if anything is off.
Works on the whole document.
https://sites.google.com/site/synthsin/ ... ects=0&d=1

[Víctor Paredes]

Thank you very much for the help!
And thank you for the script, Wes. I really appreciate it. Will test it today as soon as I can

[Greenlaw]

This sounds really good. Will let you know soon how it works out for me.

[hayasidist]

duh! sorry all -- I forgot to mention here what was also in my original thought ... if the interpolation is Bezier the fact that the start and end keys are the same doesn't mean the object doesn't move / change. Same for noisy etc. May merit a tweak to the script Wes?

[synthsin75]

duh! sorry all -- I forgot to mention here what was also in my original thought ... if the interpolation is Bezier the fact that the start and end keys are the same doesn't mean the object doesn't move / change. Same for noisy etc. May merit a tweak to the script Wes?

Ah, good point. I guess I do need to match up interpolation settings as well as keyframe values.
What about things like hold and interval?

[hayasidist]

What about things like hold and interval?

ah yes - could be that hold / interval change even though the value does not. But I don't think that matters ...

Actually - that makes me think the "which to delete" is a bit more of a question. For illustration we have 4 keys at frames a, b, c, d (a<b<c<d) and the values at b and c are the same; but we need to keep c and d to preserve the timing, and b is therefore only redundant if a=b=c (and interp mode at a or b is not Bezier, noisy...). If b is redundant (IOW a=b=c) then the interval / hold at a and b are not relevant because the value isn't changing from a->b->c (the interval / hold at c governs the motion curve from c to d).

does that make sense?

[synthsin75]

New version that requires matching interpolations as well: https://sites.google.com/site/synthsin/ ... ects=0&d=1

What about things like hold and interval?

ah yes - could be that hold / interval change even though the value does not. But I don't think that matters ...

Actually - that makes me think the "which to delete" is a bit more of a question. For illustration we have 4 keys at frames a, b, c, d (a<b<c<d) and the values at b and c are the same; but we need to keep c and d to preserve the timing, and b is therefore only redundant if a=b=c (and interp mode at a or b is not Bezier, noisy...). If b is redundant (IOW a=b=c) then the interval / hold at a and b are not relevant because the value isn't changing from a->b->c (the interval / hold at c governs the motion curve from c to d).

does that make sense?

Yeah, I didn't think hold and interval were needed. Just wanted to run that by someone else.

You're logic looks sound to me. Thanks for checking it.

[hayasidist]

Hi Wes,

need a small change?

I don't think that interp mode check is quite right.

It currently reads

Code: Select all

							if 3 the same interp modes in a row then
								if noisy etc in the middle then
									if all values the same then
										intCheck = true (delete middle "approved")
									end
								else -- i.e. if other than noisy etc (includes Bezier - mode 9)
									intCheck = true (delete middle "approved")
								end
							end

I think it wants an extra test for Bezier and either assume it's not "flat" (as below) -- or if you feel so inclined test the "handles" to see if they're "flat"

Code: Select all

							if 3 the same interp modes in a row then
								if noisy etc in the middle then
									if all values the same then
										intCheck = true
									end
								elseif not Bezier
									intCheck = true
								end
							end

and a straight question - (I really don't know the answer yet) - can you do "if color_vecA == color_vecB" -- or for channel type 3 do you need to split the dimensions as in Vec3 (type 6) (But it would be really neat to be able to do "If vec3_a == vec3_b")?

[synthsin75]

Yeah, it's not currently checking bezier interpolation or color values correctly.
Working on those now.

[synthsin75]

Here's the latest version: https://sites.google.com/site/synthsin/ ... ects=0&d=1

I took your suggestion, Paul. I don't know what all the bezier "components" mean, and apparently you can enter any number for that, and after a certain point it seems to spit out random numbers. So I just assumed we don't want to delete any bezier keys.

And color values are now compared by separate rgba values.

Again, thanks for double checking things.

[hayasidist]

... I don't know what all the bezier "components" mean ...

I think it's an index to the settings for the separate x,y,z handles --

a quick look at a file's internals for a 3d Bezier key (actually layer translation in this case) with a "loop" to the next:


{"im":9,"v1":-1.0,"v2":-1.0,
"b":[
{"ao":0.183271,"ai":-0.152106,"po":0.205828,"pi":0.15657},
{"ao":-0.099733,"ai":-0.035167,"po":0.287141,"pi":0.36332},
{"ao":0.000011,"ai":0.013836,"po":0.386905,"pi":0.315506}
],
"in":1,"h":0,"s":false,"t":0}

So a straight guess from me: component 0,1,2 => x,y,z; no idea what would happen if you tried to set / get one that was greater than the dimensionality of the item..

((A complete aside: noted that you have the types / modes in a comment at the end; those are globals with, IIRC, a MOHO. prefix should you prefer to use the constant name rather than the value))