Hi Bravlin, yeah that is pretty flickery if you are using dark colors like that.

If you use a lighter color for your objects it should help to avoid that, using the regular default color goes like this:



- Michael

Yes brighter colors helps a little. But to tell the truth it would be greater if we have an option to somehow regulate prehighlight opacity.
Yes it helps to establish right components due mouse hover. But i guess it adds small calculation load and not everyone really need this surfaces prehighlight.
I remember the times when this type of a prehighlite was added in Maya. Lots of guys turned it off. I'm not sure how it warks in Moi3D but in XSI we used
raycust due MouseMove callback to get component under mouse coordinate and it was kinda slow on heavy models.

Hello -

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 ...

It's unfortunately up to a point where this is giving me something similar to motion sickness and I can barely use the app :/ (and no, I am unfortunately not exaggerating here ...)

Any suggestion welcome.

For clarity here is the behavior that I would like to avoid :

https://i.imgur.com/nsAkcVz.gifv

Basically I'd love to set up the software so that *nothing* ever blinks until I actually click on something.

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.