Keyframe question, what does it mean when dimmed.

I have a situation where a few keyframes on the timeline are dimmed. Using the next/previous keyframe navigation will never stop on them. When you put the playhead on the keyframe the control never shows the little dot in the circle. When I drag that keyframe left/right it will change from dimmed to not dimmed and is then selectable via navigation and so on.

So the question is, what the heck does that dimmed state mean?

I found a note in the documentation with reference to scaling a keyframe sequence. It said that operation might create "sub-frame" keyframes. Sub-frame keyframe are not editable until moved onto a frame.

That sounds a heck of a lot like what I am seeing. However, I have never scaled any keyframe sequence. I've just dragged keyframes left/right. 

Comments

  • Triem23Triem23 Moderator

    Have you ever parented  a keyframed layer to another layer that scales? I've not come across this myself. 

  • edited January 2016

    I have three models in a layer. The world transform of the model layer has keyframes on the position property. Just two. Start here. End there. Each model has keyframes on its respective Transform/position property. These are small "wiggle" movements. On the third model the keyframe at 7 seconds I can move to frames left/right and easily drop onto multiple positions/frames that are "dimmed". I could check for others, but this one I can reproduce now.

    The model layer has no parent. I have a couple of camera layers which have the model layer as a parent. A particle simulator layer has the model layer as a texture.

  • I haven't come across it either and I have scaled keyframe sequences a couple of times. Going by the reference I'm assuming dimmed just means it isn't on a frame boundary. Were you working with the value graph or bezier controls? I would imagine you could easily end up with keyframes that don't hit a frame boundary in HF 4

  • NormanPCN

    When you move the key frame does it flick from blue to dim blue/grey ?

  • edited January 2016

    Yes, when I move certain keyframes from frame to frame the frame indicator does go from blue to dim blue and back depending on the frame I am over at the time. This indication does show before I let go of the mouse button.

    Here are a few screen shots. The timeline is zoomed WAY in so frame boundaries are a good distance apart. You can see the full/dim state and when the playhead is on the keyframe you can see the dot in the circle indicating the playhead is on a keyframe.

    In this vicinity. Two frames to the right goes dim. Five frames to the left goes dim. Sorry, I accidently hit the scrollbar while dragging out subframe screen capture. The ruler shows the time index is consistent.

  • I've actually seen something similar to this a few times in the past month.

    In my case I think? it is due to a different frame rate of my footage vs the project frame rate setting.

  • No media here. All CG. My project is 1080p29.97.

  • A keyframe being dimmed indicates a subframe keyframe, where the exact timing of the keyframe exists between frames. 

  • edited January 2016

    @AxelWilkinson Yes, I believe that must be the case. The question is why and how is it a subframe? I am not scaling keyframes and I understand how that can create subframe keyframes. 

    This big problem here is that Hitfilm does not think a subframe keyframe exists in certain circumstances. If I put the playhead on the keyframe via a double click or move the playhead with the keyboard, and then change the value, Hitfilm will create a new keyframe on top of the one it just pointed to. Now I have two keyframes in the same spot.

    It would seem that Hitfilm is letting me drag/move a single keyframe into a position where it becomes a subframe keyframe. It's not a good thing since we cannot edit/change the keyframe value.

    edit: see my next post.

  • edited January 2016

    @AxelWilkinson Is this in short for subsequent keyframes like in 3dsmax?

    NormanPCN  if it is it's intermediate steps between main objects to create steady /smooth transition from your object it's called tweening, I think I spelt that wrong :/ 

  • edited January 2016

    .

  • edited January 2016

    I just did a quick test. I only did this once so hopefully it repeats.

    New Project. 29.97. A simple comp with a plane in 3D plane mode. I put a keyframe at the start and a keyframe at 1;10. This is keyframe is a normal keyframe and it editable to change it setting and the prev/next keyframe navigation works. Select this one keyframe. Move it left/right one frame and right back to 1;10. It is now a sub-frame keyframe. Which is not editable. If I try to edit it, Hitfilm will create a new keyframe.

    If I drag this one keyframe across the timeline I can see various spots that Hitfilm will consider the keyframe a sub-frame keyframe if dropped at that location.

    I don't think it is right that Hitfilm lets you drag and drop a keyframe and it suddenly becomes a sub-frame keyframe. Hitfilm should be quantizing these things on frame boundaries. In fact when moving Hitfilm is snapping the keyframe movement on frame boundaries. Snapping onto subframe boundaries? At minimum it should be a preference.

    I think Hitfilm is getting rounding "errors" when dragging/moving a keyframe while it computes the new keyframe position. When you create it is quantized to a frame. When you move it it seems to be adding up frame increments and you can get rounding problems where the sum to not exactly match a frame boundary. It should quantize just like creation. Only frame scaling should have a possibility of a sub-frame, and maybe even there we probably should have a preference for quantizing.

    There are work arounds. Don't ever move a keyframe once created. If you do move it and it does become a sub-frame (dimmed), then simply double click the keyframe to get the playhead there and "select" it. Delete the keyframe and re-create it, and don't ever move it.

    Heads up and pay attention for dimmed keyframes. Word.

  • Stargazer54Stargazer54 Moderator
    edited February 2016

    Subframes!?? What the frak?!   In video land that would be a field.

    @NormanPCN ; I was going to suggest delete the keyframe and recreate it.  Good job troubleshooting.  

    Sounds like a bug.  Moving keyframes around would be a natural method of tweaking motion.  It shouldn't just fall into a subframe "black hole".

  • Triem23Triem23 Moderator

    I haven't had this happen in Hitfilm, but I have had it happen in Vegas where a keyframe or edit point shifts to a subframe/field position. In fact, that's why I ended up buying Vegasaur, since it has a "Quantize to frame boundary" function. 

    I've also had this happen in Premiere a couple of times

    So. This comment doesn't help, really, other than noting this kind of glitch can happen in other software. 

  • With Vegas you are allowed to turn frame quantizing off, although the quantize to frames feature does default to on/enabled. I've never had Vegas turn a keyframe into an non editable keyframe as Hitfilm can and will do.

    I also have Vegasaur and I do like the auditor and I have had it say something was not quantized when Vegas though it was. Vegasaur changed it and it actually never moved. There can be a slight tolerance, or fuzziness factor, when you are dealing with frame durations that are irrational numbers. The Vegas and Vegasaur fuzziness tolerance can be slightly different at times.

    I believe it is this fuzziness factor where Hitfilm is tripping over its own feet. Hitfilms right hand is disagreeing with what the left hand just did. Hitfilm clearly snaps the keyframe onto a frame boundary during dragging but the exact time held by the keyframe is off just enough for Hitfilm to think the the keyframe is not on a frame boundary.

    If any other apps also snap keyframe movement and snap to subframes so the keyframe is not editable then they are wrong also.

    To re-iterate, I get why the keyframe scaling feature in Hitfilm can create a subframe keyframe and therefore why Hitfilm has a concept of a subframe keyframe. I don't get the logic of snapping keyframe movement in effect transforming a normal keyframe to a subframe keyframe which is no longer editable.

  • Triem23Triem23 Moderator

    @NormanPCN You're correct. Vegas can turn off Quantize to frame... Intended for audio editing. The times I have had Vegas drop something on field boundaries were multicam cuts. It generates a slight flicker as the cut happens mid field, and it's happened with the Sony multicam and Ultimate S Pro. Both SCS and VASST have confirmed the bug with me, but it's never been fixed. 

    I've yet to encounter this in Hitfilm, but, give it time, yes? 

  • Ahh, never done multi-cam. I've tested the Vegas multi-cam feature.

    I've been one of the cameras in a multi-cam record. A bunch of us had GoPros on our mountain bikes. Jesse had cameras aiming forward and back. Jesse did that edit. He is an editor at NBC/Bravo. He is an Avid guy. That ride, we had a few crashes and semi-crashes and with many cams running, nobody hides.

  • Just playing with this key frame stuff and yes, it is weird.... I can replicate this bug in all the default frame rates except for 25 and 50p, looks like HitFilm has given special treatment to their own PAL system. lol

    .... side note, kinda reminds me of when I'm zoomed all the way in on DVD Architect's timeline and adjusting  the chapter points, with that little black triangle that snaps to the iframe.

    Hesh

  • 25/50 fps can be precisely represented in computer floating point format. The decimals don't do on forever. Obviously I am assuming that Hitfilm may be using FPU for time.

    Technical correction. I used the term irrational number incorrectly. My point was that the number (frame duration) cannot be represented in floating point format. Only approximated and thus the fuzziness I mentioned. 

  • Fixed in HF4 Update 3

  • DannyDevDannyDev Staff
    edited February 2016

    NormanPCN

    The dimmed keyframes are at times that don't correspond exactly to a frame. Keyframes are plotted in milliseconds whereas frames use an integer (whole number) unit system.

    For some frame rates, such as 25fps, there is an integer number of milliseconds per frame (1000 / 25 = 25) so 'keyframes' map easily to whole frames.

    But for other frame rates, such as 24fps, there are are a fractional number of milliseconds per frame (1000 / 24 = 41.67) so not every 'keyframe' will map exactly to a whole frame.

    Keyframes that do not sit exactly on whole frame are referred to as 'subframe' and appear dimmed in HitFilm.

    Subframe keyframes are perfectly valid and still have an effect but cannot be edited or navigated to because the playhead must always snap to frames. This is not a bug.

    If you drag a single subframe keyframe, HF will snap that keyframe to the nearest whole frame for you.

    Keyframes can become subframe in several ways:

    • A selection of keyframes is scaled using alt-drag.
    • The the framerate of the composite shot is changed, causing the keyframes to be remapped to fractional times (e.g. 25 to 24fps)
    • Keyframes are copied and pasted between timelines of different frame rates.

    HitFilm does not give special treatment to any particular framerate. It's just that keyframes, measured in milliseconds, cannot be accurately mapped to frames if the unit systems don't align. Imagine holding two tape measures, one in inches and one in centermeters. At some points the markings will match up and others they won't.

    HitFilm tries it's best to hide this detail from you and will even snap keyframes to frames to your convenience in some cases. For example when moving a set of keyframes on a 24fps timeline, HitFilm will snap keyframes to the closest frame if they existed on exact frames previously.

    There was an issue in HitFilm 4.0 where subframe keyframes were being produced when 'full frame' keyframes were expected which was addressed in the latest update. This is one of those cases where usability is preferred over accuracy.

    I hope this clarifies things.

  • @Danny77uk actually, yes, thank you. 

Sign in to comment