houdini is drawing its keyframes in the timeline as rectangles that their width size, has been expanded from frame N to frame N+1 and placing only on integer frame numbers.
this is completely a wrong convention.

why?

follow below example.

set 3 keyframes with different values at frame 1, 2, 3.
go to animation editor, and scale them down so that all of them to be placed between frame 0 and frame 1.
every thing is OK. we see three keyframes in the 0 to 1 range.

do the same steps but this time do the scaling, in the timeline.
BOOOMMMMMM…. one keyframe has eaten other two ones.

so, what happened?

everything in the animation editor is OK because it represents the keyframe as a point in time. TRUE way of keyframe representation.
but animation has been destroyed in the timeline because it represents keyframe as a time range (frame N to frame N+1) and holds them just on integer frame numbers and doesn't allow placing them in float frame numbers. WRONGE way of keyframe representation.

now imagine a character animator is working on a super cartoony shot that has keyframes every one or two frames and wants to make it faster.
he\she scales down the keyframes placing on some continues frame numbers and thinking logically that keyframes is still there yet, but now on floating frame numbers. some minutes later wants scale them a little up some frames, and then …….uh, where are my hardly tuned keyframes.

yes, houdini has betrayed the animator. it decides the animator doesn't need the keyframes and has deleted them. just because keyframes must be that type of rectangle shape and place over just integer frames.
this is the reason why a keyframe should be a point in time (simple line shaped keyframes in other apps' timeline) not a range in time (houdini rectangle shaped keyframes).

so that nothing bad would happen between rectangle fans vs line fans in regard to keyframe shapes, i recommend a third approach:
a rectangle with the width expanded from (N-1)/2 to (N+1)/2 that vertically doesn't cover the whole timeline height. it contains certainly a spearhead section that showing the animator, true frame number which it is pointing toward it. these keyframes will be able to place over floating frame numbers too in an overlaid mode.

here is two possible shapes of mine, in the attached picture.



PS. i talked about, in picture “tuner” term (animation editor version), in this link.
https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=42069 [sidefx.com]

Before writing such dramatic posts, do yourself a service and read the docs.
You can have floating point representation, even in the timeline.

But when you don't (which is most of the time), having those rectangles is an exact representation of what's happening (completely the opposite of what you say).
A keyframe *does* have a length, like any other frame. It's not just an abstract point in time.

The scaling inside one frame that you described is just a bug and should be reported as such.

If doing “compression” of many keyframes when in floating point time mode, thay should maybe just scale proportionally the width of the keyframes (because, indeed, they do represent “less” time).
To use lines in representing keyframes is much less usable IMO (it's less readable and offers less information).

FIRST OF ALL
pleas look at this subject from animators POV not VFX artists POV, then …

digitallysane
Before writing such dramatic posts, do yourself a service and read the docs.
You can have floating point representation, even in the timeline.

did i say we haven't possibility of setting keyframe on float frame numbers in the timeline ?!!!!
the post is all about keyframes rectangle shape drawing in the timeline not keyframes actual time, and also shrinking (scaling down) multiple keyframes in N to N+1 frame range issue.
the post is such dramatic so that people, do open their soporific eyes and look to the post more precisely and then do start writing reply.

digitallysane
But when you don't (which is most of the time), having those rectangles is an exact representation of what's happening (completely the opposite of what you say).
A keyframe *does* have a length, like any other frame. It's not just an abstract point in time.

now do this one.

1. create a box, for tx:
2. set a keyframe at frame 0
3. set a keyframe at frame 1
4. open the animation editor for tx

what are you seeing?

a big block which has occupied the range 0 to 1,
or 2 dots (your abstract point in time) with a connector spline (a segment of created fcurve). 3 components in 0 to 1 range.
how would be exact representation of those two keyframes in 0 to 1 range as rectangle shapes (NOT BEYOUND THE 0 TO 1 RANGES. those time ranges belong to another abstract points in time.) in a form that be readable at the same time by the animator. send me a picture.

if you are thinking yet, for drawing second keyframe rectangle from 1 to 2 range, set your second keyframe at float frame 0.5 instead of integer frame 1.
are you able distinguish two keyframes shapes in the timeline from each other? i see just one rectangle not two. do you see your two keyframes as two rectangles? is the rectangle, an exact representation of keyframe in the timeline in current format which is placing on just integer frames?

digitallysane
The scaling inside one frame that you described is just a bug and should be reported as such.

it might. but this bug is issued due to that wrong assumption. what will be the fix? drawing them all over each other in current format (HINT: keyframes shape positioning in timeline is just limited to integer frame numbers only now). again, the same issue described in setting two keyframes at frame 0 and frame 0.5.
now you see why i offered those new shapes with the ability for placing over float frame numbers along with a spearhead in the middle for pointing to actual frame number.

digitallysane
If doing “compression” of many keyframes when in floating point time mode, thay should maybe just scale proportionally the width of the keyframes (because, indeed, they do represent “less” time).

NOP, this is false. given a limited active range for the timeline. for example 1 to 9, and do the examples. you see …

digitallysane
To use lines in representing keyframes is much less usable IMO (it's less readable and offers less information).

i agree with you in this case and that is the reason why i wrote such a dramatic post, along that dramatic picture, and those dramatic new keyframe shapes

digitallysane
A keyframe *does* have a length, like any other frame. It's not just an abstract point in time.

OK, I think some disambiguation is in order.
Unless we're talking about the physical world, in which we have discrete time (or do we? anyway, the smallest instance which is actually an interval is the Planck time), in 3d AFAIK we have a continuous time which makes it possible to have an infinity of points on a finite curve segment. We are dealing with points on a curve when editing keys in the anim. editor, aren't we?

Now, at render time a frame can of course be an interval when MB is enabled given by the established FPS and is taking into accountthe previous and next instance in time while the camera shutter is kept open.

As always, I'll be happy to stand corrected if I'm wrong about these things.

@sorian I too brought into discussion the way Houdini represents keys, almost exactly your points. Even created a few RFEs with pics and all, one of them fortunately saw the light - you no longer see a mass of green on the time line when having consecutive keys, they have a little space in between. A good step in the right direction, but more are necessary IMO.
Please create a RFE based on this thread.

sure @McNistor. i will.

McNistor
As always, I'll be happy to stand corrected if I'm wrong about these things.

Fwiw, No one is going to correct you as the cost in dollars terms of an Indy license relegates any mistake that the devs might make into a non-issue.

When there was real dollars involved it was more important to argue for the best tools.

sorian
FIRST OF ALL
pleas look at this subject from animators POV not VFX artists POV, then …

That's exactly what I'm doing. It's you who brings a very abstract/digital perspective on this.
An animator usually thinks in 24 fps (or, anyway, in discrete, integer frames).

If you think in terms of an exposure sheet or at least a dope sheet, a keyframe is just a frame, which has a length like any other frame. Any 2D software makes this very clear, and for good reason (look at ToonBoom, Flash, TV Paint).

The situations when we do bother with float time are exactly those related to VFX (simulations) or specifics of the medium (motion blur, interpolation).

Incidentally, one software that does represent keyframes as kind of points/diamonds is AfterEffects, and, funny enough, I see people very often confused by time ranges in AFX exactly because the length of a frame is not very obvious when looking at the timeline.

sorian
did i say we haven't possibility of setting keyframe on float frame numbers in the timeline ?!!!!

Yes, here:

but animation has been destroyed in the timeline because it represents keyframe as a time range (frame N to frame N+1) and holds them just on integer frame numbers and doesn't allow placing them in float frame numbers. WRONGE way of keyframe representation.

Which is false.

what are you seeing?
a big block which has occupied the range 0 to 1,

Exactly what an animator expects to see in a dopesheet.

or 2 dots (your abstract point in time) with a connector spline (a segment of created fcurve). 3 components in 0 to 1 range.

Exactly what I expect to see in a spline editor.

it might. but this bug is issued due to that wrong assumption.

Not at all. The fact that you don't agree with something (or don't understand it) doesn't make it wrong. No matter how long or agressive your posts are.
It just looks to me that you don't know (or don't like) the difference between a dopesheet and a spline editor. They are different tools, and part of that difference is the way they represent stuff.

what will be the fix?

Considering recent history, the fix will probably be a preference, which seems to be lately the way to deal with very vocal users.

McNistor

digitallysane
A keyframe *does* have a length, like any other frame. It's not just an abstract point in time.

We are dealing with points on a curve when editing keys in the anim. editor, aren't we?

Yes.
The core of the problem is that a spline editor is different from a dope sheet.

digitallysane

McNistor

digitallysane
A keyframe *does* have a length, like any other frame. It's not just an abstract point in time.

We are dealing with points on a curve when editing keys in the anim. editor, aren't we?

Yes.
The core of the problem is that a spline editor is different from a dope sheet.

And the problem is that they probably shouldn't be that different
If they deal with the same thing, I'm arguing that it's better to keep it consistent. Right now, the timeline is consistent with the dopesheet (but not the curve editor) and IMO consistently bad and I think they need to reproduce what they display more closely to the curve editor.

Having centered lines (with some width obviously, not just 1 pixel) which BTW is closer to discrete values as a representation is a thing of little importance. What is more important is that they're easier to manipulate in a timeline and a dopesheet. I come from a software that represents keys as lines on the timeline and rectangles in the dopesheet as Houdini does (so no consistency there either)and I always disliked the dopesheet while finding the timeline much better to work with. Unfortunately on a timeline you don't have the power you have in a dopesheet, so I had to deal with it.

I'm hoping Houdini takes a step into the future and forgets about this “standard” which is probably from Maya, the all-time leader in setting bad standards.

McNistor

digitallysane
The core of the problem is that a spline editor is different from a dope sheet.

McNistor
And the problem is that they probably shouldn't be

McNistor
If they deal with the same thing, I'm arguing that it's better to keep it consistent.

I can't say anything different from what I already wrote.
You don't seem to know or understand the difference between those tools or what needs (and users) they address, so you simply come with some sterile UI debate that simply ignores the real users (the animators) of those tools.

They deal with the same thing in different ways. If they would be the same, you wouldn't need 2 anyway.

MartybNz
Fwiw, No one is going to correct you as the cost in dollars terms of an Indy license relegates any mistake that the devs might make into a non-issue.

When there was real dollars involved it was more important to argue for the best tools.

This is quite the non-sequitur: what does an user correcting me about a technical issue have to do with the SESI's economic side of things.

Improving a software interface and usability can in fact help that application in the long rung, but I don't know and don't care about where “real dollars” are involved, that's part of a plan of business decisions every business owner has to make. It would be a quite condescending act from my part to pretend that I can help SESI make good business decisions. As a user all I have to do is to give feedback and propose improvements that I'd like to see.

digitallysane
I can't say anything different from what I already wrote.
You don't seem to know or understand the difference between those tools or what needs (and users) they address, so you simply come with some sterile UI debate that simply ignores the real users (the animators) of those tools.

They deal with the same thing in different ways. If they would be the same, you wouldn't need 2 anyway.

I know very well what needs those tools address. And I'll have you know that I'm a real user. What legitimizes a “real user” anyway? Working as a hobbyist? As an employee? Pretty sure all of us are those things On and Off at some point in our lives.
I've expressed my opinion on this as you and the OP have and now I move along. To another sterile debate most likely.

McNistor
And I'll have you know that I'm a real user. What legitimizes a “real user” anyway? Working as a hobbyist? As an employee?

You're taking this in the wrong direction. It is explained in my post who the real users of the tool in question are: the animators.

We were talking about Spline editor vs Dope Sheet.

The first is an all-access data editor (splines, expressions, tangents, floating point time, name it).

The latter is a carry-over from traditional animation (usually done on 24 integer fps), targeted mostly at animators, as a blocking and timing tool.

The intended usage is the reason for the very different way they represent keyframes. Saying that they should be more consistent while ignoring their purpose feels kind of pointless to me. Animators want a dopesheet because they want a dopesheet, which is supposed to be a table-like, discrete representation of time.
Like this:

And this:

and this:

I'm becoming more and more certain that you didn't understand what I'm actually proposing. Which would be a good thing as that means we could still reach a consensus.
Being more consistent doesn't mean to make them the same. Of course that that would mean that you'd actually have just one editor instead of two.

In the 2nd pic, if I'm not mistaken, those are clips and clips are intervals so that image is not a good example.
In fact, the 3rd one is not a good example either, at least not one that supports your position it kinda helps mine. I'm not familiar with toon boom (not actually worked with it, just know of it) but it's irrelevant - it's clear from the image that even though the keys are thick, they're not actually represented like an interval since the frames are the spaces between the small lines, while in Houdini the frames are the actual lines. How can I tell? I see where the time scrubbing handle is positioned at: on a line in Houdini, in between lines in Toon Boom.

I've attached something I've proposed in a thread (and RFE) a while ago. The red key between those green ones is sitting on a non-integer frame. This is a quick dirty edit, those I've submitted with the RFE were detailed and well constructed with additional features.

I forgot to add: if we're going to show how other apps do it, I could show you how After Effects represents keys on its dopesheet timeline thing, but I don't think that's relevant, i.e. how other apps do it. Bringing other apps as examples is fine but we should focus on why it's better one way or the other and not stop on “other apps do it” or “it's a standard from here or there”.

McNistor
I'm not familiar with toon boom (not actually worked with it, just know of it) but it's irrelevant - it's clear from the image that even though the keys are thick, they're not actually represented like an interval since the frames are the spaces between the small lines, while in Houdini the frames are the actual lines. How can I tell? I see where the time scrubbing handle is positioned at: on a line in Houdini, in between lines in Toon Boom.

That's irrelevant. There are some differences (and I would argue Houdini's better), but the fundamentals are the same: in both packages frames have a length.

They start at a line and end at the next one. Keyframes are between those lines.

In your proposal, a keyframe starts somewhere in the previous frame and ends somewhere in the next one. I see no benefit in that, and it doesn't reflect reality.

Your “current” image shows a very clear representation of what is happening (in an integer world): you have a pose that lasts for the length of that frame.
IMO, there is absolutely nothing better or more useful or simply more legible in the “proposed” version. Quite the opposite, I find it confusing. And that's because it does exactly what you say: it tries to be more like the spline editor.

If I would have a RFE, it would be the complete opposite: I'd rather have a preference to also show, in a dimmed form, the length of the frames in the Spline editor (to the right of the keyframe vertical line).
But that's in the “nice to have” camp, I can live very well without it (and with a dopesheet).

There's lot of stuff to be done for the Dopesheet, but the keyframe representation is good as it is, IMO.

I'm not sure if this is a terminology communication issue we're having or what. I mean if you go by what googles says after a what is a frame in animation search:

A key frame in animation and filmmaking is a drawing that defines the starting and ending points of any smooth transition. The drawings are called “frames” because their position in time is measured in frames on a strip of film.

it doesn't do anything good to make things clearer. A drawing can't define both the starting and the ending point of a transition. You need two drawings for that. Unless it's referring to the end of the previous transition and the start of the next one, which would make it an instance.
So now I'll address your comments, with no regard to the terminology of the traditional animation (a blasphemy).

digitallysane
in both packages frames have a length.

No they don't. What length is that, can you give me a number? Doesn't your time cursor snaps from one frame to another? If it doesn't travel smoothly then it's because they're instances not intervals. The length of a frame becomes meaningful at render time and it varies with FPS and other MB settings. If you disable MB you're going to have a number of snippets/instances of time which make up a second by being displayed in a sequence for a specified interval (and from here probably comes your confusion - just because they're displayed for an interval of time doesn't make them intervals), a number which is based on your FPS . Enabling MB makes it so that a frame becomes an interval (not really, it still is just an instance), as it considers the previous and the next frame (of course you have different settings for these) and its length is dictated by the shutter speed which for a 30FPS animation would make a frame of a maximum length of 1/30 secs (or more if you're looking to achieve something surreal). Again, the length here is used non-literally -frames rendered with MB have length in the sense that they consider their surroundings, they're still instances displayed on screen each for a time interval.

The fact that you can set keys with non-integer positions on the timeline doesn't make frames intervals, it just means that we're dealing with continuous time.
Thus, keyframes are discrete values, some kind of marks on or in between other discrete integer values referred to as frames.

Starting from the assumption that frames are intervals, will make my proposal image to be confusing indeed.

Having keys represented as they are, is so not Houdini like.

@digitallysane, My friend,


read this as respond to your last post to me and to relief your misunderstanding about the problem in a practical example.
i can not do continue repeating myself again and again and telling the same story with different orthography in post after posts.
so please read this more precisely.


if i brought in the animation editor look as a deduction tool, it was just for more clarifying of the subject. by involving the dopesheet editor in discussion you only make the matter more confusing.
i am seeing many animators in maya world (todays character animation lead package) that never touch the dopesheet editor at all, and make their all job down in other editors and UIes. (i don't want to say dopesheet is useless.)
involving dopesheet editor doesn't add anything to the discussion. the same rectangle shape loyal to integer frames that has issued that scaling problem now we see in another editor with exactly the same problem.
if you are doubtful yet about what is the problem, i shall describe one last time the problem. i hope this time you be able to get what is the issue in practical world.

so,

animators are thinking in 24fps and keyframes are at integer frames, ala what you are seeing in the dopesheet, yes your right. but caution, thats just the final look.
here we are talking about the process which leads the animator to that final look not only the final look itself solely. this is a common way of working that animator starts by setting keys at integer frames, and then at some points that will come surely, decides to scale them up or down for tuning his animation. this leads certainly to floating number keyframes. when he got satisfied of the final look, he retrieves keyframes exactly over integer frames for final rendering via a fcurve BAKING PROCESS.

but at that scaling phase, houdini timeline with current architecture makes annoying difficulties for the animator and kills some of his hardly crafted keyframes.
did you understand now, why we need floating point frame placement of keyframes? i hope you did. i can not explain this better.


regarding the abstract example, this is a common way for describing of weired situations in problem solving. these abstract examples make the foundation of what we see as a general final solution for every problem. these are main building blocks of the final solution. if we obscure them the solution might work in some degree, but failing at some points. just look to that super fast cartoony example in the first post. yes, animators certainly can make their animations currently in the houdini timeline, but that scaling abstract example is troublesome and reveals itself somewhere.
abstract examples addressing extreme conditions.

digitallysane
Yes, here:

that was for, after scaling keyframes in the timeline not for setting fresh keyframes in the timeline. please read posts carefully.

digitallysane
The fact that you don't agree with something (or don't understand it) doesn't make it wrong. No matter how long or agressive your posts are.

i don't want to bother anyone. that in there was just a par reaction to your aggressive reply. please read and think and write in peace, then you'll get most of your answers. previous posts were enough informative.

digitallysane
Considering recent history, the fix will probably be a preference, which seems to be lately the way to deal with very vocal users.

I'm not agree with you. SESI people are hearing all voices always, and choose most appropriate solutions when they want to focus on a specific subject in their development road map.




i think i told everything was necessary.

You're going to have all sorts of troubles representing something in a manner that doesn't reflect how and what it actually is.

In this case representing keys as non-centered on frames intervals.

I'm all for making approximations* if they can help the user in some manner, but in this case having interval like keys doesn't come with any advantage, quite the contrary.

digitallysane
Considering recent history, the fix will probably be a preference, which seems to be lately the way to deal with very vocal users.

Two can play that game: the fact that the fix is going to be a preference instead of the only way something works is a way of dealing with users that are unable or unwilling to adapt.

*approx. not downright misrepresentations. For example I was ignorant about the viewport shading issue and as soon as I learned different, I've toned it down to the point of “let the devs deal with it when and how they can so that it's going to make sense in Houdini and Mantra context”.

I would argue that Houdini has a pretty simple and consistent approach that fulfils both camps in a decent manner.

If anything and for the sake of perspective, UI conventions that have been adopted everywhere are things we should be careful to change unless they bring some truly meaningful value, for example the approach Modo has taken of having an x-sheet mode to animate.

I totally get the point of both philosophies but I would vote for a conservative approach rather than a big departure. May be would be as simple way to indicate the keyframe represented by this green box is not an integer or there are more keyframes than 1 in that time-span by changing the shading of the box?

my 2 cents

But why be conservative when it comes to making an improvement? The current model brings nothing and I mean nothing as an advantage over the proposed model.

Right now a key eats up all the space between frames (which according to digitallysane is the actual frame), space which could be used for displaying a non-integer key. WIth options like “collapse it on the integer key when moved” and others that can't think of, you could have a very powerful dopesheet and timeline.

What are the advantages of the current model over the proposed one? Other than legacy and other subjective things like “I like it better that way” (which I can understand, but no one should present that as an argument for how it's objectively better).

If people like it this way and it turns out they're the majority and SESI will decide to keep it unchanged because of that, then fine, so be it. A missed opportunity, leave it behind, forget about it and look out for the next one.