Anim: View FCurve of Property in the Graph Editor #114407
No reviewers
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#114407
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "ChrisLend/blender:focus_in_ge"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR is inspired by a tool that the animators from Goo studios showed me at the Blender Conference 23
Description
This PR adds a new operator that allows to frame an FCurve in the Graph Editor from the animated property.
Features
Caveats
Demo
@blender-bot package
Package build started. Download here when ready.
WIP: Anim: View Property FCurve in the Graph Editorto WIP: Anim: Frame FCurve of Property in the Graph Editorhi, @ChrisLend nice waited feature ,I'll be direct 👍
suggestion one : add quick shortcut like" hover on it+Ctlr+LClick" for quick reaction.
suggestion two: if graph editor is not opened in actual workspace:
1- display a pup up graph editor if it is not opened in actual workspace
2- switch any existing editor type in the bottom
3- switch any existing animations editor type to graph editor
4- switch to a specific workspace dedicated to animation named "Animation" by default, can be changed in preference..
@hamza-el-barmaki
I didn't add a hotkey on purpose since that would clutter the global keymap. I expect the user to do that if needed.
I'll talk to the UI module about the popup. I think it violates Blenders design principles of a non overlapping GUI. That said it is being done for the render window...
I'd like to avoid switching the workspace. That feels too extreme and unpredictable
This is awesome! A few of our findings after talking to our animators about it:
Our current tool hides the rest of the curves once the operator is run. Could we add that as well? Or perhaps a preference setting to add that functionality. Right now we have to run the
Show in the Graph editor
operator, then hit the Shift H hotkey to filter out the curves we want and hide everything else.Caveat for above point. Ideally once we figure out the system that prevents keys from being hidden in other workspaces when hiding curves in the graph editor, we would favour that instead of the Shift H workflow instead,
Assuming if the graph editor is not open. If we do a workspace switch once using the operator, it should only switch the dopesheet/action editor to the graph and not the timeline. But we are okay with it not switching workspaces.
Thanks a bunch!
To add to @Raymond-Luc 's above comment, here's the goo engine code for reference. It's very naive and a little "dumb" especially in finding an active fcurve editor, i think a tidier solution would suit main blender better (ours tailored to the way most of our animators work)
1574a31c15
Also, our implementation is more like a python macro translated to C code - it's calling operators and all other kinds of nonsense (it was originally written in python using some pointer offsets to get the right-clicked property, which isn't accessible from the py API. Maybe a better solution wouldn've been to just expose that value instead...)
Even if not ideal either I could imagine it working like the
Edit Source
operator (so there would be some kind of consistency)?It simply spits out this info banner to the status bar if no Text Editor is open at the time of execution:
thanks for the link to your implementation, I didn't know that was written in C. My way of finding the Graph Editor is mostly the same. Not sure what a smart way would look like, I feel like iterating through the areas is the best one can do.
@Raymond-Luc
About hiding FCurves. I need to think about this. I see a use case where people do not want to have their other curves hidden.
For the second point, I am not quite sure I understand. Where else are curves hidden apart from the Graph Editor?
@lichtwerk
Yeah that's not a bad idea, I'll need to check the code for that operator because I am not sure how to set things in an editor that isn't currently open
I also have python operator for this, and I also hide F-curves. Because reality is most of the time I need this feature is when I'm not in Animation workspace and quickly need to inspect some f-curve and make slight adjustments. When I inspect F-curve, I want to see that one only.
But most important for me is that if there is no Graph Editor in the workspace, it creates a pop-up window with Graph Editor. I know Blender doesn't like Pop-up editors, but it's the best way to quickly tweak animation without having to dive fully in Animation workspace when you just want slightest adjustment.
Ah what I meant is the behaviour when if you hide a curve in the graph editor, the keys for that curve are also hidden in the dopesheet/action editor and timeline as well. I don't quite remember if it was in a BCON talk or an offline chat with Sybren, but I recall hearing that a new system was being drafted to address this (or I may be completely wrong)
WIP: Anim: Frame FCurve of Property in the Graph Editorto WIP: Anim: View FCurve of Property in the Graph Editor@blender-bot package
Package build started. Download here when ready.
@Raymond-Luc @Nika-Kutsniashvili
Ignore that comment, was changed right after to be a modifier key. Now pressing
Alt
while clicking isolates the curvesWIP: Anim: View FCurve of Property in the Graph Editorto Anim: View FCurve of Property in the Graph Editor@blender-bot package
Package build started. Download here when ready.
Added a property to the operator
isolate
When that is true, all other F-Curves other than the framed are hidden
This can be triggered by pressing
ALT
and clicking the menu entryThis was done after a discussion in the Animation&Rigging module meeting, where it was decided that this is the best way to implement this.
Over-all the code looks good to me. Just some nits, and a suggested refactor of one of the functions.
I haven't tested it yet, however. I'll do that tomorrow.
@ -4271,0 +4303,4 @@
return found_graph_editor;
}
static void deselect_all_fcurves(bAnimContext *ac, const bool isolate)
Nit: out-of-context I don't think
isolate
is very descriptive for the second argument. It's not actually isolating something, rather it's hiding everything. So maybe justhide
?@ -4271,0 +4328,4 @@
char *id_to_prop_path,
const int index,
const bool whole_array,
rctf *r_bounds)
Since
rctf
is a fairly small plain-old-data struct, I think it would be clearer to simply return it rather than using an output parameter. And then the callee can union it with anotherrctf
if desired, rather than that being an implicit part of this function.@ -4271,0 +4383,4 @@
MEM_freeN(path);
for (FCurve *fcurve : fcurves) {
fcurve->flag |= (FCURVE_SELECTED | FCURVE_VISIBLE);
The name of this function led me to believe that it was side-effect free, but in fact it's unhiding the fcurves as well. So I'm wondering if it makes sense to split this out into functions that serve as clearer vocabulary. For example:
Vector
of them.And then you can call them individually. In fact, 3 is probably short enough to just inline rather than making a function for it.
I am not sure I can do that.
To do the NLA mapping, I need the
AnimData
structto get that, I need the
ID
If I split the functions to handle a vector of
FCurve *
I no longer know which ID each FCurve belongs to.I could make a struct that encapsulates the
FCurve *
with theAnimData
and make a Vector of that.Or rename the function to something more appropriate.
Let me know what you think
Ah, that's a good point. Yeah, splitting this up could be tricky.
The functional programmer in me wants to split out the idea of filtering fcurves (i.e. finding the fcurves that satisfy a given criteria) from doing things with those fcurves (e.g. computing their total bounds, or unhiding them, etc.). But that would need to be part of a larger refactor of how a larger chunk of the animation code works, I think, and certainly doesn't belong in this PR even if we want to do it.
So yeah, for now let's just change the name.
calculate_selection_fcurve_bounds_and_unhide
is fine, I think. It's awkward, but I think that awkwardness is reflective of the multiple things the function is doing. And it's at least descriptive, so people won't accidentally reuse it thinking that all it does is compute bounds.good idea done that
at some point refactoring all the animation functions to check if they actually need
AnimData
would be good.I am pretty sure we can simplify a lot of these functions
@nathanvegdahl I implemented the changes, except for splitting the function which I am not sure how to best do.
Some notes from testing:
@Nika-Kutsniashvili
There actually is some precedence for this: in the right-click menu on a property, there's "Open Drivers Editor" which opens the full graph-editor-like drivers editor in a separate window. I don't know if that actually passes Blender's recent UI standards (maybe it's grandfathered in or something). But it's at least not unheard of.
@nathanvegdahl changed the error message when nothing is selected to actually say "Nothing selected"
Also I realized that framing the fcurve of a shader node no longer worked, so I fixed that.
About which Graph Editor to choose when multiple are open. I am not sure picking the biggest one feels any less random. The only sensible way I could think of is to have an "active" graph editor. But that in itself complicates the matter a lot more
maybe picking 'the last graphe editor used' or 'the last created area that use graphe editor' ?
Any method to choose Graph Editor in a smart way will require a lot of work and computation and will always feel random no matter what. I say just open it in every graph editor. Or just create pop-up in any case and not change graph editors in the workspace at all.
@ChrisLend In retrospect, I don't think changing the graph editor choosing behavior is worth it. Certainly not in this PR, at least. If it's worth changing, we can revisit that in a future PR.
@nathanvegdahl I had to modify the logic of how the
Alt
key press is detected.As @Raymond-Luc pointed out to me, making a hotkey in the keymap that has "isolate" on true was not possible
because the
invoke
function was overriding that property. I had to make another property "use_modifier_key" thatspecifies if the
Alt
key check is performed.Though I am not sure that's the best way to do it. Feels a bit hacky
@blender-bot package
Package build started. Download here when ready.
The code looks good to me. Although maybe taking some time to add documentation comments at the top of the longer new functions.
Hmm. I think this is getting a bit outside of my wheelhouse. I'm also wondering now: is there any precedence for using modifiers to change the behavior of menu items elsewhere in Blender? Maybe we should run that by the UI module. @pablovazquez , could you weigh in on this?
To get this landed sooner rather than later, I think it might make sense to just rip out the alt-modifier stuff for now. Then we can add that back in a future PR after running it by the relevant people.
Good idea. With the operator property in place, this functionality can be added via the keymap if a users wants that
Looks good to me!
Something else we might want to add in the future are an option for only selecting the curves without framing, and options for framing vertically vs horizontally. But I think it makes sense to hold off on those until we get actual requests or use cases.
I'm bit late, but Graph Editor icon next to operator in UI would be helpful
if there are lots of keyframes on one parameter, it would be a boon if there was a way to focus on only the one keyfame in the graph editor when the parameter is showing highlighted in yellow color.
Thanks for the feedback.
In the case of having a lot of keyframes on a curve you can enable the preview range and it will only zoom into that range.
But I could maybe add an option to the operator to not change the x-range of the Graph Editor.
I wish governments had passionate people like you, the world would have been come together just like Blender
In testing this out with the latest builds, I'm not able to frame any animated material properties, node or otherwise (like Base Color or Viewport Display Color). This is also true of world settings (like Mist Pass Start) and scene settings (like Gravity or Audio Volume). They all just give the 'Nothing Selected' error. It's possible to select those things via the outliner I suppose but that doesn't make a difference. Not sure if all that was in scope for this patch so I wasn't sure if I should open a new issue about it or not.
Noticed issues with this PR.
The context is modified but not restored & there was a memory leak in the
selection
list (resolved7848533395
).Overriding the context without restoring it is could break event handling logic, although in this case it didn't seem to cause user visible errors, if you check existing uses of
CTX_wm_window_set
, the convention is to restore the previous window after setting. Unless they actually manipulate the windowing data (closing the window for e.g.).As far as I can see this isn't documented though, doc-strings in
source/blender/blenkernel/BKE_context.hh
should mention this,https://developer.blender.org/docs/features/core/context/ too.
@ideasman42 do I see this right in the commit that the memory leak occurred when the code exited early because it was unable to find the graph editor? Thanks for fixing that and the context move code.
@JonathanLampel-4 make sure you select the node before calling the operator. I'll mention that in the release notes to avoid any confusion. For the mist settings, indeed that seems to not work. I'll see if I can make a fix for that.