- SpectralVectors changed review status to Awaiting Review
- 1 mo
Game Engine-style navigation for Blender's 3D Viewport (and optionally Node Editors).
Hold Right Mouse to enable 'Walk Navigation' and use the W, A, S, D, Q and E keys to navigate your scene.
Click Right Mouse to access the standard context menus.
A Time Threshold is available in the addon preferences, to adjust between a 'hold' and a 'click'.
The optional Node Editor mode binds panning to Right Mouse 'hold' and the Node Search/Context menus to 'click'. If a node is selected the standard Node Context menu will be called, if no nodes are selected, the Node Search menu will be called.
This addon supports both Left and Right Click Select, however, there is a known issue where the addon keymap is not updated after switching between Left and Right Click Select. The fix is to restart Blender, which should resolve all issues with the addon.
This extension does not require special permissions.
Code seems fine.
When the users key-map preference is set to RMB select this extension makes selection impossible.
It should probably either:
I think I'll just note the incompatibility for now, until someone requests RMB select support.
Is it enough to put a line at the top of the description:
Or does that need to go elsewhere? Thanks!
OK, I updated the addon to allow for selection: adding a check to the callMenu
function for the select_mouse
and calling view3d.select
instead of the menu if it is.
In testing I found it worked in both modes, however, I noticed that if you switch between Left and Right Click Select in a single session, not all keymaps are updated (I'm making my keymap changes in the register
function, but I imagine that select_mouse
has its own keymap callback that the addon doesn't respond to.)
I will clean up the documentation and note the issue.
Thanks!
Awaiting Review
Thank you for the submission but I do not think this meets the criteria of usability to be allowed there. Either I'm missing something, or only thing this one does is assign different shortcuts to things that are already in Blender and already have default shortcuts. Changing shortcuts is very easy and shouldn't require add-on for it.
Waiting time between navigation and menu is a nice feature, but not enough. You can generalize that feature into something more universally useful and submit as different add-on, for example: allow assigning secondary shortcuts to right-click, where click would be right-click menu, but hold and release would be whatever shortcut they assign. That way add-on won't be tied to just doing one thing.
You're only some good functionality. But in this form this is just not enough.
You're onto* some good functionality.
Changing shortcuts is very easy and shouldn't require add-on for it.
I agree, and I bet that this seems like something that should be able to be changed in the keymap alone, and I urge you to try to replicate the functionality of this addon by doing so (like I did).
The fact that it is not possible to do is what caused me to write this addon in the first place.
You can generalize that feature into something more universally useful and submit as different add-on
This is not a keymap editor, I have another addon for that, and if it were as simple as editing the keymap, the Preferences editor is more than capable of that.
But in this form this is just not enough.
The ONLY purpose of this addon is to allow Blender users to be able to navigate their scenes the same way Unreal, Godot, Unity etc users navigate theirs.
This is by far my most popular addon, and the most common feedback I receive is, 'Thanks so much for this, you're a lifesaver, I can't believe they haven't built this behavior into Blender!'
I agree that the scope of this addon is quite limited, but to say that it is possible through keymap editing without a custom Modal Operator is false.
I don't wish to dilute or bloat my addon with features that don't benefit me or my userbase, it's called RightMouseNavigation because it does what it says on the tin - lets you navigate with Right Mouse - like game engines and other 3D apps.
I have already made accommodations for Right Mouse Select users, even though I doubt any of my users use Right Mouse Select, to make it a more compatible addon.
It is not RightMouseMapping, as that would be easy enough to do through Preferences and the only point of this addon is to allow non-distruptive game-engine style navigation.
I feel like this is a bit like saying - Bool Tool only does one thing that already exists in Blender - in this form it is not enough, consider generalizing these features.
Maybe that's true, OR maybe it offers a newer or more convenient workflow that its author and users have come to depend on over time, and that's the entire reason it exists.
I don't need to replicate this actually, if you have Pie on Drag enabled in preferences and press key it takes you in walk mode and you can walk with WASD. That's what I've been using so far. In keymap editor you can change it from
to RMB if that's what you want. You can additionally just not enable that feature at all, and assign RMB to Walk mode in 3D Viewport > View menu.
Everything this add-on does is already implemented in Blender, except delay feature which is very nice, and why I wish it would be generalized more.
I'm glad that add-on is well received, and I can see that you get lot of love on github, that is great to hear. But for something to be allowed by default inside Blender for all of its users, we do have some minimum requirements I'm afraid.
I feel like this is a bit like saying - Bool Tool only does one thing that already exists in Blender - in this form it is not enough, consider generalizing these features.
Even though Bool Tool was combining like 10 clicks into one, that was indeed my reaction to it, and that's why I added 3k lines of code to make it general boolean add-on.
Markdown made assumptions in my comment. Key to enter walk mode by default is tilda "`"
Hmm, I still think this add-on has some value to be honest, a lot of people would be unable to replicate the game engine way of navigating by deault in Blender, without deeper knowledge of Blender and phyton.
I like that its just one click away instead of needing to setup all the stuff myself and learning phyton. And clearly a lot of other people like this as well!
To be honest the are a lot of honestly useless add-ons that add nothing thats not already in Blender, but I think the convenience and easy of use compered to setting this up manually makes it worth including, especially since the are a lot of people coming over from game engines to Blender, or Blender should included a deafult keymap that replicates game engine naviagation.
Also, walk navigation in Blender is not the same functionality as this in practice, even if they share similarities, when you need to work, and not just look around, this it way more convenient!
I don't need to replicate this actually
Yes, you do, otherwise you won't see that your suggestions don't work. I had all the same thoughts as you, and I can go through the reasons why they don't work:
Key to enter walk mode by default is tilda
Yes, it's not Right Mouse, like I want, so I'll just adjust the keymap to:
assign RMB to Walk mode in 3D Viewport > View
But now all of the context menus are broken, how can we fix this so that we can bind both context menus and retain navigation, by using a modal with a:
delay feature
Except I can't just call 'Context Menu' because they're different menus (or panels) for each applicable mode and I have to supply a unique name and those names are not consistent across modes, so I also make a list of all related modes, their menus or panels and add a check to ensure that the correct menu or panel is called. (In the optional Node Editor mode this also checks to see if there is an active node before calling either the Node Context or Node Search menu.)
And so, now it works, right?
Still no, because Windows doesn't always recognize a Right Mouse Up event, and so you get locked permanently into navigation unless you import Ctypes and manually call an extra Right Mouse Up event.
I asked you to try recreating the behavior of the addon with keymap editing because of all the complications listed above.
I don't have anything else to add on a technical level, the code is all there, I don't think there is anything wrong with an addon having a limited scope, it is why I have separate addons for CNC, multi-line text nodes, motion capture etc - there is no reason to add features that users don't want to an addon.
I would be happy to see this behavior implemented natively in Blender, and, if so, can see how a broader implementation would benefit users.
I can see how adapting this to an addon that could add this feature to any or every key in Blender could give some unique benefits, and you're welcome to do so, it is GPL and I've always encouraged people to fork and customize to fit their needs.
But, it is not a keymap manager, it is not a control remapper, it is simply 'Game Engine Navigation' - how you would expect it to work, with all of the kinks worked out by someone who tried for a long time to implement it using the things you suggested.
Please, PLEASE, actually try out some of the things you are suggesting and report back to me if they work. I made all the same assumptions as you about the keymap etc, and did not discover it was not possible until I actually took the time to try it myself.
I am extremely disappointed that this is the response to my efforts, I am equally disappointed by your unwillingness to try the things that you are suggesting, as well as your assumptions that I have not already tried them.
It is sounding like this might be the end of the road for this addon as an extension, and I'm at a loss as to which 'minimum requirements' I'm not meeting, all the documentation I read stated that the addon met the Extensions Guidelines and Addon Policies, where are the minimum functionality requirements listed?
Or is this simply a qualitative judgement call that the functionality that the addon provides is not good enough?
Ok I'm gonna consider this because I tried my way, and stumbled upon a problem that context menus are called by 'Click', instead of 'Press', even though they're specified as 'Press' in keymaps. I will be reporting that bug, but in the meantime, this feature deserves to exist. But only given some requirements are met.
if __name__ == "__package__":
is Incorrect. In this particular case it should still be __main__
.https://imgur.com/a/6NuvoNj
4. I do not know if sys.platform.startswith('win')
is safe, but I'll ask Campbell about that he knows this stuff.
5. About the confusion of delay, why not simply use if event.value == 'CLICK':
call menu elif event.value in ('CLICK_DRAG', 'PRESS'):
start walk navigation? I haven't tested refactoring your code, but does seem very easy thing to do, right? Or is it not possible because walk is bpy.ops
?
6. Can you understand better why are you using simulating right-up on windows with ctype? Is there a problem with default blenders keymap direction?
1 - No problem
2 - I will look into this and clean up the issues
3 - It's not really a delay, but a time threshold, and ensures that the context menu does not open after navigation, only after a short click and release - I go into more detail in the CLICK_DRAG
response below.
4 - No problem, I'm happy to do it the safest way
5 - CLICK_DRAG
was indeed one of the approaches that I tried, unfortunately it introduces a small 'hiccup' in between click and navigation - you have to Click then Drag to activate it, there are many times that I simply need to be closer or further from an object and I will click then press W or S without dragging but it would not work in that situation - it also lead to issues of needing to drag to start, so if you were going to drag in a particular direction you've already used up some of your mouse area just activating the operator before starting the navigation drag.
Using the current system allows users to immediately navigate upon pressing the mouse, and will only call the context menu if the mouse is 'pressed' and not 'held' - with the difference between a 'press' and 'hold' being defined by the time threshold. If the mouse is held for longer than the threshold time, then the Context Menu is not called.
6 - On Linux and Mac OS the addon works as it should without any additional code.
When I test it on Windows, Blender does not always recognize the 'Right Mouse Up' event.
I don't know why this is happening, it may be a bug, but it means that the user cannot exit 'Walk Navigation'.
I tried manually calling a 'Right Mouse Up' event a second time via code on Windows systems and this resolved the behavior.
I will do some refactoring and testing and keep an eye on this thread for recommendations re: platform check and bugfixes that might impact the code.
Thank you for taking the time to test, the functionality seems like it should be an easy task, and it seems like Blender has all the systems to accommodate it, but in practice there are some issues to deal with.
Word back is to use platform.system() == "Windows"
to check for windows.
Made the changes from __package__
to __main__
in the __init__
file.
Fixed the keymap issues.
Implemented the change from sys.platform
to platform.system
, however, in testing the latest version of the addon with 4.2 failed to produce the navigation bug:
platform
and Ctypes
I started development on this addon for Blender 2.8, and the issue was present there, and other users reported issues with later versions on Windows so I assumed that I still needed the OS check and windll call - but if there is currently no bug on Windows in 4.2, then I don't need Ctypes
or platform
at all
Thanks!
I'll approve this and rest of the workflow issues/difficulties can be dealt with based on user reviews.
Hey everyone,
Just a heads-up about a recent change regarding the licensing of add-ons on the Blender extension platform. Moving forward, all add-ons will need to be released under the GNU/GPL 3.0 license (SPDX:GPL-3.0-or-later). This is mainly to keep things simple and consistent across the board.
Previously, we accepted various licenses as long as they were compatible with Blender’s distribution. However, to avoid any confusion and streamline the process, all add-ons using the bpy API should now be presented as GPL 3 (the same license the Blender bundle is distributed). Regardless of whether the original code was under GPL 2, or something else like MIT or ZLIB.
Existing add-ons versions won't be affected. However, new updates will need to comply to the revised requirements.
Thanks for understanding, and feel free to reach out if you have any questions.
uploaded new version: Add-on "Right Mouse Navigation" v2.3.9
Sign in to comment.
Ready for review