WIP: Fix #97049: Auto-keyframe Status Message Overlaps Navigation Gizmo #105565
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
Code Documentation
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105565
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "PhoenixFlame101/blender:97049-fix"
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?
Adjust the position of the Auto-keying status message so that it no
longer displays on top of the Navigation Gizmo.
In Preferences we can turn on the "Auto-Keyframing" "Warning". With that enabled we see a status message while transforming objects and bones while auto-keyframing is on. Unfortunately that status message overlaps awkwardly with the Navigation Gizmo at the top-right:
This re-opens this old diff - https://archive.blender.org/developer/D14614
Fixes #97049.
Partially fixed by moving the message to the left by a length equal to the length of the gizmo.
Alternate solutions: Remove the message entirely, and change the recording icon to red when auto-keying is turned on. (#105574)
TODO:
USER_MINI_AXIS_TYPE_MINIMAL
gizmo.To reiterate what was mentioned in the older diff,
I mainly need help figuring out why the values of
printable_size
are changing with the gizmo size.@harley (tagging because you were involved in the conversation in the older diff)
c5d58cdd6a
toda0b07dd07
da0b07dd07
todb532b4b09
db532b4b09
toeef2ee0a71
Hi!
I've sent a quick note to the Animation Module in case they want that warning changed, moved elsewhere, etc.
As for the complications in this PR I haven't looked at it much, but would guess that the differences in
printable_size
you are seeing is that a font size is not explicitly set when the string is measured. So the size of the default font will be whatever it is when that function is called, but when it is drawn withBLF_draw_default
later it is using a specific size.If you follow
BLF_default
to see what it is doing you will see thatBLF_draw_default
is setting a size. But you will also see aBLF_set_default
in between them that I think you can just swap forBLF_default
as they are the same but it also sets that same size.In case the above is unclear I mean changing this line, along with an other changes you want to make:
Note that some of this bad overlap will be reduced as that warning is raised, not just as it is moved left. Just because that gizmo is round so it might tuck in nicely into its top-left corner at bit.
@PhoenixFlame101 thanks for revitalizing the old diff!
Could you update the PR description so that it follows the ingredients of a pull request? That way it's easier for others to jump in. Unfortunately it's not yet possible to embed videos here, but you can attach them.
WIP: Fix #97049: Auto-keyframing warning message shows on top of navigatorto WIP: Fix #97049: Auto-keyframe Status Message Overlaps Navigation Gizmo@PhoenixFlame101 - If you need further help or advice, don't hesitate to ask.
eef2ee0a71
to5c822f77f4
Sorry about the delay, I was busy with some other stuff.
Simply changing the
font_id
toBLF_set_default()
fromBLF_default()
seems to fix the issue!I have updated the commit to reflect this (as well as using a switch case instead of the if statements).
The fix is still somewhat broken for
USER_MINI_AXIS_TYPE_MINIMAL
, I couldn't find the size of this axis in code. Not sure how many people actually use this one, but it's worth mentioning nonetheless.No worries! I was just worried that you were stuck.
Awesome!
Fairly certain that is
U.rvisize * U.pixelsize
, drawn indraw_view_axis
inblender\source\blender\editors\space_view3d\view3d_draw.cc
. If not, let me know and I can dig a bit deeper.Weirdly enough,
U.pixelsize
seems to be 0 for me.U.rvisize
works though!It's a little too exact though, should I add an extra offset on top of the rvisize?
Unless I need more coffee that
U.pixelsize
should never be less than 1.0f. And if it were zero then thatdraw_view_axis
would break. Is it possible that the code you are in is called often and early in that you can just not do work if that value is zero? I mean if that value is zero it would be before the userdef was even populated inWM_window_set_dpi
and all sorts would be odd in there.FYI, We have a few things that change with the UI scale.
U.pixelsize is best thought of as our "minimum feature size" and indicates the how many pixels wide to draw lines. The best way to see the effect of that is to be showing the mini axis then go to Edit / Preferences / Interface / "Line Width" and change to "Thick". You will see many lines get twice as wide, including those of the mini-axis which obviously changes its size.
UI_SCALE_FAC is more directly related to the user's resolution scale (and DPI scaling of each monitor). Best thought of as our final multiplier for more UI items.
U.widget_unit is UI-sized value that combines a bit of both of the above and can be useful for setting some sizes. Basically the size of a single square button in the UI, so it gets larger with the resolution scale, but also gets a bit bigger with "wide lines".
Yes, you should be able to multiply some factor, like 1.2f or something, to that
U.rvisize * U.pixelsize
and your text should stay a consistant distance away. But just make sure to check changing both the resolution scale and the "line width".I did
U.rvisize * 1.2f
, and it works! Still don't know what to do with the U.pixelsize though, since it's 0 and multiplying it would mean the product becomes 0.No worries, will apply your patch and take a look at that in the morning.
I'm sorry, I completely forgot to post a comment here. This PR was discussed in an Animation & Rigging module meeting. The consensus was that having the message ("Auto Keying on") overlapping the 3D Viewport is distracting.
@PhoenixFlame101 could you adjust the patch so that the message is drawn next to the 'numbers' in the header? Something like this:
Alternatively it could be drawn more to the left, so that it is closer to the numerical values. It will be a challenge to avoid it jumping left & right when the numbers change, which is why I put it on the right-hand side in my mockup.
After doing some research, I found this code responsible for writing the text on the left side of the header while grabbing, rotating etc. :
headerRotation()
and similarlyheaderTranslation()
andheaderResize()
.These use the
BLI_snprintf()
function to write the text (to a buffer?), but I am unable to understand where the buffer is flushed and the text is written. Modifying these functions displays the code, but trying to make my own call toBLI_snprintf()
doesn't.Any guidance on this?
My guess here is that you examined what changes when a user selects "wide lines" and were actually looking at U.ui_line_width, which is zero for normal lines. This can't really be used in our calculations, instead we use that and other settings to calculate something usable: U.pixelsize. I've got some of that written down here: https://wiki.blender.org/wiki/Source/Interface/Preferences_and_Defaults
When I look at that section of code one thing to note is that I think the simple axes changes size and position with wide lines while the regular gizmo does not. So I get a result that seems to work in various settings (although not tested exhaustively) like this:
I think what you are looking for is
ED_area_status_text
. If you search for uses of that you will see you just call it with any text and it shows up in that area. Called with NULL it is cleared.@PhoenixFlame101 Is the WIP status of this pull request still relevant? If you want someone to re-review your patch, please remove the WIP prefix.
The code works and is mergeable, but it doesn't do what you outlined here.
I tried using
ED_area_status_text
, but it simply replaced the original text that displayed position, rotation etc. In your mockup you displayed the message on the right, which requires a custom function I believe. I still haven't gotten that working so I kept the WIP prefix.👍 that's all fine then, thanks for the update!
Landed in #111356
Pull request closed