- User Since
- Jun 27 2019, 9:55 PM (48 w, 1 d)
Tue, May 26
I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
That's why our proposal consists from a single ui button and several overlay options
Single ui button works well for controlling select through/occluded, but tying facedot selection to the overlay is flawed. If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
Mon, May 25
Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
Sat, May 23
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe.
This "Select by Facedots" toggle only applies to Box/Lasso/Circle, but you still need to use facedots to pick a specific face, with a single click. Otherwise you would need to click multiple times to select a face that's behind other geometry. That's how it works in 3ds max and it's always frustrating.
Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately
What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
Wed, May 20
It does not make sense to split modes per tools
Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options. Take a look at Drag option for example: if you set the Drag action to be Select Lasso, all tools will do a Lasso Select. So it's not tool-specific, but a global toggle. Select Through (or any other selection-related option) would work the same way. Here's how it would look like placed in the header:
Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals). Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu. This is a simple and concise solution, that doesn't complicate selection process in any way, but places useful options always within reach in case you need them.
It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm. I think it's better to take the same approach as with this task and clearly decouple selection behaviour from the shading mode.
Fri, May 15
Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts, like these:
Default configuration would be synchronised with tool setting so it would work in the same way.
The problem is that right now there is no place in Blender's UI for global selection settings (because there are no setting, just hardcoded stuff like Facedot selection in X-Ray). So tool settings looks like the only area where multiple options could be put in one place. And it could be made to work globally across Blender. Of course a dedicated space would be even better.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
Wed, May 13
all selection modes
What do you mean?
This is quite a discussion for such a simple and uncontroversial feature :) Anyway, here's my attempt to summarize it and add some suggestions.
Apr 26 2020
Tab + mouse click should work fine, because pie menu is triggered only if the mouse is moved a certain amount. If a drag threshold is set high enough it shouldn't be a problem.
But whatever the default shortcut ends up being, it should be editable in the keymap and not hardcoded in some way.
Apr 24 2020
I think this feature would work well in any of the 6 editing modes, the way Pablo is doing it in sculpt mode (hover and click). The only issue is that there isn't a convenient shortcut that is empty in all different modes. So I think it would be best to add it as a menu item without a shortcut and leave it up to the individual users to decide what shortcut to use, or if they need this feature at all in a specific mode. Blender is really flexible in this aspect, because you can use different shortcuts in different modes for the same action.
Apr 13 2020
Feb 19 2020
So it's not a bug and not an issue with a specific normal map, but a limitation with the box projection? Then maybe it should be mentioned somewhere in the documentation, because it took me quite a while to figure out why my materials look so wrong when I use normal maps.
Feb 18 2020
Are you talking about texture coordinates or setting the normal map to "Object Space"? Because for me normals gets flipped with all the different texture coordinates, but setting the Normal Map node to "Object Space" does appear to help. But it's not a real solution, because if the object is rotated away from 0,0,0, the shading gets completely messed up:
I think that standard normal maps for PBR materials have to be applied in tangent space to work correctly.
Feb 17 2020
Jan 30 2020
Dec 21 2019
Dec 20 2019
@Campbell Barton (campbellbarton) I tried the latest build (12.19) and the problem I described earlier still exists. Only now it depends on whether an object is active (origin is visible as an orange point). And a partial gizmo appears at the world origin before you start dragging:
Dec 16 2019
Dec 14 2019
@William Reynish (billreynish) Ok, I can do that. But since this is still an experimental feature, and this bug happens only when Tool Fallback is enabled, maybe it would be better to discuss such issues in this thread? Reading about the proposed “Tracker Curfew” gave me an impression that the bug tracker is a 'bit' overloaded ATM.
Dec 13 2019
Nice feature, but there's an issue with how Rotate and Scale tools work in Tweak mode:
Basically if you click and drag on an object area where the transform gizmo will appear you get a different action than clicking outside of it. This results in a very inconsistent and confusing behaviour. I think Tweak mode should ignore the gizmo when you click+drag on a new object for Scale/Rotate tools and just perform a corresponding action in screen space. Scale intensity will probably have to be adjusted because it's way too strong if you happen to click near the object's center.
Oct 31 2019
Oct 30 2019
I just tried opening this scene in 2.80 and it looks a bit better. Basically the light leaking appears only when the camera is at a specific distance from the object in front, but in 2.81 beta and up it's always visible. So maybe it's related to the shadow system refactor.
Ok, here it is. But there's nothing special about this file, it's just a bit modified startup scene.
Oct 29 2019
Jul 10 2019
Yes, it still happens on 07.10 build. Here's my settings:
Jul 6 2019
Jun 29 2019
It could pick any object from new selection, would still make a lot more sense than keeping deselected object as active.
Besides, blender does the same thing if you box-select only one object, that's definitely a bug imo.