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

[simonb65]

When filleting, for example, if you have real time preview enabled, then some edges of the model you hover over are not recognised (i.e no cursor change to show that your hovering over an edge) and the edge can't be selected as an edge to have the fillet applied to it. Can anyone confirm that this is fixed in v24.



However, if you un-check real time previews, you can select the edge!


Is this fixed in v24?

 

[bigseb]

No it isn't. Very annoying.

 

[simonb65]

What about displayed 'random' dimension text sizes? is this fixed in v24? ...

So small I can't actually read it, but its set to 3mm!



Maximise the window, then restore back to the original window size and BOOM! ...



It's the small unfinished stuff that just lingers on and on that really kills an application.

 

[Max]

When filleting, for example, if you have real time preview enabled, then some edges of the model you hover over are not recognised (i.e no cursor change to show that your hovering over an edge) and the edge can't be selected as an edge to have the fillet applied to it. Can anyone confirm that this is fixed in v24.

View attachment 34629

However, if you un-check real time previews, you can select the edge!
View attachment 34630

Is this fixed in v24?

Can you send me this part? I've never seen the inability to select edges. You can not unselect an edge with realtime on, but I haven't seen your issue.

 

[simonb65]

@Max , see attached ...

Edit feature 'Edge Chamfer 0.5mm'
Try hover over the edge shown in the previous post with both preview on and off.

It's not specific to this one part, it seems that 'inside' edges that already have chamfers at one or both ends show this issue. Changing the order that you chamfer edges does affect it, so it is due to the adjacent geometry change caused by the preview.

Its not just specific to this one part. Most, if not all, parts I've been making the last few weeks show this behaviour!

 

[simonb65]

Another one for you @Max ...

Vertex Chamfer on a 2mm thick base. With preview enabled, the edges of the chamfer are momentarily shown, then the Apply button goes red and the edges disappear ...



Without preview enabled ...



I really find it hard to believe that either yourself, your developers or QA do not see these basic issues, or hopefully you've all already seen this and fixed it in v24!

 

[simonb65]

If you hit Apply, you get an error ...



where the status is ...



and the shortage edge of the 3 is actually 2mm ...

 

[simonb65]

Entering 1.9999 allows it to not error ...



... but when you open the Vertex Chamfer dialog, its now set at 2mm !!



So it can say its 2mm after its rounded my input, but I can't actually enter 2mm!

BTW: Can there not be some visual indication on the geometry to show which directions are Distance 1, Distance 2 and Distance 3? It took a bit of trial and error to find the one to adjust to see if the error would go away.

 

[bigseb]

I have something similar go on with fillets. 1.99 works but 2 doesn't...

 

[HaroldL]

Here's another Fillet issue in v23. The edge is clearly listed in the dialog list, it just won't highlight or preview the fillet. IF RTP is turned OFF then the edges selected you get the original wire frame preview. THEN turning RTP back On with properly display. Hopefully this gets fixed in v24.
I've submitted to Support as case No. 00070444.

Here's the part file and a screen shot:

 

[bigseb]

Hopefully this gets fixed in v24.

It isn't fixed in the beta. Have this come up constantly.

 

[Max]

I really find it hard to believe that either yourself, your developers or QA do not see these basic issues, or hopefully you've all already seen this and fixed it in v24!

So the 2x2x2 chamfer fails in preview mode because the feature actually will fail. When you see a red apply button, it means the feature does not compute, because realtime previews tried to compute it and failed. Should it? Perhaps intuitively no. Does ACIS make it fail? Yes. We can ask them why, but it's not a "bug" of ours. I imagine it's a limitation, but it doesn't seem like it should be.

Regarding the other "issue", the act of previewing progressively populated features can be destructive in that what you select in a previous selection can have meaningful consequences on the availability of other geometry. For example, in the selection of Edge<1> for a fillet, you may have inadvertently (via the realtime preview) caused Edge<54> to become <Edge 99> after a geometry change. Edge<54> is what you want to select, but it no longer exists. Edge<99> isn't a real edge yet in that the feature has not been committed, so preventing you from selecting it is important to prevent a time loop and have the universe explode.

The edge may look the same to you, but in reality it may not be the same. In some cases, it's obvious when interrogating the geometry; in some cases the reasons are more subtle.

This is not a bug, it is a consequence of doing realtime previews. There are technical ACIS and autograph reasons why some geometry becomes unselectable. Realtime previews are good in a ton of cases, but they aren't perfect for every case. Toggling preview on and off as needed is the way it was designed to be used.

 

[simonb65]

So the 2x2x2 chamfer fails in preview mode because the feature actually will fail.

Why? If it solves without realtime preview, then the geometry is perfectly good and within bounds to solve the chamfer. So, I would expect the preview to come to the same conclusion. I wouldn't even be questioning whether the chamfer should fail or not. It fails, It shouldn't!

Does ACIS make it fail? Yes. We can ask them why, but it's not a "bug" of ours. I imagine it's a limitation, but it doesn't seem like it should be.

100% agree. If it is a limitation of ACIS, I'd like to hear that one!

Regarding the other "issue", the act of previewing progressively populated features can be destructive in that what you select in a previous selection can have meaningful consequences on the availability of other geometry. For example, in the selection of Edge<1> for a fillet, you may have inadvertently (via the realtime preview) caused Edge<54> to become <Edge 99> after a geometry change. Edge<54> is what you want to select, but it no longer exists. Edge<99> isn't a real edge yet in that the feature has not been committed, so preventing you from selecting it is important to prevent a time loop and have the universe explode.

The edge may look the same to you, but in reality it may not be the same. In some cases, it's obvious when interrogating the geometry; in some cases the reasons are more subtle.

This is not a bug, it is a consequence of doing realtime previews. There are technical ACIS and autograph reasons why some geometry becomes unselectable. Realtime previews are good in a ton of cases, but they aren't perfect for every case. Toggling preview on and off as needed is the way it was designed to be used.

I'm looking at this as a developer and as a user, and as a developer it makes sense as described (but very fixable), but as a user it's just a frustrating annoyance that shows as a 'problem/bug' with realtime previews.

Developer head : So if after a geometry change, Edge<54> has become Edge<99>. So, why is there now a mismatch for the between the UI (Edge<54>) and the current geometry data structure (Edge<99>) for the 'same' edge? Why isn't the edge on the UI (which is the one the user wants to select, now not referenced as Edge<99>? Is that a consequence of not updating the UI in line with the geometry data (for whatever reason!). Not sure why a 'time loop' is a factor here, but do you mean syncing the UI with underlying data? Do you actually mean potential circular dependencies? (which can be checked for and prevented)?

I would argue that, regardless of what the underlying 'index' of the edge is (due to being changed by altered by the realtime preview), there is still a visible edge shown and to me as a user it should be selectable. Now, I don't know if that's because of a shortcoming inside the ACIS or Alibre code, for whatever reason, but as a user that's a puzzle the developers need to solve. It's not unsolvable! At present it doesn't look good from the users perspective and just looks broken.

Strangely, if I select the edges of that opening (or other situations when it manifests itself) in a different order, then they are all selectable, so they are solvable!

 

[Max]

Why? If it solves without realtime preview, then the geometry is perfectly good and within bounds to solve the chamfer. So, I would expect the preview to come to the same conclusion. I wouldn't even be questioning whether the chamfer should fail or not. It fails, It shouldn't!

Simon, in literally the next post you showed how it does not solve without realtime preview. Realtime evaluates the feature just like pressing Apply does. If you see a red apply button, the feature is going to fail whether or not you are in realtime mode or not.

Developer head : So if after a geometry change, Edge<54> has become Edge<99>. So, why is there now a mismatch for the between the UI (Edge<54>) and the current geometry data structure (Edge<99>) for the 'same' edge? Why isn't the edge on the UI (which is the one the user wants to select, now not referenced as Edge<99>? Is that a consequence of not updating the UI in line with the geometry data (for whatever reason!). Not sure why a 'time loop' is a factor here, but do you mean syncing the UI with underlying data? Do you actually mean potential circular dependencies? (which can be checked for and prevented)?

The time loop part was a joke, but yes, circular dependencies. Which are...checked for...and prevented...by not allowing selection.

Strangely, if I select the edges of that opening (or other situations when it manifests itself) in a different order, then they are all selectable, so they are solvable!

If it works in an alternate order, then you have picked them in such a way that the potentially destructive nature of sequential picking and feature re-evaluation did not cause that edge to be reevaluated by ACIS in such a way that its index has changed.

I would argue that, regardless of what the underlying 'index' of the edge is (due to being changed by altered by the realtime preview), there is still a visible edge shown and to me as a user it should be selectable.

No, it should not. The modified edge does not exist in reality until the feature has been completed, unlike the other inputs that do exist before the feature has been created. Parametric CAD solves things in order. You cannot fillet a cylinder you haven't created yet - this is the analogy.

Now, I don't know if that's because of a shortcoming inside the ACIS or Alibre code, for whatever reason, but as a user that's a puzzle the developers need to solve. It's not unsolvable!

Look, this is just not as simple as you are making it seem. I appreciate you want it to work differently, but the idea that you know it is addressable and just a matter of us caring more or spending more time on it is not accurate. There are potentially ways to work around the issue, such as making ghost edges of the entire part that can always be selected and are offset and shown in a different color, for example. But you would see that and not like it either because it's a bad solution. We've thought through this; there is no non-trivial way to get this to do what you want. Perhaps by holding some key the part and new edges disappear and a wireframe of the part pre-feature can be shown with the original edges - something of that magnitude would probably have to happen.

Or, just toggle off realtime for a second. Would giving a hotkey for realtime toggling help? Like press spacebar or something.

 

[Max]

Here's another Fillet issue in v23. The edge is clearly listed in the dialog list, it just won't highlight or preview the fillet. IF RTP is turned OFF then the edges selected you get the original wire frame preview. THEN turning RTP back On with properly display. Hopefully this gets fixed in v24.
I've submitted to Support as case No. 00070444.

That is definitely a bug and should be addressable. Thanks for submitting.

 

[NateLiquidGravity]

This could be solved IF and ONLY IF ACIS has a way to determine what the previous name of a specific edge is. Then you could determine the original name of the edge as it existed before the preview and use that to add to the selection box and create a new preview.

Potentially IF and ONLY IF ACIS also had a way to determine what edge was used to create a fillet face you could let users click a previewed fillets face, then determine what edge is is associated with, and remove that edge from the selection box and create a new preview.

As of now - I have no experience with ACIS directly, so I have no way to know IF those abilities exist.

 

[Max]

This could be solved IF and ONLY IF ACIS has a way to determine what the previous name of a specific edge is. Then you could determine the original name of the edge as it existed before the preview and use that to add to the selection box and create a new preview.

Potentially IF and ONLY IF ACIS also had a way to determine what edge was used to create a fillet face you could let users click a previewed fillets face, then determine what edge is is associated with, and remove that edge from the selection box and create a new preview.

As of now - I have no experience with ACIS directly, so I have no way to know IF those abilities exist.

You are on the right track, but the solution set isn't that narrow. For example, to deselect edges a ghost edge of selected edges (a "proxy edge") could be shown. In fact, we had this before launch, but removed it because it was very ugly and "in the way". Then we made it togglable. But if it's togglable, just use the toggle realtime button.

So the solution sets involve getting novel with UI or, as you suggest, ACIS. I'm open to suggestions for a UI based approach - fundamentally it must allow you to see and select a "representation" of the previously selected geometry. But putting those up over every selection at some offset from the model does get cluttered quite quickly.

 

[simonb65]

Simon, in literally the next post you showed how it does not solve without realtime preview. Realtime evaluates the feature just like pressing Apply does. If you see a red apply button, the feature is going to fail whether or not you are in realtime mode or not.

That was referring to a vertex chamfer where the chamfer length matched the smallest edge length, which is a different math solving scenario to the previews you outlined that have geometry changes because of other elements in the preview. The vertex chamfer is a separate geometry solve issue, nothing has previously changed the underlying geometry being used to make the calculation. These two issues are not related other than preview was the key to discovering them.

 

[simonb65]

Look, this is just not as simple as you are making it seem. I appreciate you want it to work differently, but the idea that you know it is addressable and just a matter of us caring more or spending more time on it is not accurate. There are potentially ways to work around the issue, such as making ghost edges of the entire part that can always be selected and are offset and shown in a different color, for example. But you would see that and not like it either because it's a bad solution. We've thought through this; there is no non-trivial way to get this to do what you want. Perhaps by holding some key the part and new edges disappear and a wireframe of the part pre-feature can be shown with the original edges - something of that magnitude would probably have to happen.

Maybe you should pose the question to ACIS before making an absolute judgement on whether its a bug or not archivable. What happened to the 'can do' approach? Please don't dismiss a shortcoming before investigating it ... and I don't just mean asking your developer(s), they may just say no to avoid the hassle (maybe they won't, but I know many who do!).

If it can't be fixed, then you really need to let the user know why things don't work. Just leaving them thinking they've done something wrong or second guessing why it doesn't work intuitively isn't the best approach.

No, it should not. The modified edge does not exist in reality until the feature has been completed, unlike the other inputs that do exist before the feature has been created. Parametric CAD solves things in order. You cannot fillet a cylinder you haven't created yet - this is the analogy.

But non of the other chamfers in the Edge Chamfer operation exist in reality until you hit 'Apply', but they seem to get solved, created and displayed based on the edges you select in turn! Sorry Max, I agree with a lot you say, but that statement makes no logical sense. The Cylinder analogy is plainly inappropriate as the cylinder feature is separate and exists before you apply a chamfer feature to it!

If you have zero intention of perusing it, just say. Please don't say something isn't achievable without finding out if it really is or not. By that I mean pose the question to ACIS.

 

[NateLiquidGravity]

You are on the right track, but the solution set isn't that narrow. For example, to deselect edges a ghost edge of selected edges (a "proxy edge") could be shown. In fact, we had this before launch, but removed it because it was very ugly and "in the way". Then we made it togglable. But if it's togglable, just use the toggle realtime button.

So the solution sets involve getting novel with UI or, as you suggest, ACIS. I'm open to suggestions for a UI based approach - fundamentally it must allow you to see and select a "representation" of the previously selected geometry. But putting those up over every selection at some offset from the model does get cluttered quite quickly.

Perhaps show that "proxy edge" only when that edge is selected in the selection box. I understand that with Tangent Propagate enabled it gets even more messy.