Is there any way for Ortho and/or Planar drawing functions to exclude all other snaps that are unrelated to either the desired plane or angle of activity?
I’m fussing from memory (without specific examples to cite since I’m not on my computer), but drawing in 3D space is often an exercise in hair loss with snaps going all over the place, with or without Smarttrack. Users generally want to force either Ortho and/or Planar modes when evoked, excluding all else. However, this seems almost impossible to do.
The best secret to force directionality currently is using the Tab key, given the weak behavior of Ortho and Planar. Only took me about five years to discover this. Apparently, I should spend more time RTFM than trying to do work. ~Dave
Hi David- it’s hard (for me) to see how excluding osnaps in Planar mode can help much of anything, to be honest- perhaps Project, in OSnaps, in conjunction with Planar is what you are after? In any case osnaps can always be disabled or suspended without affecting Planar mode. I am pretty sure I am missing the point…
[quote=“pascal, post:2, topic:21963”]
In any case osnaps can always be disabled or suspended without affecting Planar modd.[/quote]
right, option key on mac will suspend… i’m thinking dave is saying he’d like ortho to be unaffected by any other snap than, say, Intersection if that intersection happens to occur on the same line/vector as the cursor is locked to.
?
or saying another way- if i have ortho on, an unrelated end snap somewhere in the model will override ortho and pull the line to the endpoint instead of remaining locked to desired vector.
?
As for Tab: does this help? Sometimes, but only if you can catch a tab moving in Ortho space before some snap drags you who-knows-where.
So if the answer is Tab, then the (rhetorical) question becomes, why even have Ortho?
Desired behavior of Ortho (without having to also use Tab) is that a snap should ONLY activate if it is along the vector one is drawing. When in Ortho, no snap should EVER permit a line to be created that is not in that desired vector.
While this request may seem trivial, it’s not. Picture complex, dense, irregular geometry over large distances. One believes they are drawing a new element orthogonally only to later find that it may be slightly angled due to a fargin’ off-vector snap that activated while creating it in Ortho.
Now imagine spending hours (or days!) building new geometry to be digitally fabricated based off this one base geometry which you were positive was Orthogonal–after all, that’s what the command says it does–but it’s slightly tweaked.
Not good.
(Wishing this example were hypothetical, or singular, but, sadly, neither is the case).
I think I agree with you.
I don’t work with Ortho on so I haven’t noticed this before and thus my agreement is based on a quick test drive of what is happening.
Normally one hits Alt (windows) to disable snapping (I think that is part of the answer for your issue) - when ortho is active this still works but apart from that, you can use shift to override the ortho direction while still being able to snap to geometry. So that seems to be OK. But, yes, snapping shouldn’t just override ortho.
Hi Dave - I see no difference in your example between accidentally hitting and accepting the wrong snap, with no Ortho involved, and hitting a snap and thinking you’ve got ortho. The problem is the same and it is much easier to notice (no Osnap flag) and to solve in the case of Ortho.
It might work, in many cases, to suspend osnaps during ortho, (and re-enable in a tab direction lock- another complication), but the underlying crowded osnap problem remains and we could be removing some useful behavior for some cases and some users. We’d have to think carefully about what the consequences are.
(It seems like maybe you work with many, or all, Osnaps on all the time- I personally think this is a bad idea, for the reasons you describe.)
Hi Pascal… Will try to find some time to create some useful examples and get back to you.
Any luck on figuring out snap specific aliases that we discussed a few days ago. This alone would make singular snaps while drawing far easier than the present method.
For reference, I do often work with End, Mid, and Intersect on. ~Dave
This issue did not get the attention and discussion it deserved. Logged as MR-2956 to make sure that it doesn’t slide off the radar as some items can. I would definitely like a simple test case where this can be demonstrated with very clear steps.
(Example file enclosed. The text below is also included in the Notes of the file.)
_Lines drawn in Top view
_Snaps On (Persistent: End, Near, Point, Midpoint, Center, Intersection, Perpendicular)
_Line desired from A to B; however, result is Line AC unless Project is activated — which is seemingly the ONLY way to get Line AB?
_Thus; ONLY Project works despite expectations that Ortho and/or Planar will work. Desired (and expected) behavior is that either Ortho or Planar should achieve desired results without the use of Project
One might say, “Well, just use Project”. Well, the reason Project is not practical (especially when drawing complex items) is that this requires moving the CPlane every time an Off-CPlane item is drawn (or measured). Sad!
DESIRED: The optimal (and expected) solution is for Ortho to lock new inputs (Shift Toggle is great here!) relative to the active construction plane upon which they are being worked (such as Top, Front, etc). This should also apply to items that are parallel to that CPlane (even if located above or below the Cplane). An example would be a line drawn in Top view from D to C.
SNAPS SHOULD NEVER ACTIVATE UNLESS GEOMETRY MEETS THESE ORTHO CONDITIONS!!!
(That’s where Smart Guides should be used — to show alignments that are NOT co-planar. Snaps should ONLY show up if Smart Guides is in use for non-planar geometry)
In addressing this issue, bonus points given if coincident points in front of the CPlane get Snap priority and are shown as the first item in a popup list.
SUMMARY: When Ortho is engaged, snaps would ONLY activate for items that are on the same plane as the start of a geometry (e.g Lines AB or DC) based upon the view in which they are being drawn. (This also includes items parallel to the CPlane in which work is being performed).
As for Planar — This does not behave as expected or described. See Layer “WTF? Planar”. In Top view, I want (and expect) to draw Line GH (which is on the CPlane). However, the result is Line EF. I believe that Planar could (should?) be deleted if Ortho worked properly.
In addition, because Project Snap also performs very similar (and powerful) functions to Planar (as it should work, not as it does), it could be argued that Project could/should be placed on the header bar next to Ortho (instead of Planar). The reason for this is that it would be HIGHLY visible when working, in case one forgets to turn it off accidentally. (Thinking here of very dense geometry situations where this mistake of leaving Project on accidentally can REALLY screw up a project)
Good luck with this! Fix this fundamental geometry creation problem and I will (mostly) stop complaining for a while.
~Dave