PDA

View Full Version : Better access to Selections/ possible implementatiion?



jeric_synergy
12-27-2015, 12:35 PM
(apologies if I've posted this idea before)

(LWM) The more I work, the more I find Selection irritating, and specifically, RE-selecting. While PARTS exist, the implementation is lacking, and they have some severe limitations (i.e., no overlap). I also think that the selection process for Point Sets is laborious-- that should not be a menu, it should be a list.

Throwing this out for discussion: a methodology to make REselection a lot easier-- if some other app has a better way, let's hear that too:

What I'm envisioning is:
a scrolling window of automatic selection-saves:
as you make Selections, they are automatically saved as a numbered line,
and they scroll up.
There's a NAME button that allows the user to change the name of the current line,
or RMB to change the name of a non-current line.
If a user SELECTS a line, the associated points/edges/polys are selected,
and the mode changes appropriately.
There is a THRESHOLD parameter: Selections below the THRESHOLD are not saved to the list.
EG: selections less than 10 elements may not be saved if the user decides so.
NAMED sets accumulate at the top of the list
or possibly in a separated portion of the list, if it's taller than the screen.
UN-named sets eventually scroll off the (top of) the list, by a user definable number.
(iow, the user sets the number of selection sets to be retained.)
NAMED sets are saved with the Object
UN-named sets are discarded at QUIT/CLOSE.
An INVERT function tags the text "INVERTED" to a given set.
-if the set has a name, the new line is "NAME+INVERTED".
There is an icon associated with each line to indicate if it is a Point/Edge/Poly selection set.



The main thing here is to AVOID MENUS, which I feel slow down the modeling workflow immensely, and to eliminate the labor involved in making selection

pinkmouse
12-28-2015, 03:36 AM
Really? What do you use all those selections for? When I'm modelling I might use a selection once or twice in a row, but then never again, in fact as the geometry changes it no longer even becomes relevant. I can see, (and want), some sort of "reselect" tool for getting back to a selection you might just have accidentally dropped, but that's about it.

jeric_synergy
12-28-2015, 10:12 AM
That's why unnamed Selections scroll off... crap, did I leave that off? :foreheads The deal (in my mind's eye) was: auto-selections last until they pop off the top of the user-defined window, unless named. So, the user gets like maybe, ohhh, twenty selection opportunities before a selection expires and disappears, at which point you would have forgotten what they do anyway. (But since it only takes ONE CLICK to see what a given line is, browsing the unnamed list isn't onerous.)

The original concept was named sets, which are more important no?, would accumulate at the top of the list, but then I realized this would eventually fill the list. So a separate scrollable portion of the list for named sets is better.

So, it's like a VISIBLE "Undo" queue, but only for Selections. And it will ease the pain of using Selection Sets, since it doesn't use Menus (which are slow and stupid).

I hope that makes more sense.

ernpchan
12-28-2015, 10:18 AM
Submit a feature request. This sounds like something that would go into the scene editor since I think Layout is the future environment for modeling.

jeric_synergy
12-28-2015, 10:28 AM
ernpchan, I'm thinking its own window: it's a stack of sorts.

pinkmouse
12-28-2015, 10:29 AM
I'm still curious as to why you need lots of selections.

ernpchan
12-28-2015, 10:47 AM
ernpchan, I'm thinking its own window: it's a stack of sorts.

If the sdk allowed for non-modal panels one could maybe make this. I don't know if selection sets are available in the sdk.

Like pinkmouse, I don't use selection sets much so this is probably very low priority or something better served to be implemented in Layout. You can't multi select or filter layers in Modeler so there's a lot that a scene editor implementation for Modeler would address.

jeric_synergy
12-28-2015, 11:14 AM
I'm still curious as to why you need lots of selections.
Selection Sets ease difficult selections, whether they are complicated ("every 7th plus all Surfaces named xxx") or just awkward to get to ( neck & torso connections ). Anytime you need to REselect, a selection set is appropriate, but currently is a laborious PITA to take advantage of. IOW, I feel with a less painful implementation, everybody might use them more.

And, I admit I haven't used them, but some subsystems (particles? dynamics?) use selection sets as binary switches (since there is no gradation like in a w.map). --The fact that I can't remember what uses them shows how much I use those subsystems.

As you pointed out, usually a given selection is most useful for only a short period of time. By having them scroll off, mindspace remains uncluttered, but by easing access and easing naming, USE of Selection Sets would be enhanced. I find them very useful for alternating between multiple selections, but I hate the overhead of creating, naming, and selecting. This feature request (already made, but perhaps I should make a mockup-- wait, they're not paying me....) is meant to address the creating, naming, and selecting overhead.

Access to various lists in Modeler is BAD currently, anytime there's a menu I think it should be looked at very hard with a jaundiced, prejudicial eye. I hate menus, and the original developers used them very poorly in places they shouldn't be used. Replacing them with "radio buttons" (wish there were a better name) and lists would be a step forward in quicker access and "user discoverability".

++++++++++++

If the sdk allowed for non-modal panels one could maybe make this. I don't know if selection sets are available in the sdk.
Yeah, of course non-modality has been a bugaboo for Modeler plugin writers for forever.

Like pinkmouse, I don't use selection sets much so this is probably very low priority or something better served to be implemented in Layout. You can't multi select or filter layers in Modeler so there's a lot that a scene editor implementation for Modeler would address.
See, my theory is that Selection Sets, for ALL entities (p/e/p) would be used more if they were better done. If you had multiple opportunities to name/save a set, not just the one shot, you might avail yourself of them more. Also, Parts are a ridiculous hack, I'm wracking my memory here ( #aflw ) to think of a grouping that allows overlap in grouping of polygons (not Parts, not Surfaces, I guess w.maps, but IME selection via w.maps is always dodgy).

At the very least, consider this a sort of "Selection History Stack" which is what it is partly. Does that sell the concept better?

--This "selection auto-history" might be even more valuable for rigging, which tends to be very fiddly.

++++++++++++++

Case in point: I've been watching some older modeling tutorials, and every time the presenter needs to REselect some set of polys, I'm grinding my teeth. If only he could just hit a line in a window and have those polys selected instead of, once again, slowing dragging the mouse over the polys in question.

THAT'S what I'm trying to make faster.

Sensei
12-28-2015, 01:41 PM
I'm still curious as to why you need lots of selections.

See here
https://www.youtube.com/watch?v=j2ZjSKGJxqE

It might be useful while experimenting.

Some tools require dropping selection,
if you have complex model, you could have complex selection, taking minutes to set up.
You run tool, which is using selection,
then dropping it, together with selection,
running other,
just to find out, some polygons were missing in initial selection.
And have to undo,
and again select elements one by one, wasting time.

jeric_synergy
12-28-2015, 09:12 PM
Exactly, I just want it to be even smoother, since the creation would be automatic.

In my scheme, the user could save as few as, say, 10 Selection states, or as many as s/he desired. Whatever works for them. Only named states would get saved with the Object, just like Parts, and autonamed states would evaporate with Closing the Object.

pinkmouse
12-29-2015, 03:21 AM
Still really don't see the need for it, a revert to last selection type thing would be fine for me, but as LW3DG are changing the lwo format this time around to get rid of the IFF subchunk problem, they may well still be able to do something to save states/undos as well. Get a request in. ;)

jeric_synergy
12-29-2015, 09:16 AM
Still really don't see the need for it, a revert to last selection type thing would be fine for me,
That's just the "one level undo" issue again. @^@. :beerchug:

Anyway, I requested it long ago, just thinking about implementation.

--Wait, what's the IFF subchunk problem?

pinkmouse
12-29-2015, 09:18 AM
If you have lots of nodes in an object, it trashes the save.

Sensei
12-29-2015, 09:22 AM
--Wait, what's the IFF subchunk problem?

I showed in this video
https://www.youtube.com/watch?v=gzwtr9MNcFc

Global Materials (http://globalmaterials.trueart.eu) solves is immediately.

jeric_synergy
12-29-2015, 10:27 AM
If you have lots of nodes in an object, it trashes the save.
So, that's surfacing only, right?

What's "lots"? I've seen some huge networks.

Sensei
12-29-2015, 10:32 AM
Different nodes allocate different amount of space.
It's showed in video that I attached how much you need nodes to error to appear..
But if you would add envelope(s) to some node, with plentiful (baked?) keys, it'll be appearing much more often.

jeric_synergy
12-29-2015, 10:37 AM
Ugh. Sorry to hear about it: I hope many test cases have been sent to LWG.

pinkmouse
12-29-2015, 02:24 PM
They know all about it, and if you'd read my post above, you'd have known it was fixed in the next release. ;)