For the life of me I can’t understand why this feature (certainly in it’s current state) exists.
Can anyone, user or developer explain to me a use case that is beneficial.
All I see is a feature that appears to be set to On as the default that causes inaccuracy in geometry that wouldn’t occur if it was turned off.
If there is a use case that I am unaware of I would still suggest it be Off by default and come with a warning when attempting to turn it on.
Edit: I would appreciate @colin if you could ask amoungst your colleagues after the break to see if there is some reasoning behind it.
Pure guess on my part. If/when most of your work is rectangular, you start drawing with length snapping on, and precision set low - say to whole inches - drawing without typing in measurements could be quicker.
But in practice, once you get past that very simple scenario, as you say, it only begets trouble.
I know that Aaron often goes in to turn that off in his SketchUp Live sessions. There are other defaults that don’t make sense too, like having Edge Style/Profiles on by default makes performance a lot worse.
Maybe @MikeTadros or @Mark could drop by to talk about the length snapping in particular, or how to petition against current defaults in general.
Snapping and Profiles are useful when you’re first starting out and playing around with making shapes (people wont enter dimensions), then they quickly become annoying. Beginners might also set a custom snapping amount when creating setouts for blockwork or other such geometric arrays…but they shoudl be encouraged to use components in those cases.
I use snapping for large scale projects where I want everything to connect together…0.1m is my go-to setting
With snapping on you can create geometry a bit faster with the mouse, that you can group and drop in place. The problem is you have to be rigorous in sticking to your snapping , so you can’t use things like “divide eg” or inferencing. Really the two modes should be exclusive.
Basically I agree with you though…and I feel like length snapping needs to be turned off by default. A more useful type of snapping would a 3d grid to snap and align things to, with warnings for going “off-piste”
…Or , with snappng turned on, there could be some sort of alignment/guide mode (e.g. there could be a visible warning if your geometry or object isnt consistent with your snapping/grid setting or precision), for example if you divide a 1m line into 3 segments.
I recently was involved in a long thread that was in essence about the “lie” of SU creating a face despite the geometry being non-coplanar. Basically, my geometry was good enough to create a face–and it held for months–but not stable enough for the face to remain after I touched it with a minor edit. I immediately received advice in these forums to turn off length snapping and verify and correct my geometry. To summarize a very long thread, I got a ton of comments about why this happens and my errors of construction, but no explanation (other than SU’s math tolerances) why SU can’t be more helpful in avoiding these errors in the first place. Like the OP’s observation about length snapping, I wish SU wouldn’t “help” me by rewarding my bad geometry by completing faces just because they’re close enough. A warning or other feedback about modeling errors that are not visible to the eye during construction would solve a lot of the problems I see people posting about. (Please, no more lectures about “proper modeling technique”. While such advice is useful and educational, it’s only valid to a point). At some point, the programming needs to do its job. It’s like a car manufacturer who builds a car whose wheels tend to fall off, and everyone keeps posting that if people just learned proper lug nut torquing technique and avoided bumpy roads, the wheels wouldn’t fall off. Boom–operator error again! At some point of competency–and reasonable people will disagree exactly where that point is–the burden for proper operation of any tool or device shifts from the operator to the manufacturer. In this example it’s reasonable to expect that a driver shouldn’t have to learn special skills to keep his wheels from falling off.
If someone knows how it works and is aware of its all mistakes. If such a person exists. ( ! ? )
Most (beginner ?) people think of “length snapping” as jumping on a grid. However, it is actually more kind of a polar or spherical coordinate jump. The point is that the SU tries to keep the distance between the starting point and the current cursor position by jumping to the specified closest value.
And this is where the famous and mostly brilliant SU inference comes into play. Inference, i.e., “Snaps to vertices and other entities when the cursor is close to them”. (Quote from Ruby API InputPoint description.)
In my experience, these two types of snaps “interfere” with each other and don’t always “agree”. Most of the times the SU inference wins - as you’d expect. But not 100% consistently. There is a bit of a “buggy” implementation can cause inaccuracy in geometry. (See example gifs below.)
In addition, the appropriate explanation (documentation) also causes misunderstandings. This one also applies for Ruby API doc. It is terribly concise and there are errors in many places. You better do the examples yourself (trial and fail), rather use the documentation.
About a year (or two) ago, I made a plugin (ProLine) that tries to use a lot more snapping with more - but rather less - success. Looking at today’s eyes, I’m not too proud of it because the code is confusing, full with formal and logical mistakes and incomplete …
… but as you see the snapping implementation by talented developers are eider not perfect.
Examples:
As you’d expect: the SU inference take over the lead when it comes:
A bit flaws: as soon as you lock the inference (hold Shift ) the Length Snapping will fail if you are not close enough to “lock-line”. Note that: the cursor still jumps, as if “snapping” to the right place. But if you look at the Measurements box you will see that this is not true.
I think Length Snapping should be turned off in all shipped Templates.
I have it switched off in my own Templates.
I also recommend it’s off for other users…
However, Length Snapping does have its uses…
e.g. I wrote a commercial tool doing CNC panel layouts etc. When the user makes a panel they are asked to snap to start corner, after that programmatically the current length snapping [if any is remembered] and a temporary new one set up based on a setting value for a ‘module’ - typically 150mm. After the panel is made the Length Snapping is reverted to the previous set up. A temporary 2d graphic is draw to shown an orthogonal grid based on the ‘module’, so the user simply needs to click somewhere near a node and Length Snapping does the rest - there are secondary checks on the point clicked relative to the previous point, orthogonal and distance etc in case the user manages to fool Length Snapping, but it works pretty well, with only an occasional UI.beep and the clicked point getting ignored…
An excellent example Tig, but I imagine such an option is available within the coding. Such a specific usage should be able to be turned on by the extension. But you know me I know nothing about ruby, api etc
So the option should be available to the system and those who have a use for it, but not sitting in plane sight misleading people about what it does.
While testing length snapping I noticed too, that you get non-snapping lengths if you are some distance away from the inference locked line you are drawing. Should that be considered to be a bug?
If you are clicking to a point then the distant should be rounded to one of the increments that you’ve set e.g. 150mm, of course if your inferencing is not orthogonal or magenta it might not be what’s expected.
Hence with my extension I have extra checks of the picked point for its orthogonalness and distance from the previous points…
Calling it “Length-Snapping” is somewhat misleading - because picking some random point without any other snapping will [should] give you a point a set length-increment from the previous point, which is pointless unless the inference is orthogonal or magenta ?
Honestly, I’m not sure.
But I’d tending say no. It is not a bug, but may need more attention.
I guess the original developer was also aware of this. But she/he thought a “small warning” would be enough: As you can see in the animation when “snapping is not good”, the UI indicates this with a small red square.
It is a little hard to notice especially because no documentation or description can be found about it.
I really would like to know if you can confirm or deny the lack of documentation?
If there is documentation, I would also be interested in how long it takes to find it and how to do it?
OK, so what’s up with the red square? I could see it’s red but had to zoom in (because I’m over 60) to identify it as a square. And what shape is the black dot? Are there more variations, and is there a reference key somewhere defining the colors and shapes of these dots?
I wish SU wouldn’t “help” me by rewarding my bad geometry by completing faces just because they’re close enough. A warning or other feedback about modeling errors that are not visible to the eye during construction would solve a lot of the problems I see people posting about.
Yep…totally agree with you here.
Fixing errors is something i do a LOT when modelling (I do use a lot of intersecting planar geometry).
Extensions & functions such as:
Close all Edge Gaps
Flatten faces or Flatten Selection or Move to Z
Clean-up/Merge Co-Planar faces
Highlight stray edges…
Highlight non-planar faces
…These are used so frequently I have them hot-keyed!
SketchUp should absolutely have a mode where it takes care of the issues is or at least warns about it. The Axis tools (where it hightlights stuff that is on-axis) is handy but gets in the way a bit.
The number of hours (1000s) i have spent looking for little stray edges or correcting very slightly skew faces…i shudder to think…!!
Thanks for acknowledging this! I think many of the experts in these forums have become so skilled and disciplined at avoiding errors, as well as teaching others how to avoid them (which is appreciated), that perhaps they’ve stopped asking if such errors are really entirely the user’s fault or if the software is at least partially to blame.
It introduces errors, it’s widely misunderstood and confusing for newbies, it should be off by default.
The only time I productively use it is not for modeling but for object layout, in concert with the move tool. For example when testing different lay out patterns for tables at a large event I have set the increment to 10’ (legal required egress radius around a table) so I can easily move things around in a snappy grid. I have used it similarly to make exploded views of assemblies. Set the increment to say 1’ and move components away from each other in a controlled and fast 3d grid. These are both rare uses and could be easily accomplished in other ways. At then end of the day I think there is not much lost but a lot of headache if it were to disappear, or at least be made into a buried option.
Yes, starting with a snapping set to ½ foot or ‘Module based’ length could be useful at the start of something and get’s ‘in the way’ once the perimeter is set. The Scale figures used to stand to the right side of the origin and along with the fact that drawn lines on the Axes are not visible, one would alway’s start somewhere to the right from that origin, based on the picked pixelpoint from the screen, not ‘on the module or enabled length snap grid’
It always reminds me of Harmonica setting the footprint for McBain’s Station:
But the AEC industry has evolved and if Trimble would wan’t SketchUp to keep up, it should offer more realistic scenario’s.
These extensions are essential in my view, particularly with imported geometry.
With masterplanning work in particular where I’m dealing with site plans where nothing is square, if a face won’t fill it’s usually a small edge gap, stray edge etc. It used to drive me crazy before I had these extensions trying to track down the tiniest stray edge in a 20 acre site plan!
Snapping has caused me to have to scrap a few drawings and start over. My preferred measurement system is to design in English using decimals and then I toggle to fractions when I get ready to print plans and build. I’m a simplistic user, designing workbenches, power tool stands and cabinets with almost all geometry being in the 90° planes. Still, somehow I’ve gotten to “the other end” of a structure and found that there were misalignments. I can usually find and correct the problems but a couple of times the surfaces that were not coplanar were buried so deep inside a bench or table that is was easier to start over.
It’s way too easy. I’m doing basic construction plans and 90% is parallel and perpendicular lines. I’ve learned how to avoid most problems, but the software should be more helpful in avoiding mistakes–perhaps by offering different levels of detection and feedback. You’d think that the power of the program’s inferencing function could be harnessed for such analysis. For example: “It looks like you are completing a surface, but it is not coplanar. Click Fix, Redraw, or Ignore”. This type of feedback could be toggled on/off, and ideally would have multiple levels of resolution and options for detection. A good example of this type of user interaction is the formula helper in Excel–it catches and fixes most formula formatting problems (but can’t save me from my erroneous formulas! )
)