Page MenuHome

Graph Editor, allowing "Cursor X" to go into fractions w/ Drivers
Closed, ResolvedPublic

Description

When working is the Graph Editor it can be very important to be able to work with fractions (sub integers), especially when working with Drivers. Currently the "Cursor Y" is hooked up to "cursor_position_y" which allows fractions but "Cursor X" is directly hooked up to "frame_current" which is an integer.

When it comes to working with Drivers, there's no reason why you would ever want to "scrub" the X axis as if it were the timeline. It's being used purely as a grid system with values and in most cases (in my experience) they involve fractions.

As an example, in the attached image you can see my selected key is located at 0.707 in x axis. If I click "Cursor from Selection" the cursor can't ever go to him because it can only use full integers for its x axis.

Even with "No Auto-Snap" toggled on it still can't move into fractions.

Proposed solution would be to have "Cursor X" use a "cursor_position_x" fraction variable but have it snap to integers by default. Then if you toggle on "No Auto-Snap" you can easily go into fractions.

Details

Type
Design

Event Timeline

Seems reasonable, and I wouldn't mind adding support for it.

Would be curious if there are any downsides to this?

@Joshua Leung (aligorith) any comments?

Campbell Barton (campbellbarton) renamed this task from Graph Editor, allowing "Cursor X" to go into fractions to Graph Editor, allowing "Cursor X" to go into fractions w/ Drivers.Sep 3 2015, 1:22 PM
Campbell Barton (campbellbarton) triaged this task as Normal priority.

No objections from me :)

Looks like a perfectly reasonable thing to me.

@Joshua Leung (aligorith), did you want to take this? or fine for me to?

If @Hjalti Hjálmarsson (hjalti) needs this urgently, feel free to do it. I probably won't get to it until the weekend (am giving a talk tomorrow and dealing with a few other things atm).

Yay! I've been wanting this for ages! :D

I agree the functionality is needed but don't quite agree on mixing keyframe snapping behavior with cursor snapping behavior. In animation (not drivers) you almost always want the cursor to be snapped to nearest frame, however you could want to tweak keyframes freely at the same time. Having the cursor also loose snapping automatically would make frame scrubbing confusing. Maybe a separate control in the cursor properties?

Yeah that's a fair point. Honestly the main issue I had with this was in "Drivers" within the graph editor. When using the "F-Curves" I'd want there to be snapping but it just makes no sense having it in "Drivers" ...the x-axis there should function exactly like the y-axis does right now.

Pablo mentioned to me that it would be simpler to have "Drivers" and "F-Curves" have the same x-axis variable, that's why I suggested just allowing that variable to have the option of snapping or not. But after giving it a lot of thought I think "Drivers" should just have it's own x-axis variable because it has nothing to do with the timeline and is all about using an arbitrary grid system of values.

Does this make sense? Perhaps there's a better solution?

@Hjalti Hjálmarsson (hjalti) that makes sense.

Right now, scrubbing the X-axis of the Drivers view also changes the scene's current frame. To clarify the disconnect between driver-x and frame numbers, we should change that behaviour too.

@Sybren A. Stüvel (sybren) you know that kinda makes sense. What is the usefulness of driver scroll to actually scroll over frames?

If there is to be a separation of driver value and timeline, is it too much to do a separate or integrated visual aid for driver value change? Perhaps it would be best to just stick with setting keys on the driving attribute over time, but then you get stuck with frame integer increments. Maybe the single toggle would come in handy here? I agree with the proposal, but it seems to me I'm overthinking.

I've just pushed a bunch of changes adding support for this. The implementation is as follows:

  • In "Animation" mode, the current frame will continue to be used as before, with no changes
  • In "Drivers" mode, the graph editor "cursor x" value will be used. It allows the use of floating point values.
  • The "Current Frame" option in the Snap/Mirror operators will use whichever x-value the cursor uses for drawing the green line

If there are no major changes needed, we can close this task. I'll leave it open for a week (or until after I get back from Siggraph Asia, depending on how busy I get in the meantime ;) before closing it if nothing crops up

Joshua Leung (aligorith) closed this task as Resolved.Dec 2 2015, 4:12 AM