I’ve explained it live on the screen shot, but to try again here:
Above I have a wall group, 15cm thick, that is currently selected and in x-ray mode
I have added a construction line 15cm from the vertical edge of the wall
I want to draw a line from the bottom edge of the wall where the construction line intersects the bottom edge.
I approach that intersection with the line tool from below the bottom of the edge.
As I get near where I would think to expect an inference at the intersection with the construction line, the inference point picked up the inside corner of the wall on the far side of the group (I am in x-ray only to show the problem…this happens with or without x-ray on).
In my understanding of the inference system, this should never happen.
What am I misunderstanding? Is there a setting I have wrong?
I’m not sure this is helpful, but this never happened with 2017 and earlier. All versions after 2017 have had this “error”. It drives me to distraction.
In my experience, this sort of thing has always happened, but I agree that it can be infuriating. The usual fix is to zoom in close enough that you put enough screen real estate between the two points to allow you to select the one you want. And yes, scrolling back and forth is a nuisance.
SU seems to have a weighting to the snapping process. Some points have more gravitational “pull” than others. So if you have two close together, you cannot select the one with less pull without zooming in. This has been complained about many times before. Some people would like to see a means of choosing the kind of point you want to select but I guess it is not easy to implement.
Thanks Simon. It used to work close to perfectly in 2017. When the next version came out after that, I thought that it would be a small bug they’d work out quickly. Now, three years later, it still is a mess.
And, although I understand what you are saying in general, and I understand nearby points picking up the inference is a complex decision for the software to make, it should never pick something non-visible (behind the group). How would I even know what it is grabbing unless I go into x-ray? I think that should just not be possible and should be considered a bug (and from my simplistic viewpoint should be easy to fix). Am I missing something?
Sometimes it seems that SketchUp infers what you are trying to do based on the path along which the cursor approaches. It favors snaps it found near that path, including farther into the distance. If you hover the cursor over a nearer edge for a second, you can usually get SketchUp to take the hint. But yes it slows you down a bit, as does zooming in.
Just a thought, probably a rubbish one, but anyway…
Would it be possible to develop the system such that by pressing a preset key on the keyboard, you get a kind of magnifying glass in the area of the cursor? It would be similar to zooming in but without all the scrolling back and forth. It might be activated by the + sign and allow magnification in steps (one press = 2x; second press = 4x; etc) and using the - sign to reverse it.
Hover over with magnification is something you see a lot on the internet, though in this case it would also have to allow interaction so you can choose your point.
Is there for sure an intersection between the vertical guide and the base edge at the front? We’ve often seen claims where the guide appeared to be not in plane of another seemingly crossing guide or edge. Not saying this is the case here. Which brings me to the next point…
Can you share the file as is, the one you took the screenshot from?
What if you hover over the guide first (for a second or two) to let SketchUp pick up the “On Line” iniference first, and only then approach and pick up the desired spot? (that will only happen with true intersections though!)
inf.skp (163.0 KB) Thanks for your response. You don’t need my model, but I’ll upload one anyway. Just create a 3d group that is a “wall” (a rectangle with a bit of depth). It must be a group. Then put it in x-ray mode and pull a verticle guide on the front face but place it so that it appears just inside the far corner on the back face. You want the intersection of the guide and the lower, front edge of the wall to be visually fairly close the the back corner of the box…like this:
Now just start playing with the tape measure and it will pick up the inference off the back corner as often as it does of the front edge - with or without x-ray mode turned on. When it gets this close visually, it makes it impossible to be sure that you have the right inference point. So, you HAVE to zoom in just to make sure. Broken!! In my opinion, the inference should NEVER pick up from behind a solid. (Except in x-ray mode where it seems the proper behavior).
@EscapedArtist, I don’t seem to have any problem finding the right inference, even when front intersection and far corner endpoint are somewhat at the same location on screen. In that case I might lose the popup “Intersection”, but still, I find what I’m looking for, not the corner in the back, whether zoomed in or not.
Thanks for for your input. I’ve created a video to show what I’m getting. Could I have a setting wrong somewhere? Why would I have this behavior and not you?
SketchUp has an inference memory. Can’t remember the exact amount, but it could be five perhaps? Anyway, it’s useful for finding the center of a rectangle, you infer the middle of the side, and the middle of the end, and then you can home in on the center of the rectangle.
You’ve discovered what might be a very handy use case. There are times when you want to pick up on something that is hidden, and using Xray would achieve that. For many other people I think they will want to mark your video as being the correct answer!
For you, if you don’t want SketchUp to pick up on a currently hidden corner, don’t turn on Xray and then hover over that corner. It’s going to be remembered even if you don’t want it to be.
@EscapedArtist, that’s the key thing, SketchUp’s (rather short, as for amount) inference memory
Once you picked up the back corner endpoint in X-Ray and then switch back to normal mode, the inference engine still remembers that corner. Once you draw its attention away from that corner SketchUp looses its focus on that point.
It may even help to hover over one front (vertical) edge and then again over a front (horizontal) edge or even over the front guide for a short periode of time. That could be enough to next pick up the needed intersection of vertical guide and front base edge.
You need to breake SketchUp’s focus on that back corner. In time you might not even be able to find that back corner again in normal mode.
As @colin explained, remembering more than one inference location to ultimately combine them can be quite handy.
I really appreciate this conversation, thanks!! And, although I love the inference system as shown in that little gif posted above, I maintain that inferences should never propagate from hidden points (that is why there is x-ray). Here is another video that I think makes my point a bit stronger. Let me know if you can give me a use case.
I have had that happen where the guide is behind the face I want it on. First I thought it was due to the mouse position or the angle of the face in relation to the screen. A later up date to my video drivers has since cleared the issue.
It is still a side effect of the same thing that is most of the time a useful thing. A 2020 new feature is where the object you are working on becomes transparent so that you can snap it to geometry that is otherwise hidden from view, so although your example may not come up much, there appears to be demand to infer to items hidden behind the foreground item.
A feature request would be to have a key you can press that clears the inference memory. I didn’t yet find an extension that does that.
I’ll be interested to see if anyone else knows more, but there’s not much about the inference engine exposed in the Ruby API and I don’t think this can be done without it.
Can you give me any instance where you want a reference to that back corner where it is hidden? I don’t believe it could be used effectively under any circumstance. I repeat again that this is not a feature request, but a bug report. Having an inference behind a visual surface is not a usable feature.
Here’s a short video showing a use case for the new transparency feature:
This doesn’t argue against your main point, but turning off the ability to infer things that are out of sight could stop certain workflows. Having a preferences option where you choose to not be able to infer to obscured geometry would solve the problem for you, without preventing someone else from being able to infer to obscured geometry, for whatever reason they have for doing that.
