I have made a internal script that allows navigation of 3DView, UVEditor, NodeEditor and VideoEditor while moving, scaling or rotating an object: D2624
The idea for resolving the key conflicts for constraining axis and proportional edit was to change the keymap of constraing axis and proportional edit by adding Alt.
That is, to increase the proportional edit circle you must hold the Alt first and then scroll the mouse button.
Good to see how you solve this issue.
About current blender state, just my opinion, but the middle button navigation should be consistent.
Pressing middle button should remain on navigation during operations, and alt+middle button should be on change axis.
Or another proposal, a combination of two mouse buttons for differents operations/changes of axis.
If I recall correctly, this cannot be solved through keymaps. For this to work, modal operators have to pass through the key events, every single modal operator would have to support this explicitly.
My guess as to why this hasnât happened yet is that maybe developers are waiting for a more elegant and consistent solution for this problem. Itâs probably under consideration for 2.8, etc.
This operator would have more key conflicts than the transform. Complicated :\
Yes, these commands only work while the transform is acting.
This is exactly how it works with the patch
Changing the keymaps was not the final solution. Returning the passthrough when you want to navigate was the solution. You can check the code here: D2624
(Another solution for navigation would be to call the Zoom, Orbit, and Pan operators inside the modal)
The keymap thing could be an issue with stuff like this (and reading this, Iâm not sure if changing the keymap is sufficient).
In my opinion, there could be a couple ways of resolving this.
Limit the transform mode during a selection operation to rotating with the middle mouse button (that way, it can work for box select, circle select, and generally any select tool). This could even work with modeling tools such as knife and features like grease pencil.
Implement a slow-motion catch-up mode for the viewport, node editor, and other window types when an object starts to go near the edge of the screen or outside of the screen (how fast depends on the speed the object is being transformed). The whole thing could also potentially apply to box and circle selecting on large-scale meshes. Optionally, there could also be automatic rotation based on the average of the normals of the faces near and under the mouse cursor (corrected for the view rotation). This could also kick in if the object gets to a certain distance away from the viewer in perspective mode.
Something to think about, minimizing the needed changes of the keymap, in my view, would increase the chance of such a patch being accepted.
GREAT to see this issue finally tackled, mano-wii! I am sure that you and the developers will find the right solution for the (also brilliant) axis constraint.
Looks very promising feature could this be possible to work with âcâ circle select tool that currently doesnât allow rotation/moving while making selection, but in the another end knife tool allow which is like a slap on the users face.
I tried the version of Dropbox, and when it stops moving the camera the object jumps from position. In my opinion it does not just work as it should, objects should stay in the same place once the camera movement is finished, but itâs still useful.
Itâs something I still miss a lot from modeling in Wings3D when going to Blender. (Made that move when itâd save time from switching back and forth, and Blender tended to handle more polygons better.) If implemented correctly itâs super useful. Extruding something out and it goes out of view? Well move your view (almost on the fly), then go back to the action to get that extrusion to line up or whatever. Might have to rework space navigation to a âstickyâ middle mouse navigation like Wings3D though (Mirai mode there is still the best imo), but I think people could deal with it.
For most of the middle mouse button issues with commands, Iâd suggest using middle mouse button + modifiers to take up that slack. Mid for navigation, mid + CTRL or Alt, etc. for doing stuff.
In Blender you have to sometimes think ahead where youâre viewing something from before you do something or just end up repeating actions to get something in position, so it does slow down workflow at times.
If I understand correctly this will allow to move an object without the need to drop somewhere in between just because I canât see from the beginning into the 3D viewport the target location? If so will be great!
Whatâs the status on this? It doesnât seem to be resolved in 2.8. Is there a patch or something I could install (alsoâŚer, how do you install a patch?).
Thank you. Do you happen to know of a relatively-straightforward guide to applying a patch for the naive individual? I searched briefly and it all seemed to assume a familiarity with coding that I donât have (maybe thatâs unavoidable).
