And how select something if nothing different appears on the screen ?

Hi again Michael !

Yeah I can definitely see how many users do find it useful. And that makes sense - in some cases pre-selection highlighting is quite handy, especially when things are being occluded. But as far as I am concerned I do find it to be quite a distracting visual effect because of how jittery it is : there are many different states (off, hover, selected ...), simply moving the cursor across a model makes its various components blink in and out, and so on. I suppose I would say that having the option to turn it off would be just as useful as the option to have it on :)

FP : I am not sure if this was supposed to be taken as a facetious question but I will take it as face value and will try to explain myself as clearly as possible. Preselection highlighting can be useful, but is absolutely not a necessity when it comes to selecting components in 3d space as long as the selection/component detection paradigm is reliable (and in MOI it is definitely very solid). Of course and as mentioned above there are some special cases (hidden faces) but in such cases the user can always rotate around the model, or switch to a see-through viewport style. And this can often be faster and more intuitive than hunting for a component with highlighting.

I would submit that the more comfortable one is with viewport manipulation and object selection, the less one needs visual aids like pre-selection highlighting. And if the program responds to inputs in a very predictable manner, then there is no need for visual aids/confirmation in the first place. Here is a clip showing component selections done on the components of a mesh, without any such highlighting :

https://www.youtube.com/watch?v=A-NxtQe_um4&feature=youtu.be

At this speed, having components blink in and out would be quite distracting !

Hi Pior, the problem with going so fast is it greatly increases the chance of making an error too. So in general I wouldn't recommend focusing on that so much. But if you feel that it suits your particular way of working I can certainly add in an option in v4 to disable the preselection highlighting.

Right now in v3 there isn't any option for it simply because nobody has ever asked to disable it before.

- Michael

Totally understood ! And best of luck for the development of V4, it's been really nice seeing the steady development of the app over the years.

Oh and, one last note about highlighting : this also applies to the UI ! If you look at something like Google Chrome, the highlight effect when hovering over bookmark icons placed in the bookmarks bar is really quite subtle (and it has a very faint fade in/fade out effect too). These two factors make the bookmark buttons very gentle to hover over, and this is also true of many UI elements in Photoshop, Windows programs in general, and so on. Whereas the highlight effect over the big buttons in Moi3d (and Fusion360 too by the way) is really quite strong - hence, similarly to the way the viewport can feel quite jittery when working fast, the UI can also feel "flashy" at times because of all the big buttons lighting up constantly when merely moving the mouse around. I hope this makes sense !

(As you can probably tell I am personally quite sensitive to this sort of stuff ! I can sometimes get mild motion sickness when something moves/blinks as a direct consequence of my input but not happening directly under the cursor, which is partly why I moved from Max to Blender for modeling. Blender allows the user to recenter the camera center of interest precisely at the current location of the 3d cursor, which not only allows for very fast navigation but also has the benefit of not causing me any dizziness :) But I digress !)

<< a facetious question

yes, a little! :)

From my point of view that is maybe missing is a sort of transparency...

Hi Pior, it's also very common in Windows programs to have a stronger button highlight effect as well, in Microsoft Office for example.

You can change this in your installation of MoI currently though, for MoI v3 you would edit the moi.css file in the UI subfolder and find the hover rule for a command button, it's currently this:

moi\:CommandButton:hover, moi\:CommandSplitButton:hover {
	border-color:rgb(153,158,161);
	background:-webkit-gradient(linear, left top, left bottom, color-stop(0%, rgb(237, 246, 249)), color-stop(30%, rgb(178, 223, 249)), color-stop(100%, rgb(237, 246, 249)));
}

If you remove the "background" line there then it will only have an outline highlight and not any background color change.

In MoI v2 the UI was structured a little differently, it's controlled by bitmap files rather than through CSS properties. In V2 you would need to edit the bitmap file CommandButton_mouseover.png in the UI subfolder to change the mouseover look for a command button.

- Michael

What is the syntax for keep the line "background" without use it ?
// ?
/* */
\* *\
...

Hi Pilou, one way is to rename it to an invalid property name like xbackground instead of background.

You can also comment it out, but for making a comment in CSS you have to put /*        */ around the comment.

- Michael

I have that ! (made xbackground:)
Seems that make no difference with before ?

Is it possible to comment out .htm code?

<!-- This is a comment -->

https://www.w3schools.com/html/html_comments.asp

- Brian

FP : The highlight effect on the command buttons is being discussed here. Disabling this effect has of course no effect on the preselection highlighting of objects.

Michael : Wow, the whole UI being driven by CSS is fantastic !! It looks very flexible, I see that there are even controls for button size, and it looks like mouseover even supports fade transitions (hard to tell what kind of fading transition/profile curve it is using though).

Simply knocking back the intensity of the hover states really helps already :
http://i.imgur.com/Lx3Uc09.png

(When the user put the cursor over a UI element, any highlighting effect applied to this element can be very faint because the eye is already looking right there and will be sensitive to even the faintest value change. I believe that the trend consisting of making big UI button flash with a lot of contrast is misguided UI/UX design practice : it looks good when presenting the program to a board meeting or during a tutorial, but for the end user it is not necessary. It does work great when controlling a UI with keyboard arrow keys or a gamepad though, like in Steam Big Picture, the Xbox dashboard, and so on).

Hi Pilou,

> I have that ! (made xbackground:)
> Seems that make no difference with before ?

Changing the background in moi.css will control the background for buttons in the GUI like on the bottom toolbar and side pane, not for 3D objects in the viewport.

- Michael

Aaaahhhh ok!
So it's for a relative confort of the eyes depeding of each user! :)

Hi Pior,

re:
> (hard to tell what kind of fading transition/profile curve it is using though)

I think you can control the transition curve with the -webkit-transition-timing-function CSS property , I'm not sure what parameters it takes though. MoI v3 uses an older version of WebKit and some properties like that were implemented before being standardized so it may have non-standard parameters. You may be able to find a reference to it somewhere online though.

MoI v4 will use a newer version of WebKit and should support the standard transition-timing-function CSS property I think.

re: fade-in/fade-out , the thing about UI animations like that is it makes the UI consume considerably more CPU cycles. It's fairly deeply ingrained in me to try and make the UI as efficient as possible and save cycles for things that have to do more intensive number crunching. But it's probably time for me to not worry about that quite to such an extent.

- Michael

Hi Michael !

Yeah I too believe that being careful and conservative about that sort of stuff it definitely a healthy way to go. And as a matter of fact a fading effect is definitely not a necessity since simply lowering the contrast between states already achieves a very similar end goal.

But all that said, having access to these CSS tweaks is certainly really nice, and without a doubt people will have a blast creating their own (edit : just saw that an editor was already available, awesome).

Best of luck for V4 again !

Just wanna say that this highlight is pretty flickery thing. And it's hard for an eyes. If it would have some opacity option it would be great.
I tried different type of lights, highlight color combination and style color combination. But it doesn't help much.
I can only suggest to use light preset called "Clay".

https://www.dropbox.com/s/2ofnx7j2x317i09/KCb2bnxayf.mp4

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.