[Bf-funboard] FW: Blender new keymap progress

[Danni Coy]

I work between blender and external game engines. I would like to see the
W,A,S,D cluster work for navigating around scenes as you would expect from
most games (it's more or less a standard now).
perhaps move,rotate,scale could be moved to E,R,T.


On Thu, Nov 22, 2012 at 11:30 AM, Nathan Vegdahl <cessen at cessen.com> wrote:

> > > Good point.  I'll figure out a way to put that in.  I'm thinking that
> > > RMB-drag would be good for that.
> >
> >
> > please don't do this to such an integral use heavy tool (for me at least)
> > The nature of tweak+drag is that if it's your main modeling tool (without
> > resorting to G all the time) you tend to use it A LOT.
>
> I must be misunderstanding something.  Isn't RMB-drag already the
> tweak tool in the current Blender keymap?  So if it works for you now
> in the current keymap, why not in the new keymap?
>
> > Besides that ,unless you plan to change the shorcut for placing the
> > cursor (RMB) then EACH time you tweak+drag you replace the
> > cursor. Hardly ideal for visual an practical purposes.
>
> I may indeed change the key/mouse combo for placing the 3d cursor, but
> that's not necessary.  RMB-drag doesn't trigger RMB-click, so tweaking
> would not move the 3d cursor.
>
> > Again you assume that everyone works as you do. It is better to enable
> > different ways of working. I did not know about space+number though,
> > I'll try that out first.
>
> My apologies if I have been presumptuous.  But on this point
> particularly I was speaking from experience doing very
> mode-switching-heavy tasks in Blender.  Believe me, I think mode
> switching needs to be efficient.
>
> Space-># is the same number of key strokes as ctrl-tab, and the hand
> position is even more ergonomic.  If ctrl-tab is acceptable for mode
> switching, then space-># ought to be as well.  Admittedly, though, the
> fact that you can hit a number to choose a menu item is not very
> discoverable right now, which should be addressed.  But that's outside
> the scope of this keymap project.
>
> [Regarding viewport shading: ]
> > Another way is a 'button'+ # ,perhaps? If you do plan on promoting
> > the space+ number (and along with vertex choices) making more
> > use of that paradigm might make sense.
>
> That's a very good idea.  The other advantage to that is that such
> keys can be promoted to (optional) pie menus as well, if/when we get
> those. :-)
>
> The trick is that if we do that for a frequently used function such as
> changing viewport shading, the key should probably be near the thumb.
> So perhaps V would indeed be a good choice for that.  We'll need to
> experiment.
>
> > well mnemonics aren't really a big need anymore ,if you're ditching
> > G,S and R (amongst others...) It's nice to have when most of them
> > work like that ,but if only a few do,it doesn't matter so much anymore.
>
> I'm actually trying to use mnemonics whenever I reasonably can.  My
> rationale for ditching gsr is that translate, rotate, and scale are so
> basic that they're on the level of basic selection and viewport
> navigation.  The purpose of mnemonics is to make it easier to remember
> hotkeys, but translate/rotate/scale are so basic and used so
> frequently throughout all of Blender that even new users are
> essentially forced to commit them to muscle-memory early on (just like
> basic selection and viewport navigation).  So it seemed best to place
> them as ergonomically as possible instead of worrying about mnemonics.
>
> But for other things, I plan to stick to mnemonics whenever reasonable
> and possible.  Essentially, I'm doing my best to balance ergonomics
> and speed-of-use with learnability and logical layout.  We're not
> going to get 100% of either, but 80% of both is better than 100% of
> one and 0% of the other.
>
> > As long as Tools and properties get some logical button placement
> > I don't really mind.
>
> I was considering [ and ].  Or maybe ; and '.  And really, any two
> symbol keys next to each other.  Then they can be used for side panels
> throughout all of the editors.  (N doesn't make sense in the first
> place, and T only makes sense in some of the editors.)
>
> > thanks for reading and considering some of my ideas.
>
> Thank you for providing them!  Of course, I can't please everyone with
> everything, but getting feedback from people with different workflows
> and preferences is really important to making this keymap good.
>
> --Nathan
>
>
> On Wed, Nov 21, 2012 at 11:55 AM, Bol Bib <bollebib at hotmail.com> wrote:
> >
> >
> >
> >
> >
> >
> > > > where is tweak+drag?
> > > > Just selecting and dragging points without needing to to press a
> > > > shortcut to grab is a must. I use it 85% of the time,really.
> > >
> > > Good point.  I'll figure out a way to put that in.  I'm thinking that
> > > RMB-drag would be good for that.
> >
> >
> > please don't do this to such an integral use heavy tool (for me at least)
> > The nature of tweak+drag is that if it's your main modeling tool
> (without resorting to G all the time) you tend to use it A LOT.
> >
> > Besides that ,unless you plan to change the shorcut for placing the
> cursor (RMB) then EACH time you tweak+drag you replace the cursor. Hardly
> ideal for visual an practical purposes.
> >
> > I can get used to a lot but as a left button user I cannot see that
> being a plus.
> >
> > > I appreciate the idea, but I think it would not work out well in
> > > practice.  Many people alternate rapidly between several selection
> > > tools in their workflow, and having to switch via a menu (even one
> > > brought up by a hotkey) is too slow for such things, I think, and
> > > forces them to keep in their head what selection mode they have
> > > active.
> >
> > the problem is also trying to guess what other people use most ofcourse.
> > In my opinion the proposed idea could work if treated properly and would
> be preferable to removing options to select. But I'm not gung ho about it.
> Just that the current choices leave some things out.
> >
> > I don't care for box or circle select much but I wouldn't want to
> deprive anyone from having it.
> >
> > I guess I can always change LMB+drag to tweak select (if it's
> available),so it's not that bad ofc. But leaving stuff out is hardly ideal.
> >
> >
> >
> > and circle tool is bad just because it's modal (imo). I would prefer it
> as a selection tool that when it's active (just as an example:
> alt-lmb-drag) you can just resize it on the fly (with mousewheel) When
> using circle selection you can't do anything else which makes it annoying.
> If that would change it would improve as a tool.
> >
> >
> > > I understand that mode switching is a little slower with the new
> > > keymap.  However, mode switching is not done so frequently that this
> > > is a significant slow-down to workflow (and I say this as a rigger,
> > > which may well be among the most mode-switching-heavy tasks in
> > > Blender).
> >
> >
> > Again you assume that everyone works as you do. It is better to enable
> different ways of working. I did not know about space+number though,I'll
> try that out first.
> >
> >
> > > Hmm... I'll have to think about this.  This is another one of those
> > > cases where a toggle approach just may not make sense anymore.  You
> > > may never use wireframe, but wireframe and solid are nearly the only
> > > shading modes I ever use (aside from render with Cycles).  My strong
> > > suspicion is that a lot of people will have their own "most commonly
> > > used" shading modes, depending on the sorts of tasks they do.  So
> > > there may be no good way to handle this with toggle shortcuts.
> >
> > that's why I propose having it on a button only for the viewport, this
> opens up 4 ways to change it,at least. I am glad you are willing to
> consider it. Doesn't really need to be v,as long ast it's not z anymore and
> has it's own button.
> >
> > Another way is a 'button'+ # ,perhaps? If you do plan on promoting the
> space+ number (and along with vertex choices) making more use of that
> paradigm might make sense.
> >
> >
> >
> > > Excellent point.  However, U could also be a good candidate (U for
> > > "undo").  But it is good to keep related things on single hotkeys, so
> > > perhaps z would indeed be better.
> >
> > well mnemonics aren't really a big need anymore ,if you're ditching G,S
> and R (amongst others...) It's nice to have when most of them work like
> that ,but if only a few do,it doesn't matter so much anymore.
> >
> >
> > > > loopcut can still be CTRL+R
> > >
> > > I don't think that's a good idea.  Loop cut is a really primary
> > > modeling tool at this point, and it needs to be on a non-modifier
> > > hotkey.  Besides which, ctrl-r is a bit awkward to reach one-handed in
> > > my experience, and could cause hand-strain in the long-term.
> >
> > I don't think it was akward,but I'm not about to impose my experience on
> someone else's ^^
> > So sure. As long as Tools and properties get some logical button
> placement I don't really mind.
> >
> >
> >
> >
> > thanks for reading and considering some of my ideas.
> >
> >
> >
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-funboard
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard
>