Tweak/edit tool problems

   7270   30   2
User Avatar
Member
1755 posts
Joined: March 2014
Offline
The main problem I'm having with the edit tool is that it is in tweak mode and in that only when having a transform tool active. That makes it impossible to select when zoomed in, as is often the case when detailing some small part of a mesh - it forces the user to either go in select mode or to zoom out to be able to drag select from outside the silhouette of the mesh if what you want to select is best suited for a box-selelction.



Proposed fix

Bring back the old mode of the edit node and make the current one a toggle:



I miss the old way of editing for its non-intrusiveness. Tweak mode is cool, a long awaited feature which will hopefully become great with a few enhancements (like picking a reference component on the fly, collapsing points, etc), but please let the user decide when to use it.

I've looked in the Hotkey editor and I didn't find an entry for those modes. They have to have a hotkey (by default or assigned by the user) for quickly accessing those modes.

What's your thoughts?
User Avatar
Member
1265 posts
Joined: March 2014
Online
Best way I could find was to switch off poly selection. Not perfect but it works.

4 is the hotkey to toggle it on or off, but what breaks it is going back and forth between point an poly selection. Once you've selected polys it is hard to rectangle select points again.

Attachments:
Edit_points.gif (1.3 MB)

Werner Ziemerink
Head of 3D
www.luma.co.za
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Yeah… I know of these hacks, but they're annoying (to put it mildly) to work around so that is why I think we ought to have the tweak mode be an addition to the normal (old) edit, not a replacement.
User Avatar
Staff
1072 posts
Joined: July 2005
Offline
Werner Ziemerink
Best way I could find was to switch off poly selection. Not perfect but it works.

4 is the hotkey to toggle it on or off, but what breaks it is going back and forth between point an poly selection. Once you've selected polys it is hard to rectangle select points again.

There are a couple of problems with the sloppy selections and one of them is box selecting. When you already have a selection, area selections are automatically restricted to that type. The real problem is when you don't have a selection. Right now area selections are a little too coupled to the previously selected entity, so if you want to box select points after selecting polys, you need to switch to point selections in order to box select points. The two ways of doing that are to either first click on a point, or use the convert to point selection hotkey (ctrl+shift+2). I have some thoughts on how to address this.
User Avatar
Staff
1072 posts
Joined: July 2005
Offline
McNistor
Yeah… I know of these hacks, but they're annoying (to put it mildly) to work around so that is why I think we ought to have the tweak mode be an addition to the normal (old) edit, not a replacement.

The old edit had a similar problem if you tried to box select polygons when zoomed in. The easiest way to avoid the immediate drag is to use a selection modifier key like shift or ctrl when drawing the box as this disables the immediate drag.

The sloppy selections still have the issue that it is impossible to box select points after having selected polygons without first selecting a point which needs to be addressed.

Are you asking to be able to toggle the immediate drag off?
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Ondrej
There are a couple of problems with the sloppy selections and one of them is box selecting. When you already have a selection, area selections are automatically restricted to that type. The real problem is when you don't have a selection.

Looking at the .gif I've posted, even though I have points selected, the first drag picks an edge and the second a poly. The restriction applies only when you drag from outside the object's silhouette.
For inside the object's silhouette holding shift works, but is this the optical workflow? I think Houdini has enough weird things going on for things that should be straight-forward to add one more IMO.

Ondrej
Right now area selections are a little too coupled to the previously selected entity, so if you want to box select points after selecting polys, you need to switch to point selections in order to box select points. The two ways of doing that are to either first click on a point, or use the convert to point selection hotkey (ctrl+shift+2). I have some thoughts on how to address this.

Can you please share them?
The main reason for which I asked for the classic edit back, is that often times I just want to be in point mode and not be conscious of what I need to do or avoid doing so that I don't select other type of components I don't want. It's really bad…



Ondrej
The old edit had a similar problem if you tried to box select polygons when zoomed in. The easiest way to avoid the immediate drag is to use a selection modifier key like shift or ctrl when drawing the box as this disables the immediate drag.

Holding shift/ctrl does solve the immediate drag as previously said but it still doesn't solve the problem (which the old edit had) of being impossible to select close together components without transforming them. When the old edit was around I've made a proposal (no RFE though) which probably got lost in the bit jungle - when holding a modifier key, make the gizmo disappear. Not sure if this is possible w/o transient keys or otherwise.

Ondrej
The sloppy selections still have the issue that it is impossible to box select points after having selected polygons without first selecting a point which needs to be addressed.

Are you asking to be able to toggle the immediate drag off?

If a toggle-able immediate drag is implemented and the problem of having to select a single different component before being able to box-select is solved, I think we're pretty much back to the old edit behavior, aren't we?
IMO adding the old edit and make all this tweak a toggle is a lot more straight-forward and has the added benefit of being able to remain (strictly) in a single component with single button push.
But, if you think there's something which would work better, let's try…
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Oh, one thing I forgot to mention as an advantage of adding back the classic edit: we get to keep this behavior of selection dependency which I'm pretty sure it can come in handy in some situations. I don't find it bad, it's just that it's the only thing going on that makes it bad.
User Avatar
Staff
1072 posts
Joined: July 2005
Offline
McNistor
Looking at the .gif I've posted, even though I have points selected, the first drag picks an edge and the second a poly. The restriction applies only when you drag from outside the object's silhouette.
For inside the object's silhouette holding shift works, but is this the optical workflow? I think Houdini has enough weird things going on for things that should be straight-forward to add one more IMO.

Yes, this where sloppy selections are more clumsy. However, the old edit would have the same issue when trying to box select primitives.

McNistor
Can you please share them?

I have several thoughts. The first is to check if the user has toggled off the selecting of the component type we're currently locked onto, and if so, box select the next highest priority component type that is enabled. So in this case, all you'd have to do is turn off selecting of primitives by hitting 4, which is no harder than hitting 2 to switch to point selection in the old non-sloppy selector. Another option is to have a separate type for area selections.

McNistor
Holding shift/ctrl does solve the immediate drag as previously said but it still doesn't solve the problem (which the old edit had) of being impossible to select close together components without transforming them. When the old edit was around I've made a proposal (no RFE though) which probably got lost in the bit jungle - when holding a modifier key, make the gizmo disappear. Not sure if this is possible w/o transient keys or otherwise.

Prior to MMB being used for indirect dragging and all this internal handle picking of translate planes, MMB was used as a safe-select button, meaning you would never accidentally drag the selected components when trying to do an area select. You can still use it for this if you disable all these new features in the preferences. This isn't ideal, but I'm not sure how to support this functionality without transient keys.

McNistor
If a toggle-able immediate drag is implemented and the problem of having to select a single different component before being able to box-select is solved, I think we're pretty much back to the old edit behavior, aren't we?

Not quite. As we've covered above, the old edit still had problems box selecting primitives when zoomed in on the geometry. We need to resurrect some kind of safe-selection mode to really address the issue.
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Ondrej
Yes, this where sloppy selections are more clumsy. However, the old edit would have the same issue when trying to box select primitives.

I might be remembering it wrong, but I don't think H14 had this exact problem. If what you tried to select was “inside” the event horizon of the gizmo then yes. Otherwise you could select just fine even by clicking inside the obj. Not saying this was perfect, but there's a reason some software has transient keys solving these otherwise difficult situations. Necroing an idea I've put forth when I first got in touch with Houdini modeling/interaction - it's best to deal with the most basic, underlying features (like transient keys to almost everything) and lots of other higher level stuff will get easier. Fixing/improving transformations before poly ops like bevel et al comes to mind as well. Anyway this is a side-note and obviously my personal view on these things.

Ondrej
I have several thoughts. The first is to check if the user has toggled off the selecting of the component type we're currently locked onto, and if so, box select the next highest priority component type that is enabled.

If I got this right, I find it counter-intuitive for modeling where the less brainpower for accessing certain things is necessary the better. The only instance when “I use a hotkey for the thing I want to not be in” is when using a toggle. Getting in different components using toggles doesn't seem a very clear and quick approach. In this particular case, I press ‘2’ to be in point, not press ‘4’ to not be in poly and find myself in both point and edge. Want point? Press ‘2’, not ‘3’ and ‘4’ to toggle them off.

I think it's my fault for not expressing the following idea in the most clear way: the possibility to go to a component directly with one press of a button and be in that component only, with no way of selecting other type of component (no way other than pressing its correspondent hotkey) is essential. Having this tweak mode at your finger tips is great for quick dirty nudging of an organic shape or for sliding on an edge (not edge sliding), but for hard-surface or architectural you'll want quick and clean access to specific components.

What does next highest priority component mean in this case?

Ondrej
So in this case, all you'd have to do is turn off selecting of primitives by hitting 4, which is no harder than hitting 2 to switch to point selection in the old non-sloppy selector.

But you have to press also ‘3’ so it is harder. And counter-intuitive if you ask me, for the reasons I've mentioned. You're doing gymnastics with toggling stuff on and off when in tweak. Again, I wouldn't have a problem with this if I also had the old way of working - the classic edit where I go straight to the target with one button push, to activate it not toggle other stuff off.

Ondrej
Another option is to have a separate type for area selections.

Can you expand on that? Not sure what you're referring to…

Ondrej
Prior to MMB being used for indirect dragging and all this internal handle picking of translate planes, MMB was used as a safe-select button, meaning you would never accidentally drag the selected components when trying to do an area select. You can still use it for this if you disable all these new features in the preferences. This isn't ideal, but I'm not sure how to support this functionality without transient keys.

We definitely need transient keys, for a ton of things.

Ondrej
Not quite. As we've covered above, the old edit still had problems box selecting primitives when zoomed in on the geometry. We need to resurrect some kind of safe-selection mode to really address the issue.

I don't think such a thing is needed. Again, transient keys.

I have to ask: is there a technical reason for which you're not considering adding back the classic edit and make the current tweak mode a simple toggle?
Remember when I said Houdini makes simple things complicated (or something to this effect) and you agreed and added that even so, you've made progress and I agreed?
IMO replacing the classic edit with the tweak tool instead of adding it, made things complicated.
User Avatar
Staff
1072 posts
Joined: July 2005
Offline
McNistor
I might be remembering it wrong, but I don't think H14 had this exact problem. If what you tried to select was “inside” the event horizon of the gizmo then yes. Otherwise you could select just fine even by clicking inside the obj. Not saying this was perfect, but there's a reason some software has transient keys solving these otherwise difficult situations.

I think you're remembering wrong in this case. You didn't have the problem of primitives getting in the way of attempting to box select points, but you did still have the problem of primitives getting in the way of attempting to box select primitives (in that they would interpret the mouse event as a drag of the primitive instead of a box selection).

McNistor
If I got this right, I find it counter-intuitive for modeling where the less brainpower for accessing certain things is necessary the better. The only instance when “I use a hotkey for the thing I want to not be in” is when using a toggle. Getting in different components using toggles doesn't seem a very clear and quick approach. In this particular case, I press ‘2’ to be in point, not press ‘4’ to not be in poly and find myself in both point and edge. Want point? Press ‘2’, not ‘3’ and ‘4’ to toggle them off.

I think it's my fault for not expressing the following idea in the most clear way: the possibility to go to a component directly with one press of a button and be in that component only, with no way of selecting other type of component (no way other than pressing its correspondent hotkey) is essential. Having this tweak mode at your finger tips is great for quick dirty nudging of an organic shape or for sliding on an edge (not edge sliding), but for hard-surface or architectural you'll want quick and clean access to specific components.

Another option I've been considering is to interpret the ‘2’, ‘3’, ‘4’ hotkeys not as toggling that particular component type, but rather as “soloing” that particular component type (i.e. turn it on and all the others off for picking). That way it becomes very easy to isolate yourself to a particular component type. We still wouldn't automatically convert the current selection to that type as we used to do in H14, but it should, along with a few small bug fixes, alleviate most of the drudgery we're discussing here and be more consistent with other selectors.

McNistor
What does next highest priority component mean in this case?

The most granular component type. So in order of priority vertex > point > breakpoint > edge > primitive.


Ondrej
So in this case, all you'd have to do is turn off selecting of primitives by hitting 4, which is no harder than hitting 2 to switch to point selection in the old non-sloppy selector.

McNistor
But you have to press also ‘3’ so it is harder. And counter-intuitive if you ask me, for the reasons I've mentioned. You're doing gymnastics with toggling stuff on and off when in tweak. Again, I wouldn't have a problem with this if I also had the old way of working - the classic edit where I go straight to the target with one button push, to activate it not toggle other stuff off.

Technically no, not in this case, since if you've currently got a primitive selection, and you've toggled primitive selecting off, the box pick would prioritize points over edges. But I acknowledge your point.

McNistor
Ondrej
Another option is to have a separate type for area selections.

Can you expand on that? Not sure what you're referring to…

I haven't given it much thought, but it was along the lines of explicitly managing the component type for area selection separately. But I don't think this is a good idea.

McNistor
I have to ask: is there a technical reason for which you're not considering adding back the classic edit and make the current tweak mode a simple toggle?
Remember when I said Houdini makes simple things complicated (or something to this effect) and you agreed and added that even so, you've made progress and I agreed?
IMO replacing the classic edit with the tweak tool instead of adding it, made things complicated.

Nope, no technical reason. I'm actually not ignoring this suggestion. However I'd much prefer to get the tweak/sloppy selection to a state where it functions just as efficiently (if possible given some of the constraints). In other words, I'm hoping it won't be necessary.
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Ondrej
Another option I've been considering is to interpret the ‘2’, ‘3’, ‘4’ hotkeys not as toggling that particular component type, but rather as “soloing” that particular component type (i.e. turn it on and all the others off for picking).

And then you have lost the ability to select any type of component on the fly without manually switching, which is what makes a tweak tool be a tweak tool.

Ondrej
That way it becomes very easy to isolate yourself to a particular component type. We still wouldn't automatically convert the current selection to that type as we used to do in H14, but it should, along with a few small bug fixes, alleviate most of the drudgery we're discussing here and be more consistent with other selectors.

But this is a big problem, because it implies that you first have to LMB on that which you “isolated” first, right? If I got this right, it's bad, really bad. It slows down work quite a lot. I can't imagine a modeler who normally “flies” in the viewport stopping to crapshoot a component everytime they want to switch.
This one I might've misunderstood, so please rephrase or ignore what I just said.

Ondrej
The most granular component type. So in order of priority vertex > point > breakpoint > edge > primitive.



Technically no, not in this case, since if you've currently got a primitive selection, and you've toggled primitive selecting off, the box pick would prioritize points over edges. But I acknowledge your point.

So it's a prioritization the s/w does the user is a spectator. You know why that is bad in this case…

Ondrej
McNistor
I have to ask: is there a technical reason for which you're not considering adding back the classic edit and make the current tweak mode a simple toggle?
Remember when I said Houdini makes simple things complicated (or something to this effect) and you agreed and added that even so, you've made progress and I agreed?
IMO replacing the classic edit with the tweak tool instead of adding it, made things complicated.

Nope, no technical reason. I'm actually not ignoring this suggestion. However I'd much prefer to get the tweak/sloppy selection to a state where it functions just as efficiently (if possible given some of the constraints). In other words, I'm hoping it won't be necessary.

OK, here's a few logical statements:
there are two needed modes - 1) an exclusive mode, in which the user has complete control over which component is active, hence having highest priority and 2) an inclusive mode, in which all components have the same priority (with a temporary highest - the selected comp.), also called a tweak mode.
Each mode has its strength, therefore they both are needed and as far as I can tell, they're mutually exclusive.
I'll let you draw the conclusion whether it is necessary or not.
If you somehow find that they're actually not mutually exclusive, please consider if the new solution you found is easier for the user than keeping it as two separate modes.

p.s. BTW, you know does XSI solve the no. 2)?
It doesn't. You can't drag select when in tweak mode, so what you click on is what you have. No priority headaches. But you still can box-select when in tweak, because you have sticky keys and as such you can temporarily leave the tweak tool by activating any selection tool.
User Avatar
Member
1265 posts
Joined: March 2014
Online
Sticky keys would solve a lot of problems. It adds allot to modeling workflow without the user realising it 90% of the time.
Werner Ziemerink
Head of 3D
www.luma.co.za
User Avatar
Staff
1072 posts
Joined: July 2005
Offline
I just lost a long detailed response because of stupid forum, so this version will be less rambling.

McNistor
Ondrej
Another option I've been considering is to interpret the ‘2’, ‘3’, ‘4’ hotkeys not as toggling that particular component type, but rather as “soloing” that particular component type (i.e. turn it on and all the others off for picking).

And then you have lost the ability to select any type of component on the fly without manually switching, which is what makes a tweak tool be a tweak tool.

You can always turn the selection of other components back on. In fact, I'm thinking that if the 2,3,4 hotkeys isolate their respective component type, then hitting the hotkey again when that type is already isolated could restore the previous settings.

McNistor
Ondrej
That way it becomes very easy to isolate yourself to a particular component type. We still wouldn't automatically convert the current selection to that type as we used to do in H14, but it should, along with a few small bug fixes, alleviate most of the drudgery we're discussing here and be more consistent with other selectors.

But this is a big problem, because it implies that you first have to LMB on that which you “isolated” first, right? If I got this right, it's bad, really bad. It slows down work quite a lot. I can't imagine a modeler who normally “flies” in the viewport stopping to crapshoot a component everytime they want to switch.
This one I might've misunderstood, so please rephrase or ignore what I just said.

You'd first have to LMB on what you isolated in order to get a selection to move. You wouldn't need to LMB on a point first to let Houdini know that you want your next area selection to be a point selection, which is what we have now.

McNistor
So it's a prioritization the s/w does the user is a spectator. You know why that is bad in this case…

The prioritization I'm talking about is done solely to restrict a box selection when multiple component types are enabled. You already have full control over what component types are available so I don't really understand the problem. Speaking solely in the context of area selections with a sloppy selector, what are the alternatives? Pop up a menu after the selection to let the user choose which entity out of all those selected they meant to select? Have a UI somewhere to allow the user to explicitly set priorities?

McNistor
OK, here's a few logical statements:
there are two needed modes - 1) an exclusive mode, in which the user has complete control over which component is active, hence having highest priority and 2) an inclusive mode, in which all components have the same priority (with a temporary highest - the selected comp.), also called a tweak mode.
Each mode has its strength, therefore they both are needed and as far as I can tell, they're mutually exclusive.
I'll let you draw the conclusion whether it is necessary or not.
If you somehow find that they're actually not mutually exclusive, please consider if the new solution you found is easier for the user than keeping it as two separate modes.

I'm not currently convinced that two modes are necessary if the only problem with sloppy selection is area selection (which is one of only two places where the “active” component type matters for sloppy selection, the other being which decorations are displayed). I'm currently working on some fixes, that are, unfortunately, dependent on other fixes, but I'll see how the sloppy selector feels after I make the changes I've described in this thread.
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Ondrej
I just lost a long detailed response because of stupid forum, so this version will be less rambling.

And that is why I always hit ctrl+a ctrl+c before posting on anyf orum.

Ondrej
You can always turn the selection of other components back on. In fact, I'm thinking that if the 2,3,4 hotkeys isolate their respective component type, then hitting the hotkey again when that type is already isolated could restore the previous settings.

How would this work… Let's consider a particular case: I select an Obj and want to go point mode. What would be the default, all active? Only the point? If all active, I'd have to hit ‘2’ again to go to point only. Else, hitting ‘2’ again would get me into “all” or ‘3’ for edge and ‘4’ for poly. Hitting any of these twice will get me to “all”. Like this?
This could work.
However when in “all” mode if you keep area selection active, we're going to have again the old problem - who's the “prioritiest” of them all. Probably the best way to solve this would be to make a box-selection impossible when in “all” and when we'll have transient keys, one could just hold 2, 3 or 4 to box select any of these.


Ondrej
The prioritization I'm talking about is done solely to restrict a box selection when multiple component types are enabled. You already have full control over what component types are available so I don't really understand the problem. Speaking solely in the context of area selections with a sloppy selector, what are the alternatives? Pop up a menu after the selection to let the user choose which entity out of all those selected they meant to select? Have a UI somewhere to allow the user to explicitly set priorities?

No, see above - transient keys - simple, elegant solution

Ondrej
I'm not currently convinced that two modes are necessary if the only problem with sloppy selection is area selection (which is one of only two places where the “active” component type matters for sloppy selection, the other being which decorations are displayed). I'm currently working on some fixes, that are, unfortunately, dependent on other fixes, but I'll see how the sloppy selector feels after I make the changes I've described in this thread.

Yeah, I'm no longer convinced of that either. But, there's however a problem with the laser selection when in “all” mode not just the box-select, specifically when trying to a+MMB to select a full loop/ring, which should probably work well even when you brush over, selecting the loop/ring of the component it picked first. Is by any chance Soft Radius using the MMB? Cause I'm getting stuff…
Anyway, these things have to be thoroughly tested for all type of selections. One more thing I noticed it's not possible and I think it should be, is that one can't change the selection type (F2-F5) when in tweak mode.

Let me know your thoughts about the things I've said. Just a tiny side-note: if I had any say in establishing dev. priorities (which I dont), I'd drop any modeling/interaction related stuff and implement transient keys first , because problems that take a lot of time to circumvent, wouldn't probably even exist if we had those.
User Avatar
Staff
1072 posts
Joined: July 2005
Offline
McNistor
Ondrej
You can always turn the selection of other components back on. In fact, I'm thinking that if the 2,3,4 hotkeys isolate their respective component type, then hitting the hotkey again when that type is already isolated could restore the previous settings.

How would this work… Let's consider a particular case: I select an Obj and want to go point mode. What would be the default, all active? Only the point? If all active, I'd have to hit ‘2’ again to go to point only. Else, hitting ‘2’ again would get me into “all” or ‘3’ for edge and ‘4’ for poly. Hitting any of these twice will get me to “all”. Like this?
This could work.

So let's say you're starting at the object level. You hit ‘2’ to select points, then hit ‘t’ to add an edit SOP. The default state is for points, edges and primitives to be toggled on. This is okay though, because your active selection is points, so all your box picks will be point selections. So you're still selecting points. Let's say you now want to work exclusively with primitives. You hit ‘4’, that remembers you currently have points/edges/primitives enabled, disables points/edges and you proceed to edit primitives. Now you want to go back to full sloppy mode, and so you hit ‘4’ again, and points/edges/primitives are now enabled again. This is actually working reasonably well and feels okay.

I'm just not sure if the un-isolating should restore the component mask to what it was when you last isolated that component or whether it should just go to a good default, with a hotkey to override the default with the current component mask. I'm experimenting with the former, and while it feels natural when going back to the full mask, if you do something like hit ‘3’ to isolate edges, then hit ‘2’ to isolate points, then hit ‘2’ again to restore the previous state, you end up with only edges enabled. So that last ‘2’ switches from only points enabled to only edges enabled, which is kind of jarring, especially since the viewport reports it as “Select Points”.

Going with the latter approach you'd always un-isolate to a reasonable default state. But maybe we could still restore the previous component mask if we also always keep the component type we're un-isolating enabled. So if you hit ‘3’ to isolate edges, ‘2’ to isolate points, and then ‘2’ to un-isolate points you'd have points and edges enabled instead of just points (in the first approach) or points, edges and primitives in the second.

McNistor
However when in “all” mode if you keep area selection active, we're going to have again the old problem - who's the “prioritiest” of them all. Probably the best way to solve this would be to make a box-selection impossible when in “all” and when we'll have transient keys, one could just hold 2, 3 or 4 to box select any of these.

Making it easy to isolate and un-isolate a particular component type should make the priority issue a very minor one.

McNistor
No, see above - transient keys - simple, elegant solution

For the moment I'm concerned with addressing these issues in H15.

McNistor
Yeah, I'm no longer convinced of that either. But, there's however a problem with the laser selection when in “all” mode not just the box-select, specifically when trying to a+MMB to select a full loop/ring, which should probably work well even when you brush over, selecting the loop/ring of the component it picked first. Is by any chance Soft Radius using the MMB? Cause I'm getting stuff…
Anyway, these things have to be thoroughly tested for all type of selections. One more thing I noticed it's not possible and I think it should be, is that one can't change the selection type (F2-F5) when in tweak mode.

The F2-F5 thing is definitely a bug. The other I'll have to look into.
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Ondrej
So let's say you're starting at the object level. You hit ‘2’ to select points, then hit ‘t’ to add an edit SOP. The default state is for points, edges and primitives to be toggled on. This is okay though, because your active selection is points, so all your box picks will be point selections. So you're still selecting points.

But is it OK though… unless I'm not understanding you well, we're back to square one.
When in ‘all’, is the box-selection going to not pick edges/polys even when clicking “inside” the mesh? Either ‘yes’ or ‘no’ it's going to be bad. “no” because user's no longer in full control (H15 current problem) and “yes” because it wouldn't be a tweak tool which has as its main (if not sole) strength the ability to LMB and move any component.
The point I've been trying to relay is that you cannot have a box selection that works well when in “all” mode. You have to cripple either the box selection - to select the “active” component only when dragging from outside - or to cripple the tweak tool by making it impossible to select-and-move any type of component which I wouldn't even call it a tweak tool if that were the case.


Ondrej
I'm just not sure if the un-isolating should restore the component mask to what it was when you last isolated that component or whether it should just go to a good default, with a hotkey to override the default with the current component mask. I'm experimenting with the former, and while it feels natural when going back to the full mask, if you do something like hit ‘3’ to isolate edges, then hit ‘2’ to isolate points, then hit ‘2’ again to restore the previous state, you end up with only edges enabled. So that last ‘2’ switches from only points enabled to only edges enabled, which is kind of jarring, especially since the viewport reports it as “Select Points”.

Going with the latter approach you'd always un-isolate to a reasonable default state. But maybe we could still restore the previous component mask if we also always keep the component type we're un-isolating enabled. So if you hit ‘3’ to isolate edges, ‘2’ to isolate points, and then ‘2’ to un-isolate points you'd have points and edges enabled instead of just points (in the first approach) or points, edges and primitives in the second.

You lost me here (what is a component mask?), but regardless of what exactly you are trying to say here, “a good default” screams like another “let Houdini stick its nose and revert to something” as is currently the case with many things. I cannot stress enough how important user control is. I remember even now my first experience with Houdini felt like a box match because Houdini selects and reverts to what it wants whenever it wants.

Oh right - another thing that struck me is that although I previously accepted that the old edit might not be necessary to bring back (I'm still in that position), I have a hard time figuring out how exactly this tweak mode will deal with selection memory for various components. Right now it's a mess for example. I get selected edges to display even when in scene lvl and with no selection (see attached).

I'm slowly leaning back to adding the classic edit being more straight-forward and with less problems for everyone.



Ondrej
Making it easy to isolate and un-isolate a particular component type should make the priority issue a very minor one.

But to me doesn't seem minor.

Ondrej
For the moment I'm concerned with addressing these issues in H15.

As you wish, I'm just hoping that when we'll have those, you (or whoever from SESI) will be willing to come back on these to make any possible improvements and not classify them as “problem solved, we have bigger fish to fry”.

Attachments:
edge.jpg (29.9 KB)

User Avatar
Member
1755 posts
Joined: March 2014
Offline
One thing I forgot to mention: yes, I know you can hold shift/ctrl to avoid select-drag-move. Having to hold shift even for a new selection is bad enough, but what do you do when you have something selected and you don't wanna add but select something new? Deselect everything then hold shift again?
This sucks man.
User Avatar
Member
1755 posts
Joined: March 2014
Offline
Not sure how or if this is helpful at all: attached is how a tweak tool is used for quick dirty edit of an organic shape.
Notice no gizmo mode (the first axis button is toggled off) so it doesn't get in the way at all. But even if it were enabled, upon selecting and dragging to move, there wouldn't have been a gizmo present. Gizmo would have appeared only on click and release, no dragging.

edit: just realized that this is exactly how Houdini works right now regarding this. A few differences, like lower point activation area which makes it a bit more difficult to pick points, but all in all the same.
A waste of a gif.

Attachments:
xsi_tweak1.gif (650.0 KB)

User Avatar
Staff
1072 posts
Joined: July 2005
Offline
15.0.294 will have the new isolating hotkeys, add support for some more hotkeys, like F2-F5, and add some fixes to area selections.

There are still some outstanding selection bugs in the edit state which will hopefully be addressed soon (that blue selection, selections disappearing, selections sticking around, etc).
User Avatar
Member
1755 posts
Joined: March 2014
Offline
I've tested this and at first I thought that it's a bug that sometimes you get all three upon recalling an already active component mode and other times you don't, but then I've re-read and understood this time what you've said there and it seems it's by design. Sometimes I also get the toggle behavior which could be a bug. Either way it's not intuitive at all.

Also, the fact that when you first create an edit node (which would happen a gazillion times in a modeling session) all components are active is bad.
Yes, the component for which you press the hotkey has priority but upon box-sel from outside, the inside will pick whatever, where you need to hold shift which is bad as explained in an earlier post.

What should be a very simple thing, has become a riddle solving . I don't know what else to say without repeating myself at this point.
  • Quick Links