Orbiting make the model disappear

Hi,
I’ve found an issue where the 3D Model disappear when I use the Orbit Tool to turn it 360 degrees. The model comes to a certain point and the drawing area becomes totally blanked.
I’m working a MacBook Pro with Mac OS High Sierra.
Anyone having the same problem?

BR paf

You are dealing with the clipping plane issue.
See if this article helps: Clipping and missing faces | SketchUp Help

Thank you!
I’ve been away for a while.
The zoom extents did help me. A defined point far away from the model was disturbing the view so I could only see 3 sides of the model. Deleting the that point was of great help. In fact I don’t know how it came there.

Thank you again for your time

Kindes regards paf

Also orbiting around in perspective view can cause clipping plane issues. You can set up a key command to switch between perspective and parallel projection. I often orbit around in parallel and then switch to perspective once I’m roughly where I need to be.

Zooming extents does indeed remove the effects of the clipping plane, but doing so is a royal pain in the rear when you’ve just spent a tedious 5 minutes finding the area in a complex model that needs adjusting and merely want to rotate the model a little to see the region from a different angle.

I suspect the clipping plane and the wonkiness of the orbit tool (that often seems to select some point off in another universe to pivot about, instead of, say, the center of the screen? Hmm?). A work-around for this glitch is to plant the orbit tool on some part of the geometry and crossing all the rest of your fingers and toes in hopes that the pivot point for the orbit is that object, and not out at the L3 Lagrangian point.

It might pay off to use ‘Previous’ (view) and then save a scene from that and start from there.
Update that scene from time to time to make life easier in cases as you described.
Especially when zooming in have that extra (temporary) scene that you update regularly during the process of zooming in.

Although there isn’t a menu item to do this, a right-click option is to Zoom Selection. If you can see the tiny model part you were working on, and can right-click on it, you can zoom to the point that it fills the view.

@Wo3Dan: This helps the problem how?
Workflow: Some face is corrupted. It’s an easy fix, but to do so, you gotta zoom way in to the place where that ~0" line segment needs removed, or whatever. That place is way in the depths of a unique assembly (not a component, because I’d fix that at the component level). I need to do this ONCE, thankfully. But in the process of doing this one-time fix, the dang clipping plane rears its ugly head and wipes out half of the geometry that you really want visible as reference to where you are in 3D space. Yeah, saving a scene for this situation is kludgy, IMHO.

As for the orbit glitch, I DO use previous view, and have a hot key assigned for that. But it is a hiccup, and it does NOT solve the problem that the orbit tool’s pivot point is not where you think it should be.

FYI, I usually model stuff in parallel projection, often perform these fixes in wire frame. The orbit thing isn’t as bad when working in monochrome, because the tool “finds” a plane, often, to set its pivot on. At least, that’s how it seems.

@colin: Yep. That’s a thing one can do. But I most often find myself in this dilemma while using the tape measure, or push-pull, or some other tool that doesn’t directly make a selection for that context menu to work on. And I don’t always want to see JUST the ~0" line filling the screen. :slight_smile:

Also orbiting around in perspective view can cause clipping plane issues.

It was my understanding the opposite was true.

I find that working in ‘Perspective View’ is less susceptible to clipping than ‘Parallel Projection’. But that may be just my experience.
I’m not saying that you don’t have a point in that orbiting and zooming in can be a pain as to the clipping issue. Not at all. But in stead of being thrown back “ten views” I made some suggestions that reduced it to maybe one view back. I don’t know your work flow and your level of experience and thought it might help you (or others) in some way.
To tackle the issue as you described needs a specific example that I could look at to see how I would tackle it. There is not just one way that always works 100%. I’ve (in the passed) looked at “simple” ruby script on youtube, written by Chris Fullmer. Small alterations I made to it allowed me to find and delete very small edges, ~0.01" or so, somewhere in space, to delete them.

I find that the orbit tool very reliably pivots around the curser position on the geometry. If the curser is over empty space when you click to start your orbit then it will orbit around that distant point. If it’s over a piece of geometry in your model then it orbits around that point. This is the predictable consistent behavior of how the tool works. I’m not sure I would call that a glitch. But until one starts being intentional about where you start your orbit I understand it can feel surprising.

1 Like

As long as the “geometry” is an edge.
Using a mouse (not such an obvious idea–sometimes I’m forced to use the stupid finger pad on my laptop), I want to check the dimension of an object. But to accurately get to one end of it, I need to zoom in. In so doing the other end of the object is now off screen. I can, as @Wo3Dan suggests, zoom extents…but then I lose anything meaningful in the spaghetti of geometry. If the clipping plane hasn’t hidden what I’m after so that I must start over, I use the pan tool, or perhaps orbit tool, to locate the desired end of the object. Pan works just fine. No complaints. But orbit often as not swings the pertinent geometry completely off screen. I don’t believe I’m talking through my hat, here: I’ve made many tests to discover that if the orbit tool is not exactly on an edge, if the orbit tool is on a face or surface, the pivot point is at some obscure undetermined point in space. To pan, I hold down the shift key and middle mouse button. To orbit, I hold down just the middle mouse button. I often use them rapidly and alternately to move quickly about my model. To have to worry about previous view or saved scenes or whether the cursor is exactly on an edge is glitchy. It slows things down and is just another of the little niggles of SU that make many folks dislike it. Do not get me wrong: I love SU. I just think this is something that needs a look-at by the developers.
Thanks.

Huh, I find that the orbit tool locks to any face or surface pretty easily. If I had to find an edge to rotate around every time I wanted to orbit I would be frustrated too.

Now Clipping is another matter entirely, it’s super annoying and a real problem when trying to navigate and work on smaller things within a larger model. And, once clipping rears it’s ugly head then there is no geometry in the foreground to lock to, so orbit becomes pretty useless anyway. I would love to see some future development on widening the display range to give us bigger and smaller things simultaneously. Down with clipping I say.

But I’m curious about the behavior you are seeing, you need to find an edge to orbit around every time?
Does the orbit arc not adjust depending on where you start the orbit? Even on a surface, like this?

I’m beginning to suspect that it’s a graphic card issue, and not SU, necessarily. But I experience various degrees of the wonkiness on my laptop (Lenovo something or other) and my Win7 64 bit machine with an Nvidia something. Right after your earlier response, I did a test and couldn’t get the orbit tool to find ANY other point than the one it decided I should use. I sure don’t see behavior as exhibited in your brief video.

Yes the problem is definitely a greater issue while working on a small region of a large model. But if that’s not easy, then the program isn’t as elegant as it could be.

I seem to recall that AutoCad (back in the days when I used it exclusively) had some way to define or defeat the clipping plane. Not only that, there were two of them, one “in front” (between model and viewer) and one “behind” at some designated distance. It wasn’t all that useful for what I did; so I enjoyed the option of turning them off. In ACAD, it was possible to zoom from the orbit of Pluto to my house on Earth seamlessly (crazy, but it could be done), and without chopping Jupiter in half on the way.

Ooops - yes, you are right. I didn’t force the error before posting but the solution still works, just the opposite way around :slight_smile:

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.