Annoying BUG with "Line normal to surface"

Check this video at the 2:50 minute. You will notice that the ! _Line _Normal command builds the line in a wrong direction which does not correspond with the surface’s normal direction. To make it work properly, the user is forced to either hold Ctrl+Shift while clicking on the target surface, or extract a copy of it preliminary.

Hm - if you preselect the face it ought to work - it you don’t then, the command considers the Brep as a whole so snapping to a corner where the three faces coincide is a crap-shoot.

-Pascal

In my opinion, this is still a bug, because the user is asked to pick a surface anyways. It’s against any logic that after picking a surface Rhino is still confused which surface should be used as an input for the normal direction.
Also, those who want to build the line normal to the vertical (back) surface, should simply click on it instead of the top surface. I wonder if the developers intend to fix this bur, or we will have to live with it forever? :slight_smile:

It’s unfortunate that the command works as expected in 90% of the time, but on rare occasions it’s inconsistent and leads to such unwanted errors.

Hi Bobi - as far as I can see either the user can be more precise by sub-object selecting an individual face - the current behavior - or the command would have to be changed to ignore polysurface input and constrain the cursor to the picked on face only, which would be a step backwards, imho. Or I am missing the point completely…

-Pascal

I could not replicate this bug. By the way, your video is very long and confusing.

Sorry to hear that 4:30 minutes is too long for you and confusing. I showed two alternative methods for building of 3d dimensions directly in the Perspective view between objects with random orientation. I was very specific in my original post about the exact time when the bug appears.

Hi @pascal , since Rhino explicitly asks the user to preliminary pick a target surface (be it a separate surface or as part of a polysurface) to read the normal direction from, it’s against any logic for it to use a different random surface behind the visible portion of the model as the target subsequently. :slight_smile: Polysurface surfaces should remain pickable, but since one of them is already selected by the user initially, the command should consider it as the target surface. It makes no sense to pick one surface of the polysurface, then place the “Line normal to surface” on a completely different surface.

Not to mention that this particular vertex shown in the video is shared between 3 surfaces, but no matter which surface is picked first, the direction of the “Line normal to surface” is always the same (horizontal), with no option to change it between any of the 3 input surfaces. Rhino should at least allow a convenient change of the normal orientation in those situations.

Here is the same file to replicate the bug on your machine:
Manual fillets in Rhino 7.3dm (382.3 KB)

Hi Bobi - if I specifically select a face, the line > normal uses that face. If I do not specify a face with Ctrl-shift select then any face on the selected object is ‘eligible’ as a face for the normal. In other words, Line > Normal accepts top level polsurfaces and lets you pick anywhere on that object to start the line. I think that is as it should be. If the pick drops through to a face on the back side, I can see that might need tune-up but to specifically constrain the cursor to a particular face, use Ctrl-Shift to select. Doesn’t that make sense?

I think what you are asking is that only the selected (clicked on) face shoukld be considered when the pick is not a ctrl-shift one, which is probably how it was before sub-object selection existed, I don’t recall.

-Pascal

Yes, I think that the surface that the user picks initially should be considered as the target surface, because this is the intent anyways. As I mentioned above, clicking on one surface and then build a “Line normal to surface” on a completely different surface does not make any sense.

It should work just like ! _Point _OnSurface where the target surface is the one picked initially. That makes the very predictable and eliminates any mistakes and will not force the user to preliminary press and hold Ctrol+Shift before picking the target surface.

On top of that, using the initially picked surface as the target surface leads to an advantage to plate the “Line normal to surface” on a surface edge while snapping to another (distant) object. This is possible with ! _Point _OnSurface but not with ! _Line _Normal (unless pre-selecting with Ctrl+Shift).

The inconsistency is what kills that particular command in the first place. It works properly in the majority of times, then it suddenly builds “Line normal to surface” in the wrong direction. That inconsistency happens on quite similar polysurfaces, which is also annoying.

I write all this from the perspective of a user who uses a 3d mouse with the left hand and being forced to always hold Ctrl+Shift to pre-select a target surface, because Rhino refuses to use the initially picked surface as a target surface, is a cumbersome workflow.

Hi Bobi - I both get and don’t get what you are saying - it seems to me the current behavior lets you have both possibilities - per face and per polysurface - easily enough.
Line > Normal prompts for the various types of objects it is willing to be normal to, not just a surface, but you can force a particular face, in effect the OnSrf osnap, by ctrl-shift selection. That seems predictable and controllable - I do not see a downside, what is missing?

-Pascal

You can also enable SubObject filter, so it only selects faces instead of polysurfaces. We don’t think this is a bug, and we believe it is working as designed.
If you want other behavior, you should be able to make a macro for what I just described.

While I perfectly understand your point of view, in practice nearly all users would simply pick the very surface they want to use as a target surface to build a “Line normal to surface”. I doubt that too many people will pick a wrong surface just to be forced to pick again the correct target surface they wanted in the first place. The current state of the tool forces the user to follow a more complicated workflow that requires to press and hold “Ctrl+Shift” just to make sure that Rhino won’t go crazy and build the line in the wrong direction. This is especially annoying for those who use a 3d mouse.

Anyway, I just figured out that the “IgnoreTrims=Yes” option actually does exactly what I was asking for, by limiting the selection to the initially picked surface. Not sure why the Help information does not mention that, since it’s a very important information. It only says the following:

IgnoreTrims

Surface trims are ignored. When the marker misses the untrimmed surface, the no-access cursor is shown.

Also, in my opinion the “IgnoreTrims=Yes” option should temporarily show the full border of the surface, even if it was trimmed and joined. Then, the user must be able to snap to that border. This is not possible at the moment, forcing the user to extract a copy of the target surface, then untrim it, then run the ! _Line _Normal command again.

@Rhino_Bulgaria
No need to set IgnoreTrims=Yes anymore.
RH-74224 improved how the normal line is drawn. Now it uses the cursor location to decide which surface is used to draw the normal line.

1 Like

I tried it, but it’s only fixed for Rhino 8 WIP. Thanks for making it work that way!
However, since I’m working on Rhino 7 now, I will stick to using the “IgnoreTrims=Yes” option, because it gives me far more predictable result. :slight_smile: It’s also quicker and more convenient that sub-object selection with Ctrl+Shift, especially while using a 3d mouse.

1 Like

RH-74224 is fixed in the latest WIP

1 Like