A very common convention from other 3d packages would be to move the current frame number field which is way over there on the right (and has < > buttons that you can use for next/prev frame, it’s just not intuitive the way the rest of the transport controls are) and put it between the play buttons (without its own < > buttons) so that the current frame number that the transport controls are affecting is right there.
at the moment as it is, it creates confusion …
if we are in vertex select and click on the edge slide tool, it does not work, and vice versa for edge select and vertex slide does not work
it makes no sense that it is split into two tools.
if we are in edge mode, it should work for the edges …
if we are in vertex mode, it should work for the vertices …
that’s all.
That would probably be easy to do but not so elegant. You don’t always have the sidebar open - I think it should be right there in the header next to the ID selector.
I have always pressed esc to cancel the function …
it’s also true that if you cut out a fairly complex shape, it’s a nice headache to reset everything for a wrong vertex …
This makes sense to me. @jendrzych What do you say? The keyframe doesn’t have to have a color obviously, but this would clarify the fact that it jumps to the next key.
Just put an alpha transparent ‘outline’ in middle of the arrow and the key and it’ll be a real winner, IMO. Currently they melt together into a single shape.
Right Clicking and Joining Mesh is very easy, but once joined it is a lot more tricky to separate them again.Can we add separate too right click please.
This would be hard since Linux doesn’t have a standard GUI. It might involve looking up the window manager at use in the current display, and I’m not very sure there’s a standard way of gathering this information reliably. Also supporting each available WM conventions, and keeping up with them, seems like too much work for not so much return. Supporting just the mainstream ones (say gnome/KDE) might not be fair enough. Showing the standard OS/WM dialogs breaks the whole theme feel.
I do like the idea. Everybody likes a standardized workflow and a popup with buttons in the wrong order than usual can screw things if one is fast enough to click. I just personally think accommodating to the OS/WM ways and maintaining might involve too much work not worth the return, and showing standard dialogs is ugly.
I think Blender interface is already specialized enough that users may expect dialogs not to fit their OS/WM way.
(repost because it was accidentally posted as a reply to an unrelated comment)
When animating in stepped and using autokey animators often scrub with the mouse to quickly look at poses. In order to actually change a pose, they need to be directly on it otherwise a new frame is created.
Could we get a button that enables Snap-scrubbing?
I wrote a little python script, it should be fairly easy to implement. It only needs to be connected to a button. It detects if you’re moving to higher or lower numbers and according to that snaps next or previous.
bl_info = {
"name": "ScrubSnapper",
"author": "Karlo Pavicic Ravlic",
"version": (1, 0),
"blender": (2, 80, 0),
"location": "View3D> N > Handy Anim Tools",
"description": "Snap frame to nearest keyframe in drag direction",
}
import bpy
from bpy.utils import register_class, unregister_class
from bpy.props import BoolProperty, EnumProperty
from bpy.types import Panel, Menu
from rna_prop_ui import PropertyPanel
CurrentFrame = 0
def frame_handler(scene):
global CurrentFrame
if not scene.asset_manager.snapscrub:
return
if CurrentFrame > scene.frame_current:
bpy.ops.screen.keyframe_jump(next=False)
if CurrentFrame < scene.frame_current:
bpy.ops.screen.keyframe_jump(next=False)
if CurrentFrame == 0:
CurrentFrame = scene.frame_current
CurrentFrame = scene.frame_current
#Booleas
class PropertyGroup(bpy.types.PropertyGroup):
snapscrub: bpy.props.BoolProperty(
name='SnapScrub',
description='Snap to frames while scrubbing on the timeline')
# Draw the control panel
class HATOOLS_PT_ButtonPanel(bpy.types.Panel):
"""Panel Creation"""
bl_label = "Handy Anim Tools"
bl_idname = "object.hatoolss_pt_handytoolspanel"
bl_space_type = 'DOPESHEET_EDITOR'
bl_region_type = 'UI'
bl_category = "Handy Anim Tools"
def draw(self, context):
layout = self.layout
view = context.space_data
scene = context.scene
wm = context.window_manager
manager = context.scene.asset_manager
activeArmature = bpy.context.active_object
# Display menu if armature belongs to MSW
row = layout.row()
row.prop(manager, "snapscrub", text="SnapScrub", toggle=True)
classes = (
HATOOLS_PT_ButtonPanel,
PropertyGroup,
)
register, unregister = bpy.utils.register_classes_factory(classes)
#Register booleans
def register():
for i in classes:
register_class(i)
# storing property in scene for this example
bpy.types.Scene.asset_manager = bpy.props.PointerProperty(type=PropertyGroup)
def unregister():
for i in classes:
unregister_class(i)
if __name__ == "__main__":
register()
try:
bpy.app.handlers.frame_change_pre.remove(frame_handler)
except:
pass
bpy.app.handlers.frame_change_pre.clear()
bpy.app.handlers.frame_change_pre.append(frame_handler)
That’s probably not just a UI papercut, but I second the idea. Mad props for writing it yourself. I proposed a little something on the same topic a while ago : https://blender.community/c/rightclickselect/P0bbbc/