I took a look into adding the infinite line cutting mode last week and I found it was actually much harder to implement than I initially anticipated it would be due to how the knife tool is designed. I will have to postpone adding that for the moment and focus on my proposal timeline. I suspect I will have spare time near the end of the GSOC time period in which I may decide to revisit it when I a smaller TODO.
5 Likes
Hey,
Will there be an option of not seeing all the cuts you made, but only the one’s that are facing you?
In this example you can see all the cuts marked and it’s kinda confusing (hope that made sense).
1 Like
Please no modal keys that go beyond your t,g,b,y,h,n letters, we rest our right hands (most of us) on a mouse, and not everyone has gigantic palms, please keep most used hotkeys on or around the left home row hand position. No weird hotkeys like i [ ] ;’ ,… Thanks!
5 Likes
I love all the changes you make.
I have a minor request not even related to coding.
Could you please use screencast keys in your weekly report gifs? It would be helpful to see what you are pushing on the keyboard to evaluate the new behavior better.
Thank you, thank you and thank you 
3 Likes
Interesting point of view about hotkeys. Blender as a hole doesn’t avoid hotkeys on the right hand, and there is some value to using hotkeys that have a mnemonic value for memory (which is usually how I chose them, when I chose them).
What do other users think?
1 Like
I would agree with you Howard, but for the knife tool since you use the right hand to actually make the cuts you generally don’t want to remove the right hand from that operation, otherwise it feels intrusive. In that respect I don’t mind the hotkeys for the knife tool being a bit “quirky” if it keeps me from removing the hand doing the actual operation.
Actually I was secretly a bit disheartened when 2.8 removed 2.79s hotkeys for orbit control. You could use Ctrl+Alt and also Shift, all in some combination while using the scroll wheel on the mouse to control orbit. This meant you didn’t have to use the numpad keys to move the view, thus removing your right hand. They were a bit ridiculous in terms of the button combinations, and they were removed in 2.8 along with other nasty contenders like ctrl+alt+shift+C, but I do miss it being default.
Is there a difference, for Knife, between modal keys that are either rarely used or only used at the beginning of the use of the tool, vs keys that are often used throughout the use of the tool? What modal keys are used (or do you foresee using, with new ones) a lot and which rarely?
Well, I think currently in master all the hotkeys are all around the left hand. The only action that requires moving a hand is “enter” to confirm which is of course just fine. I’d say they all share decently even usage? Maybe the most used would be Z for cut through, and CTRL for midpoint snapping, but that’s just from my experience.
As for this I think it’s hard to tell without getting my hands on it. I was going to ask @HobbesOS when the project is at a point where you feel testing is viable if you could upload the branch to GraphicAll? That makes accessing it very easy for more people and we’d be glad to try to figure out if the hotkeys feel good or not.
personally, my entire custom keyconfig is based around the idea of ‘access comfort’, which translates into speed and efficiency for me. mnemonics are certainly useful- but I find that I can memorize just about any hotkey if I’m using it frequently enough. I also think that relying on mnemonics for hotkey assignment is a losing battle since eventually you run out of keys to map to sounds, which is why we end up with a semantic stretch like proportional editing being on the O key for the “o” sound and the separate popup being on the “p” key.
a more tenable solution is to have popup help/hud for complex modal keymaps similar to how HardOps handles it, but that’s more of a philosophical UI discussion for another time.
speaking specifically to the knife tool (and other modal operators like it), i personally think that removing your hand from the mouse should be a non-starter. modal operations like knife, extrude, bevel, inset, etc- are all ‘precision’ tools where the user needs to be in control of the mouse the whole time.
1 Like
“M” to show measurements does not comply with what you propose about the left side of the keyboard. “S” and “D” keys seem to be available, and this could be mnemonic if we associate it with “Show” or “Display” or even “Distance”.
But this is where I don’t think all the shortcuts should be very close together on the left side. Now that the “E” key cancels all the work done, it has become dangerous, that action should not be close to the other keyboard shortcuts since you could accidentally press it, and there is no Undo function to recover the work. I really don’t understand why this new function if we already have “Esc” key, I’m probably missing something?
PS: The above does not mean that I am unhappy with the change of RMB getting the old E functionality. I like that RMB now doesn’t cancel all work. I’m just saying that maybe we should just stick with Esc key as the only shortcut to cancel all work.
Mnemonics break down too quickly. The amount of ‘mnemonic space’ you have isn’t consistent from operator to operator, and there are a bunch of baked-in language and vernacular assumptions that don’t really work in practice.
The safest bet is usually row/column clustering. Mode-like shortcuts on one row/column, action-like shortcuts on another, least-frequent shortcuts on a third can work pretty well. There’s plenty of room within that to adapt to specific operators, but it makes it pretty easy to set up a pattern consistent enough to help people predict what keys do what.
1 Like
I thought it was an uwritten Blender law to having the hotkeys away from the rest position be much less frequently used. Pablo said in a recent Blender Today that this is why “X” as a shortcut has a confirmation panel and “Del” does not. X is easily reachable and may be hit by accident. When you reach for Del you usually do it consciously enough to know what you are doing.
Personally, I also dislike lifting my hand to reach. Especially if it’s so far that I have to look away from the monitor and at the keyboard. As much as I like G, R and S - it’s much easier to keep three fingers next to each other in W, E and R position. It’s also why I love the othographic mouse gesture shortcuts. No need to reach for the NumPad any more.
If it’s a specific tool that is not often used, then - sure. Frequency needs to be as optimized as possible, I think. Don’t know how this translates to left handed people actually using the mouse with the left hand, though.
I think there is only mnemonic value if the user is familiar enough with the english language to associate a specific word with a specific action. Even I forget the associations that were initially intended, though I speak english reasonably well. Plus, a proportion of them don’t even have this quality : C to constrain, sure, but Z to cut through ? if there’s no meaning to it we might as well pick a key that’s easy to reach.
Instead I would advocate for a fixed group of keys to be used in the context of every tool. The ones around the left hand side of the keyboard would be ideal since they don’t require stretching your hand too much, as others have said. The mnemonics would instead be “cross-tool”, if that makes sense : eg the E key, in the context of edge slide (and vertex slide), extends the edge virtually so that you can slide the component further. Well, E could be bound to “extend cut” in the knife tool (provided that’s indeed going to be added), which has a semantic relation with “extend edge”. In the bevel tool, E could toggle “clamp overlap” which as you know very well prevents the extension of the bevel further that the its boundary edges.
(Of course that wouldn’t work for every key, because not every tool has options that carry over to other tools, but we could try making this somewhat consistent with the few options that do have equivalents in other tools. The biggest advantage would come from the fact that it’s a fixed set of easy-to-reach keys.)
1 Like
I don’t know about you guys, but all my colleagues and very skilled 3d modellers that I know and respect, customize their hotkeys in every DCCs they work, so that their left arms stays on the left side of the keyboard most of the time. That is basically one of the things that gives you a speed advantage compared to people that use the software occasionally, and in my opinion it is better to teach users best practices straight away.
The whole philosophy could be described as follows: when drawing and painting an artist should be concentrated on composition, shape and shouldn’t be thinking about the key he would press and look down on a keyboard. It’s distracting as if like you’re changing the brush every time you need to make a single brush stroke. That’s why every skilled artist develops custom hotkey sets for the software they work in, because defaults are not always the best choice and many times they were chosen because the first letter in the name of the tool is the same. And sadly, Blender doesn’t avoid the right side by default, so a lot of things eventually have to be remapped to save time.
Also, the claim that left side of the keyboard runs out fast because you run out of keys is not fully valid, as you have combination of modal keys that you can use, giving you loads of variations, and also blender has separate modes where you can have different hotkeys.
As for Knife tool being binded by default to ‘K’ key - I don’t know about you, but I rebind it to double middle mouse tap on my mouse in edit mode, I don’t suggest you to do the same as it sounds quite unorthodox for many, but it saves me loads of hand movement and prevents distraction from the flow and doesn’t disrupt navigation at all. Same goes for some functions like select more/less in edit more instead of using ctrl + ctrl - (or whatever that is by default) and wasting time reaching out unreachable keys I remap it to shift+ middle mouse button up and down. I rebind a lot of stuff on the right side either to left side of the keyboard or my mouse with 20 buttons, this allows me not to ever look at keyboard and just be in the flow.
It might seem that it is a great idea to bind some function to a key because it has a similar name, it seems logical at first, but what you must think of is the “flow” here. A person using the tool you have programed will be using it for 8 hours, sometimes 12 hours during crunches, and these distractions when he tries to find a key on the right side of the keyboard will eventually add up and you’ll make his life harder, even if sometimes he won’t notice it at first.
Also please keep all new options available for customization in Knife Tool Modal Map section in hotkeys settings so that they could be customized too, there is nothing worse than hard-coded hotkeys in a software package. Just my 2 cents on the matter, you don’t have to do that, but yeah, at least make sure that we have an option to change it.
7 Likes
In regards to the large discussion on modal key mappings,
@YAFU I agree with your points about ‘E’ deleting the entire cut being dangerous, especially considering there is no way to retrieve your lost cut. I am happy to remove it in favour of just having escape do the same. I would also be happy to move ‘M’ to ‘D’ for showing measurements.
@Bobo_The_Imp I could certainly upload a build of the branch to GraphicAll. I will likely do this near the end of my project (early August) as that is when I will have all of the proposed features implemented to some degree and have had some time to fix any bugs I find myself.
@MeshVoid The Knife Tool Modal Map section in the hot key settings is automatically updated as I add more modal keys, so this is no problem.
I noticed a few people saying they used ‘Z’ for cut through a lot. How do you feel that I have moved it to ‘T’ as ‘Z’ is now for snapping along the ‘Z’ axis?
I will certainly put more consideration into choosing modal keys in the future after this discussion.
3 Likes
I tried it before, but the addon for blender seems to not pick up number keys while in the Knife Tool modal. At the time I just wanted to show off number key input so I removed it. I will try get an external software to display the keys or find an alternative solution for future gifs in the weekly reports. I realise this would have been especially useful in the last gif of the last weekly report.
1 Like
I also thought the same when I made that gif. I will take a look at adding a sort of X-ray toggle for the knife tool.
About mnemonic. Default keymap in Blender is “in English” mnemonic based. Of course this is not always the case, it would be impossible. But this is preferably so in default keymap. Remember that in Blender we have “Industry Compatible Keymap” and other keymaps to do it differently.
In this I have my doubts, more now that we can choose constraint to axes. Personally I could be fine with “T”. Or perhaps propose a bigger change: “A” to [A]ngle constraint and “C” to [C]ut through.
3 Likes
Those are good propositions as far as I’m concerned. The axies’ names can’t really be changed, so we can consider the keys occupied. A and C make sense to me.
1 Like
@YAFU @Hadriscus I agree, it keeps things altogether on the left side of the keyboard which is great. Check out the latest weekly report.
1 Like