Graph Editor: Fcurve extrapolation visibility #76472

Closed
opened 2020-05-06 12:15:25 +02:00 by Stanislav Ovcharov · 31 comments

Tweak option to toggle off visibility of extrapolated f-curves.
Best place for 'Show extrapolation' command with on/off checkbox in the graph editor menu - View.

The option ‘Show extrapolation” is ON

Graph editor behavior is as usual. The option is ON by default.

The option ‘Show extrapolation” is OFF:

Then:

  • Constant extrapolations are hidden.
  • Linear extrapolations are shown.
  • Cycle modifier present but set to No Cycles: see above.
  • Finite cycles are shown. Beyond the cycles: see above.
  • Infinite cycles are shown.

If the extrapolation part of the curves are shown they should be drawn a bit different (lower opacity or dotted) whether show_extrapolation option On or Off.
Single keys. They should be shown just as single keyframes in the graph.

  - But first of all we have to implement the simplest variant 
      - The option ‘Show extrapolation” is On:  shows extrapolated curves.

The option ‘Show extrapolation” is Off. doesn't show extrapolated curves at all, whether it is a cycle, a linear extrapolation or a constant.
Examples:

extra-constant-full-on.png extra-constant-full-off.png

And this are examples for possible improvements on next possible upgrades:
Constant extrapolation:

extra-constant-full-on.png extra-constant-full-off.png
Linear extrapolation:
extra-cycle-linear.png
--
Cycle extrapolation finite:
extra-cycle-finite-left-side.png extra-cycle-finite-full.png
-- --
Cycle extrapolation infinite:
extra-cycle-infinite-left-side.png extra-cycle-infinite-full.png
-- --
Tweak option to toggle off visibility of extrapolated f-curves. Best place for 'Show extrapolation' command with on/off checkbox in the graph editor menu - View. ### The option ‘Show extrapolation” is ON Graph editor behavior is as usual. The option is ON by default. ### The option ‘Show extrapolation” is OFF: Then: - Constant extrapolations are hidden. - Linear extrapolations are shown. - Cycle modifier present but set to No Cycles: see above. - Finite cycles are shown. Beyond the cycles: see above. - Infinite cycles are shown. If the extrapolation part of the curves are shown they should be drawn a bit different (lower opacity or dotted) whether show_extrapolation option On or Off. Single keys. They should be shown just as single keyframes in the graph. - But first of all we have to implement the simplest variant - The option ‘Show extrapolation” is On: shows extrapolated curves. **The option ‘Show extrapolation” is Off. doesn't show extrapolated curves at all, whether it is a cycle, a linear extrapolation or a constant.** Examples: | ![extra-constant-full-on.png](https://archive.blender.org/developer/F9266125/extra-constant-full-on.png) | ![extra-constant-full-off.png](https://archive.blender.org/developer/F9266128/extra-constant-full-off.png) | | -- | -- | **And this are examples for possible improvements on next possible upgrades:** Constant extrapolation: | ![extra-constant-full-on.png](https://archive.blender.org/developer/F9112903/extra-constant-full-on.png) | ![extra-constant-full-off.png](https://archive.blender.org/developer/F8518753/extra-constant-full-off.png) | | -- | -- | Linear extrapolation: | ![extra-cycle-linear.png](https://archive.blender.org/developer/F9112907/extra-cycle-linear.png) | | -- | Cycle extrapolation finite: | ![extra-cycle-finite-left-side.png](https://archive.blender.org/developer/F9112915/extra-cycle-finite-left-side.png) | ![extra-cycle-finite-full.png](https://archive.blender.org/developer/F9112919/extra-cycle-finite-full.png) | ![extra-cycle-finite-right-side.png](https://archive.blender.org/developer/F9112926/extra-cycle-finite-right-side.png) | | -- | -- | -- | Cycle extrapolation infinite: | ![extra-cycle-infinite-left-side.png](https://archive.blender.org/developer/F9112932/extra-cycle-infinite-left-side.png) | ![extra-cycle-infinite-full.png](https://archive.blender.org/developer/F9112935/extra-cycle-infinite-full.png) | ![extra-cycle-infinite-right-side.png](https://archive.blender.org/developer/F9112938/extra-cycle-infinite-right-side.png) | | -- | -- | -- |
Added subscribers: @StanislavOvcharov, @dr.sybren, @LucianoMunoz

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @Oskar3d

Added subscriber: @Oskar3d

A small suggestion. I think it would be useful if the extrapolation part of the curves is a drawn a bit different.(lower opacity, dotted, a bit tinner etc.) It gives a bit more information, so you know there are no keyframes prior or following what you see.
graph_editor_curves.jpg

A small suggestion. I think it would be useful if the extrapolation part of the curves is a drawn a bit different.(lower opacity, dotted, a bit tinner etc.) It gives a bit more information, so you know there are no keyframes prior or following what you see. ![graph_editor_curves.jpg](https://archive.blender.org/developer/F8530548/graph_editor_curves.jpg)

what oscar says would be highly appreciated.

what oscar says would be highly appreciated.

In #76472#929792, @Oskar3d wrote:
A small suggestion. I think it would be useful if the extrapolation part of the curves is a drawn a bit different.(lower opacity, dotted, a bit tinner etc.) It gives a bit more information, so you know there are no keyframes prior or following what you see.

Do you mean to use it with Linear and Cycle extrapolation types only when extrapolation is off?

> In #76472#929792, @Oskar3d wrote: > A small suggestion. I think it would be useful if the extrapolation part of the curves is a drawn a bit different.(lower opacity, dotted, a bit tinner etc.) It gives a bit more information, so you know there are no keyframes prior or following what you see. Do you mean to use it with Linear and Cycle extrapolation types only when extrapolation is off?

only when the visibility of the extra is on, in anytype, to easily distinguish between the "live curve" and the generated one

only when the visibility of the extra is on, in anytype, to easily distinguish between the "live curve" and the generated one

In #76472#929934, @LucianoMunoz wrote:
only when the visibility of the extra is on, in anytype, to easily distinguish between the "live curve" and the generated one

So this thing should be used everywhere/everytime, with this new extrapolation option ON and OFF, shouldn't it? Not to replace new option?

> In #76472#929934, @LucianoMunoz wrote: > only when the visibility of the extra is on, in anytype, to easily distinguish between the "live curve" and the generated one So this thing should be used everywhere/everytime, with this new extrapolation option ON and OFF, shouldn't it? Not to replace new option?

Added subscriber: @antoine.grasset

Added subscriber: @antoine.grasset
Contributor

Added subscriber: @RedMser

Added subscriber: @RedMser

Also would be useful if the extrapolation part of the curves is a drawn a bit different (lower opacity/dotted,/bit tinner/etc.) whether show_extrapolation option On or Off. It gives a bit more information, so you know there are no keyframes prior or following what you see.

@StanislavOvcharov I agree that this would be nice. To make it possible to just implement it without getting more disucssions, can you pick the one you think is best and update the description & screenshots for this?

Once that's done, I think it's fine to get this implemented. @StanislavOvcharov do you have any idea how long it'll take you? Would Blender 2.92 be a reasonable target (so implemented, reviewed, and merged before 25 November)?

> Also would be useful if the extrapolation part of the curves is a drawn a bit different (lower opacity/dotted,/bit tinner/etc.) whether show_extrapolation option On or Off. It gives a bit more information, so you know there are no keyframes prior or following what you see. @StanislavOvcharov I agree that this would be nice. To make it possible to just implement it without getting more disucssions, can you pick the one you think is best and update the description & screenshots for this? Once that's done, I think it's fine to get this implemented. @StanislavOvcharov do you have any idea how long it'll take you? Would Blender 2.92 be a reasonable target (so implemented, reviewed, and merged before 25 November)?

I think this all needs to be much simpler.

On: shows extrapolated curves.
Off. doesnt show extrapolated curves at all, wether it is a cycle, a linear extrapolation or a constant.

The whole idea is to be able to get rid of the extra drawing in the graph editor that makes it harder to view.
Wether we want theeming options for when the extrapolated curves are on I think its secondary (could be a slider for opacity).

I think this all needs to be much simpler. On: shows extrapolated curves. Off. doesnt show extrapolated curves at all, wether it is a cycle, a linear extrapolation or a constant. The whole idea is to be able to get rid of the extra drawing in the graph editor that makes it harder to view. Wether we want theeming options for when the extrapolated curves are on I think its secondary (could be a slider for opacity).

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

I think that information about surrounding extrapolated animation that allow to distinguish cycled animations types is important for editing.

I think that information about surrounding extrapolated animation that allow to distinguish cycled animations types is important for editing.

In #76472#1044375, @LucianoMunoz wrote:
I think this all needs to be much simpler.

On: shows extrapolated curves.
Off. doesnt show extrapolated curves at all, wether it is a cycle, a linear extrapolation or a constant.

The whole idea is to be able to get rid of the extra drawing in the graph editor that makes it harder to view.
Wether we want theeming options for when the extrapolated curves are on I think its secondary (could be a slider for opacity).

I don't mind that about such simplifying if it speeds up implementation but what if you have e.g. cycles for some f-curves? you have to remember that you have got these cycles somewhere on your curves or toggle show_extrapolation on and off back and forth to check it. Described in the task variant allows you to toggle show_extrapolation once and forget about it and do you work in a more calm way

> In #76472#1044375, @LucianoMunoz wrote: > I think this all needs to be much simpler. > > On: shows extrapolated curves. > Off. doesnt show extrapolated curves at all, wether it is a cycle, a linear extrapolation or a constant. > > The whole idea is to be able to get rid of the extra drawing in the graph editor that makes it harder to view. > Wether we want theeming options for when the extrapolated curves are on I think its secondary (could be a slider for opacity). I don't mind that about such simplifying if it speeds up implementation but what if you have e.g. cycles for some f-curves? you have to remember that you have got these cycles somewhere on your curves or toggle show_extrapolation on and off back and forth to check it. Described in the task variant allows you to toggle show_extrapolation once and forget about it and do you work in a more calm way

So it was chosen to implement first the simplest way, just on \ off.
On: shows extrapolated curves.
Off. doesn't show extrapolated curves at all, whether it is a cycle, a linear extrapolation or a constant.

So it was chosen to implement first the simplest way, just on \ off. On: shows extrapolated curves. Off. doesn't show extrapolated curves at all, whether it is a cycle, a linear extrapolation or a constant.
Member

Added subscriber: @wbmoss_dev

Added subscriber: @wbmoss_dev
Wayde Moss self-assigned this 2021-02-13 00:39:35 +01:00
Member

I'll see if I can finish a patch for the simple approach . The upgrades appear non-trivial as I'm not sure how to properly determine the fcurve extents when multiple fmodifiers exists and how they interact with eachother (cycles modifier, limits modifier, restricted ranges, etc).

I'll see if I can finish a patch for the simple approach . The upgrades appear non-trivial as I'm not sure how to properly determine the fcurve extents when multiple fmodifiers exists and how they interact with eachother (cycles modifier, limits modifier, restricted ranges, etc).

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

This comment was removed by @LucianoMunoz

*This comment was removed by @LucianoMunoz*

Cool! but it's not resolved yet, isn't it?)

Cool! but it's not resolved yet, isn't it?)

no he just started :)

no he just started :)

In #76472#1113068, @LucianoMunoz wrote:
no he just started :)

but you closed it as resolved)

> In #76472#1113068, @LucianoMunoz wrote: > no he just started :) but you closed it as resolved)

interesting, I didnt!, and i tried deleting that and i can only mark as resolved or invalid... can you gimme a hand here @dr.sybren ?

interesting, I didnt!, and i tried deleting that and i can only mark as resolved or invalid... can you gimme a hand here @dr.sybren ?
Member

Changed status from 'Resolved' to: 'Confirmed'

Changed status from 'Resolved' to: 'Confirmed'

When the design work is finished, and implementation can start, either one of these two should happen:

  1. Close the design task as resolved (because the design work is done) and create a new TODO task for keeping track of the implementation, or
  2. Re-classify this task as TODO task.

I think the 2nd option is the most suitable here, as it's not a huge amount of work that needs a separate task for tracking it.

The design description has this as 2nd sentence:

Best place for 'Show extrapolation' command with on/off checkbox in the graph editor menu - View.

I don't see a motivation for this, though. Why is this the best spot? What makes this preferred over just having a user preference that sets this?

Is the description of this design task up to date with what's being implemented in {D10442}? If not, please @StanislavOvcharov or @wbmoss_dev update it so that any reviewers know how the code should behave.

When the design work is finished, and implementation can start, either one of these two should happen: 1. Close the design task as resolved (because the design work is done) and create a new TODO task for keeping track of the implementation, or 2. Re-classify this task as TODO task. I think the 2nd option is the most suitable here, as it's not a huge amount of work that needs a separate task for tracking it. The design description has this as 2nd sentence: > Best place for 'Show extrapolation' command with on/off checkbox in the graph editor menu - View. I don't see a motivation for this, though. Why is this the best spot? What makes this preferred over just having a user preference that sets this? Is the description of this design task up to date with what's being implemented in {[D10442](https://archive.blender.org/developer/D10442)}? If not, please @StanislavOvcharov or @wbmoss_dev update it so that any reviewers know how the code should behave.

In #76472#1117488, @dr.sybren wrote:

Best place for 'Show extrapolation' command with on/off checkbox in the graph editor menu - View.

I don't see a motivation for this, though. Why is this the best spot? What makes this preferred over just having a user preference that sets this?

Well it looks logical enough for me to place it here..
2021-02-23_16-36-06.png

In #76472#1117488, @dr.sybren wrote:
When the design work is finished, and implementation can start, either one of these two should happen:

  1. Close the design task as resolved (because the design work is done) and create a new TODO task for keeping track of the implementation, or
  2. Re-classify this task as TODO task.

I think the 2nd option is the most suitable here, as it's not a huge amount of work that needs a separate task for tracking it.

I would choose the option 1 because it is ready for master. And I would leave it even as it is. Looch is right when said that you should know \ remember all your fcurve cycles or linear extrapolation if exist. So there is no big need for further tweaks but I don't mind about it.
So I would edit and close it if you accept.

> In #76472#1117488, @dr.sybren wrote: >> Best place for 'Show extrapolation' command with on/off checkbox in the graph editor menu - View. > I don't see a motivation for this, though. Why is this the best spot? What makes this preferred over just having a user preference that sets this? > Well it looks logical enough for me to place it here.. ![2021-02-23_16-36-06.png](https://archive.blender.org/developer/F9830228/2021-02-23_16-36-06.png) > In #76472#1117488, @dr.sybren wrote: > When the design work is finished, and implementation can start, either one of these two should happen: > 1. Close the design task as resolved (because the design work is done) and create a new TODO task for keeping track of the implementation, or > 2. Re-classify this task as TODO task. > > I think the 2nd option is the most suitable here, as it's not a huge amount of work that needs a separate task for tracking it. > I would choose the option 1 because it is ready for master. And I would leave it even as it is. Looch is right when said that you should know \ remember all your fcurve cycles or linear extrapolation if exist. So there is no big need for further tweaks but I don't mind about it. So I would edit and close it if you accept.

In #76472#1117543, @StanislavOvcharov wrote:
Well it looks logical enough for me to place it here..

Ok, so it's a personal choice. That's fine, but it's better when it's actually been discussed & decided upon by more people in the module. The placement of the option also has implications as to where the option is stored, and how global it is.

An alternative would be to have this as a user preference. That has an impact on how teams of animators look at each others' files.

In #76472#1117488, @dr.sybren wrote:
When the design work is finished, and implementation can start, either one of these two should happen:

  1. Close the design task as resolved (because the design work is done) and create a new TODO task for keeping track of the implementation, or
  2. Re-classify this task as TODO task.

I think the 2nd option is the most suitable here, as it's not a huge amount of work that needs a separate task for tracking it.

I would choose the option 1 because it is ready for master.

Not if there are still questions about the design.

And I would leave it even as it is.

I don't understand. Option 1 is "close this design task, create a new TODO task for the actual implementation". You can't leave this task as it is AND close it and create a new one.

> In #76472#1117543, @StanislavOvcharov wrote: > Well it looks logical enough for me to place it here.. Ok, so it's a personal choice. That's fine, but it's better when it's actually been discussed & decided upon by more people in the module. The placement of the option also has implications as to where the option is stored, and how global it is. An alternative would be to have this as a user preference. That has an impact on how teams of animators look at each others' files. >> In #76472#1117488, @dr.sybren wrote: >> When the design work is finished, and implementation can start, either one of these two should happen: >> 1. Close the design task as resolved (because the design work is done) and create a new TODO task for keeping track of the implementation, or >> 2. Re-classify this task as TODO task. >> >> I think the 2nd option is the most suitable here, as it's not a huge amount of work that needs a separate task for tracking it. >> > I would choose the option 1 because it is ready for master. Not if there are still questions about the design. > And I would leave it even as it is. I don't understand. Option 1 is "close this design task, create a new TODO task for the actual implementation". You can't leave this task as it is AND close it and create a new one.

I believe it should go in the view menu as it is an option that you'd often change, I'd rather it be off by default because just by having it off it improves readability in the graph editor and I'd turn it on just when I "NEED" to see the extrapolation which is how I normally do it in at work all the time, I only turn it on in rare occasions, because i need the graph editor to display as minimal and clear information as it can (its already a spaghetti mess, i don't want more stuff cluttering it)
Also this might mean a bit of a performance improvement by drawing less curves by default, but I dont know how true this las phrase is, i'm just speculating.

I believe it should go in the view menu as it is an option that you'd often change, I'd rather it be off by default because just by having it off it improves readability in the graph editor and I'd turn it on just when I "NEED" to see the extrapolation which is how I normally do it in at work all the time, I only turn it on in rare occasions, because i need the graph editor to display as minimal and clear information as it can (its already a spaghetti mess, i don't want more stuff cluttering it) Also this might mean a bit of a performance improvement by drawing less curves by default, but I dont know how true this las phrase is, i'm just speculating.

This issue was referenced by dcd7dacc4f

This issue was referenced by dcd7dacc4fd8d72f3388268959b1324f7aae95e4

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#76472
No description provided.