- User Since
- Aug 12 2019, 1:02 PM (27 w, 1 d)
Nov 30 2019
Thanks a ton for your work on this @Campbell Barton (campbellbarton) !! I'll continue testing for any lockups, inconsistencies, etc.
Very exciting that we finally have this working as intended in Blender!
@Campbell Barton (campbellbarton) Thanks Campbell! Can confirm that works now and the 3D Mouse Menu refurbish is very welcome.
Nov 29 2019
Cheers! Tested the latest build and mostly works as expected. Turning on "orbit around selection" seems to cause some serious lockups in the panning....with this setting off, everything is quite fine.
Additionally, some axis are reversed by default. This setting configuration had the Spacemouse Wireless working just as it would in 3D Connexion's viewer application:
Nov 28 2019
@Campbell Barton (campbellbarton) Brilliant!!
Which branch/build was this? Loaded blender-2.82-4659fa547166 (built today) and orbit didn't load as default on factory reset. Using a 3D Connexion Spacemouse Wireless on Windows 10.
@San Tokki (santokki) Nice!! I've no idea how to build or insert code changes to make my own version but it's really good to hear that seems to be working.
Would you be able to drop a .zip of your build I can try out? I'm using the 3D Connexion Spacemouse Wireless, just to check everything works across different models.
If this works, seeing it committed to master would be a godsend for all of us using NDOF navigators.
Aug 31 2019
Sweet! Thank you for the update Paul :)
Aug 21 2019
A good example of proper NDOF device operation is in 3D Coat. Using a device such as 3DConnexion in that environment performs exactly as it would in the training examples/viewer application included with the drivers.
Aug 16 2019
Yeah I totally get that, no need to apologize.
Now that I know it's a necessary sacrifice I'm happy to accept it :)
Aaaah okay. I wasn't aware that you couldn't have AutoGrab on and cancel without it AutoMerging.
I think that logically you could create a state in which cancelling AutoGrab would not AutoMerge...and even if it did, you could rip the vertex.
@Paul Kotelevets (1D_Inc) Where would Auto-Merge cause an issue on the creation of those examples? Saying that it would cause an issue on "complex models" without explaining why doesn't help.
I came across this bug while working on a complex model and found it inconvenient.
Thank you. This is exactly what I've been trying to get across. Inconsistent behavior from Auto-Merge on "Quad from Vertex" operation.
I think Paul was trying to explain that it's by design but couldn't come up with a use case in which Auto-Merge being blocked by the addon would actually result in a desired outcome.
Aug 15 2019
At this point I give up.
Paul, F2 at the very least treats merges differently at the quad from vertex level. The expected response from a user is that vertex-based fills will merge just like edge-based fills.
Being accustomed to that is not learning the software. It is becoming accustomed to an inconsistent behavior, which you still haven't managed to explain the professional benefits of. I've explained why it is not of benefit, and you agreed that it did not increase or decrease working time. Therefore, the benefit is that changing it would make it more intuitive, and would not hurt existing users in a meaningful way.
So now that we've established it does nothing to speed-up or slow-down work, we may now focus on why it's a problem:
AutoMerge inconsistent behavior.
In every other case, AutoMerge will merge two vertices on top of each other. This is what the tool is expected to do.
When a tool does something that is not expected, it is a bug.
I'm not saying that's what F2 is. I use Blender for professional work as well, you don't need to go shooting your highly polished work at me like I don't know the benefit of F2 in complex work.
Here's a use case of filling in faces with a corner selection, which would be possible with a couple of F taps if this wasn't an issue.
Considering how F2 treats edges and allow you to spam F to fill multiple segments, the same is expected here.
I can confirm this behavior was built into F2 from 2.79b, my bad.
The issue is AutoMerge not recognizing the vertices are within the merging threshold. If I wanted them to always merge, I don't have that option. I need to drag it and snap to the vertex it lays on top of.
This apparently still existed in 2.79b too, but seems like a bug behavior to me, since AutoMerge isn't acting in the way one would expect.