[Bf-funboard] FW: Blender new keymap progress

Danni Coy danni.coy at gmail.com
Thu Nov 22 03:58:24 CET 2012


Those are pretty sound reasons....
In the unigine editor (which I work mostly with) camera is looking mode by
default, by pressing f(focus) with an object selected you go into orbit
mode around the selected object. In focus mode A and D move you around
selected object (I guess similar to 4 and 6 on the keypad and W and S move
you closer and further from the object.)

My problems with flythrough mode are 1) The controls feel wrong. 2) you
can't use any tools while in this mode - 2 is by far the biggest problem
for me.

A possible alternative would be to build this functionality into the numpad
cluster but W,A,S,D would give an immediate familiarity for many new users.


On Thu, Nov 22, 2012 at 12:22 PM, Nathan Vegdahl <cessen at cessen.com> wrote:

> There are many reasons not to do this, but the biggest two are:
> 1. It takes up four hotkeys that would otherwise be used for tools
> 2. For wasd navigation to make sense, the mouse would also have to be
> switched to "looking" rather than "orbiting".
>
> Both of these are counter to the primary purpose of Blender, which is
> to be a 3d creation suite.
>
> I understand that this can be helpful in designing levels and other
> similar tasks, but for most 3d creation tasks (modeling, texturing,
> animating, etc.) pan/orbit/zoom is a much more useful behavior.
>
> However, Blender does have a "fly" mode (shift-f in blender's current
> keymap) which provides functionality similar to what you are
> requesting (though wasd behaves more as accelerators, which
> could/should be changed).
>
> In any case, I think accommodating game-like navigation is best
> handled in a mode similar to fly mode.
>
> --Nathan
>
>
> On Wed, Nov 21, 2012 at 6:06 PM, Danni Coy <danni.coy at gmail.com> wrote:
> > 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
> >>
> > _______________________________________________
> > 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
>


More information about the Bf-funboard mailing list