Found 340 posts.
Search results Show results as topic list.
Technical Discussion » Group Selection hotkeys (F, G)
- Ondrej
- 1072 posts
- Offline
It looks like you need to have the mouse over some geometry for these hotkeys to work.
Technical Discussion » Curve SOP handle not in sync with prefs
- Ondrej
- 1072 posts
- Offline
The underlying handles should share a lot of the code, so should be subject to the same preferences. Which preferences aren't affecting these handles?
Houdini Learning Materials » snapping point to a Null
- Ondrej
- 1072 posts
- Offline
We use a new faster drawing method for nulls and bones in H15 that does not yet support snapping.
This new method is not used for a given null/bone when you dive the viewer into that object, so a (terrible) workaround is to RMB on the handle you want to move, turn on the persistent flag, dive down into the object you want to snap to, move and snap the handle, then jump back up and RMB on the handle to turn off the persistent flag.
This new method is not used for a given null/bone when you dive the viewer into that object, so a (terrible) workaround is to RMB on the handle you want to move, turn on the persistent flag, dive down into the object you want to snap to, move and snap the handle, then jump back up and RMB on the handle to turn off the persistent flag.
Houdini Lounge » road intersections in a city asset
- Ondrej
- 1072 posts
- Offline
grayOlorin
Credit to Ondrej for the dissolve trick! (which later led me to the carve trick)
I only passed it on. It was pointed out to me by someone else.
Houdini Indie and Apprentice » Changing even with Window Pinned
- Ondrej
- 1072 posts
- Offline
Unfortunately, the current folder is represented by the value of a switcher parameter on the node, and so will be the same in all dialogs.
Technical Discussion » Aligning rotation manipulators to stamped geometry
- Ondrej
- 1072 posts
- Offline
Technical Discussion » How to remove HUD Sliders?
- Ondrej
- 1072 posts
- Offline
You can't bring up the RMB menu on these HUD sliders because the handle is disabled, for one of two reasons. You may be in a state that disables handles, like the view state, or the parameter the slider is bound to is itself disabled.
In the first case, you can hit Enter to launch the state of the current operator, which should enable the handles, and then you can remove the handle by turning off the Persistent toggle in the RMB menu.
In the second case, you can select the handle in the handle list pane and hit the delete key.
Turning off the display of the handle in the handle list pane, or the RMB menu on the Show Handle button in the left tool bar will hide the slider, but will not remove it entirely.
In the first case, you can hit Enter to launch the state of the current operator, which should enable the handles, and then you can remove the handle by turning off the Persistent toggle in the RMB menu.
In the second case, you can select the handle in the handle list pane and hit the delete key.
Turning off the display of the handle in the handle list pane, or the RMB menu on the Show Handle button in the left tool bar will hide the slider, but will not remove it entirely.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- Offline
McNistor
Why another key? Pressing on the same key again is easy enough for getting into “all” mode. It was the “last state” that required you to recall what you did previously which could very quickly become very frustrating.
Maybe some hotkeys for toggling them on/off like shift+2/3/4 would be a something of value for the savvy that want specific components only.
Going back to the default “all” mode is probably okay for most usage. The times it becomes annoying is when you've explicitly turned off a component, like primitives, or if you've turned on breakpoints when you're working with splines. Going back to the previous state deals with these edge cases. Going back to a fixed state would also work as long as the user can easily change what that fixed state is. Maybe hit a hotkey to save the current toggles as “all”?
McNistorOndrej
This should already be the case in 15.0.294. If a component type is disabled, you cannot box pick it (unless shift or ctrl is held, but that's a special case).
Yeah, but that's bad. If a component is disabled, you shouldn't be able to pick it by any means. This why this whole thing becomes confusing at times - if you have say a poly selected when in “all” mode and disable poly (4) you're still going to be able to select polygons with box-sel by holding shift as you said. The alternative would be to pick one or the other, point or edge as active for box-sel, but which one?
I think this can be argued either way. If you're holding “shift” to add to the current selection you really can't pick anything other than primitives (since we don't support heterogeneous selections). So the choice, if primitives are disabled, is really between selecting primitives, selecting the primitives corresponding to the edges or points you highlight, or selecting nothing. The third option is not really useful, and the second requires guesswork about what to highlight. I chose the first, primarily because the second didn't occur to me at the time.
This behavior is undesirable for when in an isolated component and that's what matters. Are there serious technical hurdles to make an exception for isolate edit?
I disagree. I feel it's perfectly reasonable to only have point selection enabled when you don't want to accidentally drag an edge or primitive. I generally dislike trying to second guess the user. This immediate drag of components during selection can also be a problem when selecting for other states, so I think a better approach is to provide a general selection option to toggle this behavior.
McNistor
Making the gizmo temporarily disappear when holding shift/ctrl for dealing with close together components that would otherwise be “covered” by the gizmo.
I initially wanted to do this, but the problem is that shift and ctrl have meaning when dragging a handle. I never came up with a good way to reconcile this. I suppose it could be a setting in the state itself?
Technical Discussion » camera reset on selection issue
- Ondrej
- 1072 posts
- Offline
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- Offline
McNistorOndrej
I don't see how this differs functionally from my above suggestion. That is, you're always in tweak mode, the 2,3,4 hotkeys isolate a component type for selection, and some other hotkey restores your last multi-toggle enabled state.
The difference is: when you type say ‘2’ again it will go the “previous state” instead of “all”.
Yes, that's what I implemented in 15.0.294, but, as you say, that requires the user to pay too much attention to the current state and do some mental gymnastics. What I'm proposing now is that 2,3,4 only isolate, and a new hotkey be added to restore the multi-toggle state.
McNistor
Another is, which is very important and not the first time I'm mentioning it, is that this omni-tweak, even when isolated in a single component I can accidentally click on a component and drag-move it when trying to a box-select. The shift/ctrl thing works but is a very poor design choice because beside the fact that it doesn't make sense to hold shift when you have nothing selected it also means that you have to deselect whatever you have selected first before another shift + box select when you don't want to add to selection. Deal breaker for me.
This should already be the case in 15.0.294. If a component type is disabled, you cannot box pick it (unless shift or ctrl is held, but that's a special case). In terms of immediately dragging components, it behaves the same as the selectors for other states that support such dragging (transform SOP for example).
It occurs to me now that perhaps you've been assuming that non-tweak selectors do not let you immediately drag components, which is not true. That is to say, if you're selecting for a state that supports such dragging, say the Transform SOP, then you cannot start your box selection over the geometry without immediately picking and dragging a component.
Ondrej
I guess my question is what are you getting from a regular selector selecting points that you aren't getting from the edit selector with only points enabled? I think this is what I'm not understanding in all this discussion. By design they should be very very similar.
McNistor
Not sure how can you avoid that w/o having a separate tweak mode. Again, I've explained it earlier, why each mode is important: when in isolate - quick selection w/o worrying you're gonna grab one accidentally regardless of you selection method and when in tweak - access to all components for dragging, nudging, etc as shown in a .gif above.
An alternative to avoiding adding the classic edit mode back (because for some reason that's only as a last resort) is to disable this click'n'move feature when in isolate.
Again, classic edit mode had the same click'n'move problem. Maybe you never noticed this because you only ever tried to box-select starting over the geometry when selecting points. In 15.0.294 you can just hit ‘2’ and box select your points the same way. If you accidentally start your drag over a point, then yes, it will drag that point instead of box selecting, but this is no different than the old edit state.
It now seems to me that you want a mode that specifically disables the immediate click drag of components, which is not the same thing as a classic edit mode (though yes, if we had a classic edit mode, we could also associate it with such a restriction).
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- Offline
McNistorOndrej
Another option is to have 2,3,4 only isolate, and have a separate hotkey to restore your last state that had multiple component types enabled. I just thought it would be faster to hit a hotkey to temporarily limit selection to a particular type, make your selection, and then hit that same hotkey to get back to your previous selection types.
Here's how a help section should read in explaining a simple straightforward workflow:
-activate a transform tool to enter edit mode
-to select points press ‘2’
-to select edges press ‘3’
-to select faces press ‘4’
-to enable the tweak mode, press 'x'. In tweak mode, to toggle Off (remove) one component ctrl click its respective icon; to toggle it On (adding), shift click it
That's it.
I don't see how this differs functionally from my above suggestion. That is, you're always in tweak mode, the 2,3,4 hotkeys isolate a component type for selection, and some other hotkey restores your last multi-toggle enabled state.
- to select only points, press ‘2’
- to select only edges, press ‘3’
- to select only faces, press ‘4’
- to restore the last multi-type selection mask, press ‘x’
or alternatively,
- to restore the full multi-type selection mask, press ‘x’
I guess my question is what are you getting from a regular selector selecting points that you aren't getting from the edit selector with only points enabled? I think this is what I'm not understanding in all this discussion. By design they should be very very similar.
McNistor
Regarding the current workflow, I swear that right now I don't know what is a bug and what is normal, that is, a consequence of the implemented workflow.
As a quick example, after I did a few modeling ops on a few objects, deleted them, created a new one, pressed 2 to enter point, pressed T and bam! I'm in edge mode. Is this is bug or a consequence? I have a feeling it's the latter.
That is a bug, likely unrelated to all this hotkey discussion.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- Offline
McNistor
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.
The design is as follows. If you hit 2, and points are not the only type enabled, then it will save what is currently enabled, clear everything, and enable only points. If you hit 2, and points are the only type enabled, then it will restore the enabled types it saved earlier and also enable points. So 2 will toggle between only points and points plus something else.
What are you finding unintuitive? The hotkeys to isolate a type for selection mimic how regular selectors work, so is it using the same hotkey to switch back to that type plus whatever was enabled earlier?
Another option is to have 2,3,4 only isolate, and have a separate hotkey to restore your last state that had multiple component types enabled. I just thought it would be faster to hit a hotkey to temporarily limit selection to a particular type, make your selection, and then hit that same hotkey to get back to your previous selection types.
McNistor
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.
This is only true for the first Edit in a session. Any successive Edit state in a session will start with the previous settings.
McNistor
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.
If you isolate the component type with a hotkey, then than component type is the only one you can box select unless you hold shift or ctrl. If you're experiencing otherwise, then it is a bug.
SI Users » Construction mode
- Ondrej
- 1072 posts
- Offline
You can continue to manipulate an edit SOP in the middle of the chain as long as it is the current SOP (i.e. the one selected SOP in the worksheet), regardless of where the display flag if the mode of the viewer is Show Current Operator (the default, can be changed in the right mouse button menu of the geometry select button on the left sidebar).
There is no mode that will automatically search your entire chain for an edit to manipulate.
The selectable template flag does allow you to interactively select from that geometry and then manipulate it, but as soon as you manipulate it, the new node (or the edit SOP itself if it is being reused) will become the current SOP.
There is no mode that will automatically search your entire chain for an edit to manipulate.
The selectable template flag does allow you to interactively select from that geometry and then manipulate it, but as soon as you manipulate it, the new node (or the edit SOP itself if it is being reused) will become the current SOP.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- 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).
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).
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- Offline
McNistorOndrej
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.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- Offline
I just lost a long detailed response because of stupid forum, so this version will be less rambling.
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.
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.
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?
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.
McNistorOndrej
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.
McNistorOndrej
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.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- 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.
McNistorOndrej
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.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- 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.
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- 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?
Technical Discussion » Tweak/edit tool problems
- Ondrej
- 1072 posts
- 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.
-
- Quick Links