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.