Why do Osnaps override Ortho anyway?

Rhino Rhino for Windows
,
21

Hi @wim
In youtrack also you commented about misbehavior of this new option.
dominant 45 degree ortho
This ^ seems… sorry… useless.

Mikko said: “The cursor location in relation to the snap location indicates which direction the point gets projected.”
… this seems hard to exploit, hard to make intuitive and consistently use, to me.
Simon and jim probably wanted something simpler.
Something like: “Always project the point to the closest ortho axis.”
But at this point I’m not that sure about this.

btw… I don’t need this. :face_without_mouth: … default Rhino works great here.

22

Hi,

I have to agree with the poster. I’m tired of the stupid tab and moving in the direction one needs thing and have been for years since there is not a modeling session where I am forced to use this over winded methodology.

I am maybe the first to complain about this going back years. It makes the ortho switch completely useless. I wish you would port it to V7as a plugin it would save me time and be more accurate than the direction tab method.

RM

23

I use the magic key Tab to lock the direction, which is pretty useful for snapping to other distant objects while keeping the movement locked in the desired direction. I have my Ortho turned on by default and I rarely need to disable it. Of course, this is just my use-case based on my workflow, so other may need a completely different approach.

24

Yes, exactly that, extremely simple. The way it is implemented now just makes this unusable, especially with 45° Ortho as you also found out.

But as I showed, it’s even more flawed because it will still sometimes snap completely overriding Ortho just as before and I can’t even figure out when or why that happens (at least before it would snap always, so it was more predictable). So either the new feature has bugs or it has been implemented in a way that’s unclear to me and definitely not useful.

Edit:

I can see that in such a case (Ortho always on and using Shift to temporarily disable it) you might find it slightly useful to have snaps override it (so that you don’t have to even press Shift*). But then you’re still unable to force Ortho in all those occasions where you actually want Ortho.

And also, I feel like this way, you’re basically using Ortho just as another SmartTrack guide (basically if you disable Ortho but make a smart point at the origin [which as far as I can tell, is actually always created, so why even have Ortho on?], it will also snap to it if you get close to the ortho axis but as it is just that – a snap – it doesn’t have priority over other snaps). But in my view, Ortho shouldn’t be just another optional guide, it really should force Ortho at all costs to make it useful and predictable.

Now I get that someone might not like changing this core behaviour because they somehow found it useful (I’m still somewhat baffled by it but that’s not important) which is why having it as an option is fine by me. I still feel like if you were testing new users unfamiliar with Rhino, most would agree what I suggest to be more useful than the current default but unless someone actually does this testing, that’s just a hypothesis.

Edit2: Now I’m curious – can somebody who has access to it check how this is implemented in AutoCAD? It’s been over a decade since I last used that program.

*Still, having to press Shift to disable Ortho is much, much less work than having to zoom out, Shift+Tab, check that you still somehow didn’t snap to a smart point accidentally created somewhere off screen that changed your direction by a minuscule hard-to-spot angle, then zoom back in.

25

When I want to disable the Osnap temporarily, I hold the Alt key.

I just tested your settings by turning off the Ortho entirely. Once I ran the “Move” command and dragged the selected object a bit, I held Shift to activate Ortho and immediately pressed the Tab key for a brief moment to lock the direction, then I released both keys. Pressing Shift+Tab for a half second does the job perfectly fine.

26

That’s not what we’re discussing though. In your case, you’d hold Shift to disable Ortho. In my case, I hold shift to enable Ortho. But other than that it functions the same.

Holding Alt to disable Osnap is only useful if you do not actually want to snap to anything (either because you’re entering the distance numerically or you’re freeform drawing/modelling). But most of the time, I want to snap or smarttrack even when I want to constrain to ortho angle, so I need both turned on which is where the trouble comes.

It does the job perfectly fine IF and ONLY IF the cursor isn’t near other geometry or a SmartTrack guide that will override the Ortho direction. Basically, you’re still running into the same issue. The only difference is, that since TAB will lock it, it is easier to find a place where you minimize the danger of an accidental snap (but that often means zooming way out and even that isn’t bulletproof if there’s a rogue smart point somewhere). You’d have to temporarily disable Osnaps while pressing Shift+Tab to be absolutely sure you lock the direction right. But try pressing Alt+Shift+Tab in Windows…

Edit: In fact, what I often end up doing is zoom out or pan to less busy place, hold Alt+Shift to see exactly where the ortho direction is, then release Alt, try to spot if the direction changed or not, if not, hit Tab, zoom back where I actually want to place the target point, snap to whatever I need and finally click. With what I suggest, I’d only need to hold Shift, find the snap and click without worry. I don’t get how someone can not see how much work and nerves this would save.

27

Sorry for bumping this again but can we please get an explanation from a developer how the WIP DominantOrtho advanced setting is supposed to work? As was discussed later in the thread, it’s not really clear and not just to me.

28

In my opinion, “Dominant orhto” must be a tickbox located next to all the Osnap tickboxes in the Status bar, which should make it easier to turn on and off.

29

:+1:

.. please no dominant ortho - users can use .x .y

30

Please stop derailing this thread with your unhelpful comments, thanks.

31

i think dominate ortho will only introduce new sources of errors, and will give us teachers one more details where there is no “standard rhino best practice” (use .x ) but to many options. this kind of variations will not make a program more accessible nor better.

that s the job of the moderators of this forum, to comment like this, not your job. and it s part of the wip development to discuss and also do do not like new features…

bring a sample workflow where dominant ortho is nesscessary.

32

Sure but the discussion has shifted since developers have actually implemented the feature in the WIP (in fact long before I even created this thread) based on other people’s requests. Now I’m trying to figure out how that feature is supposed to work and whether in has been actually implemented correctly. After that is cleared, then it makes sense to discuss whether that feature is useful or not.

And your resistance to changes has been noted, there’s no reason to keep repeating it as a reply to every new comment. That really is not helpful and it is diluting the thread with some sort of philosophical discussion where the important technical points are then hard to find. If I were suspicious, I’d even say you’re doing it intentionally to make developers less likely looking into this feature but I’m not going to make that accusation and assume you’re discussing in good faith.

Also, your convoluted workarounds are not a satisfactory solution in any way. The motivation was to make drawing/modeling faster and more convenient (and as a bonus, less error prone).

I have given plenty of examples of that in this thread, I’m not going to repeat myself.

On the other hand, no one has yet given me an example where not having dominant ortho is necessary, or even moderately useful.

33

maybe it s a mindmap / category / knowledge-map glitch:

In my brain snapping is the superior, dominant, reliable input. and its strongly highlighted with thickend lines / objects and text: [end] [int] [mid]

Modelling Aids are optional support, and might not help / might not be reliable. For sure everybody had a smarttrack-overkill moment. There is no Feedback (grid snap) or modest white lines as feedback.

If we introduce dominant ortho, why should we not also introduce dominant grid and dominant smartracks - it will mess up point input totally.

dominant / force ortho is possible with a partial point input or with a snap along a line:
.x
.y
_alongLine r1,0 r1,0 // for x
_alongLine r0,1 r0,1 // for y

moving / copying along a World axis is also possible with the vertical option. ( a macro to set the cplane, move, revert the cplane can create a move x move y move z ) command.

There is really a lot of constructions where there is “visual ortho”, but there might be productional or fitting tolerance of 0.1 or even 0.02 mm that look like orthogonal but are not.
There is also Circles that not align to world x-y, so their end / mid are not reliable - using [quad] is a superior.

My teaching and coaching experience for more then 10 years with many, many students and clients from different branches / industries tells me, that bad snapping is a huge source of mistakes for beginners.
I already see my students doing mistakes until i find out, that they’ve set dominant ortho because the have seen it in the forum or some youtube video…

visual ortho - that is technically not, is also hidden in many fonts:

image
image1299×960 29.6 KB

image
image1299×960 37.7 KB

if users still want dominant ortho, i would judge this as another vote for constraints - as vertical / horizontal is a typicall constraint.

my 2 cents

best - tom

34

There is definitely some disconnect between how we think about this, that’s for sure.

Sorry, I don’t follow. Snaps are literally under Modelling Aids

obrazek
obrazek632×537 24.1 KB

As well as here, Osnap is on the same level as Ortho:

obrazek

So in my mind the only question is what should be the priority order. And here I think the determining factor should be usefulness. Ortho taking priority over Osnap is more useful than vice versa. No one here has yet presented a use-case that would convinced me otherwise.

Now, how the feature should be implemented IF it is implemented is another matter. I’m fine with it being Advanced Option but ideally it should probably find itself in this context menu:

obrazek
obrazek342×225 5.7 KB

But currently, the most important issue is how the feature has been implemented in the WIP. Because I think it has been implemented in a way that is different from what I and likely other users wanted. In fact it seems to behave so unpredictably that I find it even less useful than the default state, making that option completely pointless.

So I’d really appreciate if a developer could chime in here. :folded_hands:

35

:100:

36

Sorry Tom, you aren’t making sense. You seem to be just lashing out with all sorts of irrelevant issues.

I have yet to read a single thing from you that answers the question that was asked as the topic of this thread. You seem to be doing nothing but trying to avoid the question.

As far as I’m concerned the fact that when the Ortho constraint is active and that constraint gets derailed when the cursor happens to gets close to a snap point is a bug. Its a mistake the Developers made when programming this function.

The thrust of your arguments seems to be that this bug should be kept because there are lots of ways the user can workaround the bug. But that same argument can be made for almost every bug report.

37

The intrusive nature of Osnaps really must be dealt with. It comes across a great tool that is as bad in intrusive nature as something like Copilot. It just takes over the shift mode and makes idiotic suggestions undr Shift, and that just isn’t acceptable.

The random snapping of items into utterly silly and often contextually meaningless locations owing to Osnap makes Rhino hard to use in this way.

To utilise 100% more digits on ones hand to send a command constraint should be a very clear intent sent to Rhino. I spend inordinate amounts of time needlessly fighting with Osnaps, and then I have to turn them off.

38

For what it’s worth, I have ortho default enabled (holding shift temporarily disables it), and I use TAB whenever I need ortho to override osnaps. This is the most natural and useful setup for me, but I fully support customizable options for other configurations.

39

How is that “natural”? Its just a workaround for a bug.

What would be the problem for you if Ortho just worked without having to use the tab key to make it work properly?
This is the question asked months ago at the top of the thread and people just keep jumping into this thread to recite how they deal with this bug but they never answer the question. Some people don’t even address the question they just talk about other off-topic problems related to Osnaps.

Edit:
Let me clarify what I’m saying:
When you hit the Tab key its not really a override of osnaps. Osnaps still work. What hitting the tab key does is turn on Ortho when its not working properly, but why should you have to do that? You already told Rhino you want Ortho on.

The alt key is what is used to turn off osnaps and the shift key is what is designed to be used to to turn Ortho off (or on). What is the benefit in forcing the user to hit the tab key to make ortho work?

40

Because most of the time I want osnap to override ortho, and using tab is about the quickest way to switch when I need to.