Length Snapping… is good. Basically.
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.