- User Since
- Jul 26 2019, 7:55 PM (69 w, 3 d)
Can confirm. This can also be triggered by
- Put the default cube in edit mode
- Create a new scene
- Create a new object and change the mesh to the one in edit mode in the other scene.
In CAD programs selection is usually additive by default. That means, that selection box always add objects to a selection until selection will not be deselected intentionaly, this allow to form complex selections without holding any keys and loosing previous selection set.
Is such an option planned in this patch?
It sounds like you're trying to import a file that doesn't exist. Did you mean to export? Or why don't you just choose your .obj file instead of writing the name of it?
However from what I can tell, directional selection is a standard in CAD apps, but not in other 3D app similar to Blender. So the standard choice there would be to disable directional selection by default in the preferences.
It's been available in 3ds max for more than 10 years. I think Modo also. Not sure about Maya.
Do you have any thoughts about a flip option Brecht, or should I just keep it simple like the current state?
Sun, Nov 22
Created poll functions and moved all checks on the source object there.
Now it should work fine to call the operator from Python too.
Sat, Nov 21
Okay, I did some testing with the Fluid modifier that left me a bit confused about the goal of this function.
Fri, Nov 20
Did you update your drivers or anything else? Tried loading factory preferences? Does it happen in all .blend-files?
Thu, Nov 19
Wed, Nov 18
I agree that we should try to follow the industry standard, but I guess it would be quite easy to add a setting to flip the direction.
I was also thinking maybe there should be toggles to enable/disable this feature per operator? Right now only 4 operators (3d View box/lasso and Nodes box/lasso). There is a risk that would become too messy though.
I think I covered all the basic functionality now. Not so happy about how the lasso tool turned out.. Should probably be clockwise/anti clockwise there instead of the start direction.
Would appreciate if someone could try it, or review the code a bit.
Tue, Nov 17
Closing this because I discovered it's already possible through Object.hide_set(state, view_layer)
Mon, Nov 16
I trust that you know by your huge experience what you are talking about, but from my point of view it's definitely the easiest way to access view layer specific settings per object and really should be possible through the API.
The two properties available are hide_viewport and select. Who knows, maybe in the future there will be more view layer specific settings and then those will appear automagically instead of making workarounds for those too.
Sun, Nov 15
I'm giving this a go again. Would appreciate if someone can look at it. I'm also open to continuing this creating similar functions in other areas to speed up data input/output from Python if someone know of a bottleneck somewhere.
Reading the weights using the new property .weights() is around 30 times faster than looping through all vertices and calling .weight(index) in Python.
Sat, Nov 14
Realized I forgot to change to BKE_object_supports_modifiers in one place.
Fri, Nov 13
The patch grew quite a bit, but I think everything should be covered now.
Thu, Nov 12
Aw, I thought we are discussing the usability of the method, applied by patch as well.
Maybe you did, but I thought you meant you wanted to add something that's already in the patch:
Well, I think it can be solved by adding forth option "always crossing, independently from direction".
But you're right the current blender default behavior should probably be an option (the default) as well.
I don't even know what both of you are you are discussing here. Can we focus on the patch?
Just one thing, a linux user reported he had an error compiling, it's a mismatch I missed that was a warning in vc16 but apparently an error in som other compilers.
This is the default in the patch.
Tue, Nov 10
Sorry for spamming, but I realized I didn't post the latest diff. Just a few fixes/typos/removing old code, otherwise same functionality as a few minutes ago.
Maybe there should be an option in Phabricator not to send notifications to subscribers. :)
Updated the diff.. it should compile now.
Moved the options to Properties under Editing->Miscellaneous->Selection Behavior.
Mon, Nov 9
Sun, Nov 8
Sun, Nov 1
Fri, Oct 30
Thu, Oct 29
Tue, Oct 27
I'm not entirely sure if this made it better or worse, but I'm trying a new thing where the code is basically completely rewritten. Now there are three buttons called "inclusive", "exclusive" and "directional" next to the selection modes. I'm not sure about those names but that's another question.
Thanks for reminding me to update the diff @Nathan Craddock (Zachman)
Sun, Oct 25
When I search for `PROP_FLOAT, PROP_PERCENTAGE``` I get a few matches like eraser_strength_factor, I guess they are cases where the developer wanted to force display of percents, or just old code?
"remove_ratio" should be a RNA_def_float to remove the % sign, or keep it as a RNA_def_float_percentage and change the max value to 100 and change the execution code I guess.
Ok I decided to keep it as simple as possible and removed the extra stuff.
Improving the depth value (where the view will pivot around after zooming) is for another time.
Creating a rect in the center of the border to improve accuracy of the depth, fallback to the whole border.
Oct 25 2020
I can reproduce this, and also the front faces only option is not really working as expected. It seems it's only looking at the direction of the camera, not if the faces are actually angled toward the camera.
Oct 24 2020
Ah, I get what part of the problem is now. It's not taking the viewport focal length into account. The problem gets worse as you increase the focal length of the viewport.
Another problem is that the height of the selection box is not very important in the calculations either which means any box with a lower x/y ratio than the view will get cut more.
I made a patch that kind if works a bit better but I will continue investigating.
@Campbell Barton (campbellbarton) I just noticed "text.paste" (ctrl+v, shift+ins) don't repeat but they probably should, right?
I'm not able to reproduce this. Can you give some more info on how to reproduce it? Or can you check if it's fixed in the latest Blender version?
I tried to fix this in a simple way by multiplying the threshold value with the value that is compared against. And if delta is negative, the threshold is multiplied by 0.5 to make the range between 50% smalller to 100% bigger. Do you see any problems with this? Will it mess with any other select similar modes?
Oct 22 2020
Oct 21 2020
Oct 20 2020
Changed from MOVE_ON/MOVE_OFF flags to a toggling MOVE.
Simplified the for-loop as suggested (with a tiny change to make it work).
True, I didn't even know it was possible by expanding, so it's pretty much useless then I guess. Or atleast might cause more harm than good.
Oct 19 2020
Oct 17 2020
Added the move function to line gestures too, so now all selection types and the new sculpt line project for example should be supported.
Oct 16 2020
Made Lasso gesture movable too.
This also works with the lasso tool now, so maybe the review can be postponed a little while until I update the diff again.
Updated as comments suggested.
Added repeat: false to all space bar commands, and any: true to allow modifiers while moving the selection.