v23 - Realtime previews don't allow some edges to be selected

[Max]

I understand what you are explaining here but from a user point of view it seems like something that only creates more clicks.

I know! I really do understand that in these cases it's not ideal. I wish it was different, or that overcoming the nature of this was trivial to do. It's not impossible, but it certainly isn't worth it. I totally get that it sucks to have to toggle previews on and off to select geometry in certain cases.

Perhaps a way forward is to:

a) let you determine the default toggle state of previews (so you would turn if off)
b) make a hotkey that, while depressed, displays the realtime preview

So then your workflow is select as normal, perform a quick check (quick is relative), and then finalize the feature. Maybe this can be mostly overcome with some UX modifications.

 

[simonb65]

As a result, we prevent you from picking geometry in that circumstance.

Then please make that clearly known to the user by indicating this in some way.

 

[Max]

Then please make that clearly known to the user by indicating this in some way.

This might be something we can do. Perhaps hover text at the mouse. Or perhaps we can turn such geometry red. That is a good suggestion.

 

[simonb65]

Perhaps hover text at the mouse. Or perhaps we can turn such geometry red. That is a good suggestion.

The latter is more in keeping with current hover over visual selection methods. Maybe a 'No Drop' type icon (Red circle with a red line) as a sub-cursor indicator too. Either would be a great step forward.

 

[MilesH]

When we're in the chamfer tool, and we select the first edge (to get the right picture), the feature is immediately evaluated. All the consequences of the evaluation now exist. One consequence of this particular geometry change (the first of several progressive selections of the chamfer tool) is that another edge we want to select has gotten a new identifier. The edge's new identifier is predicated on the model change (the first chamfer, which is being previewed).

We cannot allow you to select the edge with a new ID as part of the same feature that caused the new ID to exist. That's the circular reference problem. As a result, we prevent you from picking geometry in that circumstance.

Fundamentally, ACIS evaluates things simultaneously. Realtime preview forces it to evaluate things progressively. This is fundamentally where the issue is. To do what you want, you need to make ACIS evaluate the selection simultaneously, which means you must give it both inputs simultaneously. This cannot be done with realtime previews on.

For many geometry cases, it turns out there is no difference in the result of a simultaneous or progressive evaluation, since geometry IDs that are important to you are not changing. But in some cases, there is a difference. In those cases, this is what you will see happen.

Thanks Max. I'm still having a problem understanding the difference between my example on the left which works and the one on the right, which doesn't. For the one on the left, I selected the horizontal edge first. For the one on the right I selected the vertical edge first and the horizontal edge became unselectable. For both cases, the edge ID changes? Or not? Both done using 3D Preview, of course.

 

[MilesH]

Perhaps a way forward is to:

a) let you determine the default toggle state of previews (so you would turn if off)
b) make a hotkey that, while depressed, displays the realtime preview

So then your workflow is select as normal, perform a quick check (quick is relative), and then finalize the feature. Maybe this can be mostly overcome with some UX modifications.

This would transform it, for me. It would be a workflow that was consistent.

 

[simonb65]

I'm still having a problem understanding the difference between my example on the left which works and the one on the right, which doesn't. For the one on the left, I selected the horizontal edge first. For the one on the right I selected the vertical edge first and the horizontal edge became unselectable. For both cases, the edge ID changes? Or not? Both done using 3D Preview, of course.

^this. It's this order selection that works fully one way but fails one edge using another that doesn't seem logical, even based on Max's description of what is happening internally, and is what I tried to highlight very early in this thread.

In the short term, the highlighting of un-selectable edges would be great. Longer term ... who knows!

 

[Max]

Here is what we're looking at internally for v25 on this, at least regarding visualization. Haven't talked about default toggle state and keyboard toggle yet.

Red edges represent "any edge that was created by virtue of the preview existing". Created can mean a new edge exists that wasn't there before, or ACIS has deleted and recreated an edge that looks visually identical but is not actually the same. Red edges would be highlighted in an optionally thick, optionally colored way that indicates unselectability.

Part of making them optionally thick brings in a new option for selected / hovered edges in general, making them user-definable thickness / color. This was a request elsewhere in this thread.

Edges that are bounds of faces created from previews are almost always unselectable. Occasionally, as we see in this example, other edges that do not touch the yellow faces can also be affected.

 

[simonb65]

I'm not sure the highlight around the preview face itself is really required. I know it adds complete clarity, but would also clutter a very compact and many many selected edges in a single fillet or chamfer feature (I wrote that thinking the highlight would always be visible) ... but if this highlight was restricted to only 'popping up' when you hovered over the edge (which I presume is the intended behaviour?), but for clarity, you don't explicitly state 'when' the highlight would be shown.

The #1 most important highlight here is on cases like the lower edge, where it isn't apparent at all to the user that the edge has been touched by the preview solver, with it having non modified faces on both adjacent faces.

I think this would help users greatly.

 

[Max]

The #1 most important highlight here is on cases like the lower edge, where it isn't apparent at all to the user that the edge has been touched by the preview solver, with it having non modified faces on both adjacent faces.

There isn't an easy way to distinguish in code between "stuff that should be obvious" versus "stuff that is probably unexpected". The real algorithm is "find all geometry that was created by operation X" In this example the chamfer is super obvious and makes intuitive sense that its edges should not be selectable, however it's not always that obvious depending on what you're doing.

Reducing the clutter by setting the line thickness to a smaller value would probably go al long way. Ex:



Will be up to you how you want to see it.

 

[MilesH]

......................................In this example the chamfer is super obvious and makes intuitive sense that its edges should not be selectable............................

Not to me

 

[MilesH]

I think it's an excellent idea to have the new edge highlighted though! Even if I don't understand why!