Hi Pior, actually for those selection filter shortcuts you would probably want them like this:

script: /* Turn on edge selection filter */ moi.selection.clearSelectionFilters(); moi.selection.setFilter( 'Types', 'Edges', true );

script: /* Turn on face selection filter */ moi.selection.clearSelectionFilters(); moi.selection.setFilter( 'Types', 'Faces', true );

These ones will clear any current filter before setting the new one.

- Michael

Hi again Michael ! Thank you so much for the follow-up, this is truly outstanding support.

I'll definitely do my best to recreate that one "tiny face" selection issue. I can't recall if it was in v3 or v4beta though, but I'll dig it up.

And thanks a *ton* for these shortcuts, this is exactly the kind of stuff I was looking for. I understand that it may sound like an attempt at recreating polygon modeling habits, but it really isn't - I am quite familiar with the differences between CAD and polygon modeling, and what I am struggling with here is not so much the MOI toolset but rather the noticeable barrier to "flow state" induced by the program being very click-dependant ... by default, that is !

To give you an idea here are the shortcuts I've been using, based on the ones you provided above but with a few more things added (deselection of whatever was selected before, and also grouping some object types together) :

Edge mode :
script: moi.geometryDatabase.deselectAll(); moi.selection.clearSelectionFilters(); moi.selection.setFilter( 'Types', 'Edges', true );

Face mode :
script: moi.geometryDatabase.deselectAll(); moi.selection.clearSelectionFilters(); moi.selection.setFilter( 'Types', 'Faces', true ) ;

Solids + Surfaces + Curves mode :
script: moi.geometryDatabase.deselectAll(); moi.selection.clearSelectionFilters(); moi.selection.setFilter( 'Types', 'Solids', true ); moi.selection.setFilter( 'Types', 'Surfaces', true ); moi.selection.setFilter( 'Types', 'Curves', true );

Deselect all :
script:moi.geometryDatabase.deselectAll();

Using these not only makes me faster but it also largely alleviates the preselection jitter because I am always directly in the mode that I want to be in. That is to say : even if I miss an edge click, I never end up in face mode meaning that the faces never blink in and out. It makes for a significantly more pleasant experience !

Can you make a little video of what makes these scripts in action ?

Hi Pior, you're welcome I'm glad that helps!

- Michael

Heya Michael - it definitely does :)
Digging a little deeper I would say there are two distinct things I personally would like to turn off :

- The preselection highlighting modes, on a mode by mode basis (for instance I personally don't think I'd ever need the object and face modes, but I could see myself still relying on edges highlighting as edge selection is naturally the most error-prone because of the very nature of these components being thin)
- The "click confirmation highlight" that flashes the components with a thick yellow overlay and then disappears when releasing the mouse. I personally don't see any reason for it at all since it is redundant with the component becoming ultimately selected. Now don't get me wrong, it is *very* good that something happens on clickdown as opposed to only later happening on click release, as such a late confirmation behavior leads to some 3d programs feeling sluggish. But I don't think that flashing the selection with a thick overlay has any use at all - might as well skip that step altogether and instantly showing the end result of the selection instead.

(of course I am aware that many users are used to the current behavior, so the suggestions above are really just suggestions for options in the .ini and not at all a suggestion to change the defaults ... even though I am convinced that it would look sleeker and feel smoother if that was the case hehe :D)

FP : sure thing, here's a short vid. I am in no way an expert in using the app of course but I can confirm that at least as far as I am concerned, being able to jump straight to edge/face/object mode makes me faster because it significantly reduces the number of clicks required. But more importantly, that way I never get concerned/distracted by faces or objects flashing in and out when my mind is in "I need to select this one edge" mode of thinking. Think of it like jumping from one tree branch to another as opposed to having to constantly climb down a tree and back up again.
https://www.youtube.com/watch?v=YpwZgQPVaZY

Also : c'est "a little video showing what these scripts do in action". "Faire" ne se traduit pas littérallement par "make" dans ce cas.

Cool little video !

If you want to win some time in loop selection edges you have this little script! ;)

script:/*Loop selection*/moi.geometryDatabase.selectLoop();

Ha, that's excellent, thanks ! This will indeed save quite a bit of time.

Hi pior,

> But I don't think that flashing the selection with a thick overlay has any use at all - might as well skip
> that step altogether and instantly showing the end result of the selection instead.

It may not have been useful for you so far but it has a definite use in various more complex situations.

Here are some examples where the selection flash helps convey additional information on the shape of the selected object which is not immediately apparent otherwise:



- Michael

Hi there Michael ! Thanks again for yet another follow-up.

I see I see ! Well, it could very well be argued that if the point of the flashing outline is just to allow for the hunting of occluded objects ... then a more "goal oriented" way to solve this specific scenario would be to let the user switch to a transparent or wireframe display, as such objects would become instantly identifiable without even any need for marquee gestures.

... but of course I am just pushing the counter-point just for the sake of the argument here. I definitely understand that if this feature is here it is for good reasons (and no worries, no need to detail each and every uses, I obvisouly take your word for it.)

My point is more along the lines of : given the fact that there *are* workflows that do not rely on it at all, and also considering that this visual feedback can very distracting for some users (definitely not all of course, but some), then it would make sense to have an *.ini option to disable this feature if so desired by the user.

Here's a video edit taking it out. Of course the video would be more complete by also comping out the pre-selectoin highlighting as per the original topic of this thread, but that would get pretty involved in terms of masking :D

https://www.youtube.com/watch?v=LE1pjkb8V_E&feature=youtu.be

The point I am trying to make here is that visually speaking the UX experience becomes much smoother and relaxing once this very high contrast element is taken out. (On a side note I'd be willing to bet that sensitivity to this sort of stuff is likely related to things like motion sickness, as the dizzyness I get from this flashing is really quite similar to that. It also somewhat reminds of the feeling of discomfort I get when some games do funky stuff with their camera motion.

Hi Pior,

re:
> Well, it could very well be argued that if the point of the flashing outline is just to
> allow for the hunting of occluded objects ...

As the video shows it's not about only that. It shows 3 different cases only the first of which is for an occluded object.

It helps to give a general ability to see more information about the object's shape and if pieces of it are sticking off in unexpected areas that is very helpful with trying to understand what's going on with more complex geometry.


> My point is more along the lines of : given the fact that there *are* workflows that do not
> rely on it at all, and also considering that this visual feedback can very distracting for
> some users (definitely not all of course, but some), then it would make sense to have
> an *.ini option to disable this feature if so desired by the user.

I'll see about adding in an .ini option to disable it. Just be aware that by disabling it you will be reducing functionality for some use cases.

- Michael

Hello Michael ! Well, you can be sure I'll be eagerly waiting :)

On a side note I've been trying to reproduce the preselection highlighting inconsistency mentioned earlier. I remember it happening in face mode but somehow I haven't yet managed to reproduce that (and maybe my inability to do so could be related to the fact that I use direct filters for edges/faces/objects as opposed to the default "hybrid" multiselection mode). However, I am able to reproduce the issue consistently in object mode. See this clip :

https://www.youtube.com/watch?v=CB51iNfokps&feature=youtu.be

What this clip is trying to show is that there is some sort of a deadzone behavior (around 5 to 10 pixels or so) going on in object mode in this instance , within which the program is not picking up the correct object to highlight under the cursor. However the expected object (that is to say, the one under the active sharp tip of the cursor) does get selected upon click. There seems to be no such deadzone in face mode, as faces get highlighted precisely under the cursor tip consistently with the later performed selection click.

Now of course at the end of the day this doesn't really bother me (since, of course, I am not paying much attention to the highlighting in the first place hehe) but it looks like there is definitely a "false negative" going on here and it can be mildly annoying at times when working fast, as it introduces a split second of doubt, so to speak.

- - - - -

Also, while on the broad topic of selection : I think it would be nice if the app could search/raycast for edges from a much bigger distance. Blender is excellent in that regard, casting the search from very far away with very consistent results and that makes edge selection extremely fast (as the user task is not "I need to click close to this edge to select it", but instead it becomes "I need to click somewhere on screen that is closer to this edge that the other edge, but it doesn't have to be right next to it").

https://www.youtube.com/watch?v=dBvPKFbDIQY&feature=youtu.be

Very interesting stuff imho ... but probably another topic altogether. And of course this is a very unique case anyways as I believe Blender is the only 3d program out there doing such intricate/complex/delicate component detection. It sure feels like a world of difference though !

I hope this makes sense !

Hi Pior,

re:
> However, I am able to reproduce the issue consistently in object mode. See this clip :

There isn't really an "object mode" in normal MoI operation. It looks like what you're seeing there is a side effect from having selection filters active. Edges and curves have priority for hit test targeting and that I think that zone is where the edge is being targeted initially.

I can probably tune that up, I'll take a look. This sort of thing can kind of crop up fairly easily when you're trying to set up MoI to operate pretty differently from its normal behavior. In this case it's about having selection filters on all the time during regular usage instead of only for helping a particular targeted selection which is what they were initially designed to be used for. It's like you're going "off the beaten path" and you're more likely to run into branches that will poke you here and there.

It's also why it is not always so great to have a zillion different kinds of possible behavior configurations. It becomes hard to test and refine such things. Earlier in this thread you were saying basically "why not have an option in moi.ini to make it do this different thing"... - but this can be a reason to not have that type of stuff.


> Also, while on the broad topic of selection : I think it would be nice if the app could
> search/raycast for edges from a much bigger distance.>

In MoI v4 there is an option you can set in moi.ini for increasing the distance:

[View]
SelectionHitTestRadius=12

- Michael

Hello Michael - this makes complete sense ! Indeed, it's definitely the edge being "pre-picked" under the hood sice it is consistent with what I am getting when all filters are off. At the end of the day in my case it doesn't really matter much anyways since the actual click picks up the intended object anyways - I just have to ignore the "un highlighted" status, so to speak :) And yeah, I totally get what you mean about this kind of deep dependencies and what happens when twisting things outside of their default/intended uses.

The selection distance setting seems rock solid ! I already more than tripled it so far and can see no ill effect whatsoever. I'll probably stick to around 20pix or so, that seems like a good middle ground. It's a great time saver as it allows to think of and operate on selections in a more fuzzy, rapidfire way. Only downside being that it causes more "false negatives" on preselection highlight, but as said I am training myself to ignore that anyways :D

Hi Pior, I've been able to fix up that "edge dead zone" selection issue when filters are active for the next v4 beta. Thanks for reporting it!

- Michael

Ha, that's excellent !
Looking forward to it - and good luck with the development.