Seems you are in Face selection Mode ?
Just click on an empty space for stop the Yellow enleighting or click on a face for valide your selection

Yes FP, I am of course aware of that, that's not the point.

Hi Pior,

> Has this issue been adressed/feature been added as of V3 or V4beta ? I am just getting back into MOI
> after purchasing the upgrade and I still find this flickering behavior to be extremely disorienting/distracting ...

Sorry no, it's the same as previous behavior. It hasn't really been on my radar since it's only been mentioned as a problem by just a couple of people over the last 12 years or so.

I'll see about adding in an option in moi.ini for the next v4 beta.

- Michael

Hello Michael !
Thanks a lot for taking the time to reply and following up on this, this is sincerely appreciated.

On the topic of user requests about preselection highlighting (or the disabling of it thereof) : in my opinion many users *think* they want/need a preselection highlighting feature, while in reality what they actually need is *some kind* of predictable behavior, conveyed in one way or another.

For instance : Maya has always been infuriating when it comes to selecting the component one hovers the cursor over, therefore users welcomed the addition of pre-selection highlighting because indeed it makes things easier to predict. And then when these users transition to Blender, they *think* they need the feature there aswell because sure enough it sounds like a useful thing to have - and this leads to countless user requests about this feature. Whereas under the hood Blender is doing an excellent job making sure that the selection behavior is always perfectly predictable, thus making preselection highlighting pointless.

I guess what I am getting at is : the ability to completely disable this behavior in MOI might actually make the program more enjoyable overall, even to users assuming that they want things to flash and flicker at all times :P If anything, the component prediction could also be conveyed by a subtle change in the mouse cursor itself, similarly to what happens when one hovers over a link when browsing internet pages. So in the case of MOI one could argue that preselection highlighting doesn't necessarily *have* to be materialized be a literal highlighting of the component.

Anyways - can't wait ! By all means hit me up if you'd like me to test drive any beta implementation of such setting, it'd be my pleasure to test it thoroughly.

Thanks !

Hi Pior,

> I guess what I am getting at is : the ability to completely disable this behavior in MOI might
> actually make the program more enjoyable overall, even to users assuming that they want
> things to flash and flicker at all times :P

I think that's unlikely - what's more likely to happen is that not having it will be ok for simple situations but the reduced amount of information that is being conveyed to the user will be a detriment to more subtle situations like trying to do a "drill-in" selection on an object that is small in size at the current zoom level.

> If anything, the component prediction could also be conveyed by a subtle change in the mouse
> cursor itself, similarly to what happens when one hovers over a link when browsing internet pages.

Sorry, no - it's a general design guideline for MoI to avoid changing the cursor shape. The cursor shape is considered to be part of the user's operating system and it's polite to try and keep it in its familiar shape.

- Michael

Hello Michael !

Regarding the cursor thing : oh of course, this was really just an example amongst many. Another example would be Topogun, in which the cursor doesn't change but a little L or R appears next to the pointer to inform the user that the upcoming selection will be either loop or ring (depending on the pointer sitting near the middle of an edge or near its extremities). But this example isn't a suggestion or request either as indeed ideally things should be as non-intrusive as possible, with the pointer being consistent at all times.

Going further, an argument could be made in favor of having three distinct selection modes : the current behavior (objects+edges+face, resorting to clicking multiple times to enter edge or face selection mode), but also : buttons and/or hotkeys for edge mode, and face mode. I do believe I would likely work much faster that way as I would know for sure that the app would only select faces or edges whenever I need it to (as opposed to having to click an object, and then having to click on any edge/face in order to finally be in edge/face mode). Put differently : if I am not mistaken, going to edge mode,to face mode, and back to edge mode currently requires 9 clicks. Whereas if there were shortcuts going directly to edge and face modes, it would be only 3 button presses + 3 clicks.

All that said, when it comes to MOI in particular I certainly see the usefulness of edge highlighting. I must say (and that's a bit of a different topic, related to how the detection of components actually happens under the hood) that even the highlighting doesn't fully prevent selection errors at this time, so there are probably still some improvements to be made there ...

Also, while we are at it : there seems to be an issue with face highlighting at this time, as sometimes it seems like small faces are not being highlighted at all when the cursor is over them (the surrounding faces get the highlight instead). But when actually clicking, the un-highlighted face gets selected.

Anyways ! As said, it would be my pleasure to test out the highligting settings if they ever make it into the V4 beta. Staying tuned, with my fingers crossed :)

Hi Pior, I understand that it seems like face and edge selection that you're used to in polygon modeling would apply here as well but NURBS modeling is rather different in overall usage than polygon modeling. It's not really a fit to try and make it behave exactly the same as a polygon modeling program.

MoI will definitely kind of feel odd if you're trying to use it with the same approach as you would in polygon modeling. It's not meant to be used in that way.


> Put differently : if I am not mistaken, going to edge mode,to face mode, and back to
> edge mode currently requires 9 clicks. Whereas if there were shortcuts going directly
> to edge and face modes, it would be only 3 button presses + 3 clicks.

MoI is actually designed to not need to use the keyboard for basic operations, so tying hotkeys into its main workflow is not really a fit for MoI either.

But it is possible though to set a selection filter that will then cause faces or edges to be targeted thereafter. You could do that by setting the following on a shortcut key:

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

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

You'll see the filters activate in the "Types" section of the scene browser.

You can press the Escape key to turn off the selection filter.


> Also, while we are at it : there seems to be an issue with face highlighting at this time, as
> sometimes it seems like small faces are not being highlighted at all when the cursor is over
> them (the surrounding faces get the highlight instead). But when actually clicking, the
> un-highlighted face gets selected.

I haven't seen that over here. Do you have an example model that you can post
that has this behavior?

Thanks, - Michael

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