Because I’ve used Shift+Z for Zoom Selection for as long as I can remember.
The same holds true for Z for Zoom Window
The bulk of my navigation in physically large models is via the keyboard.
Because it happens as fast as the GTX1060 can spit up the pixels.
Here you go…
Clipping for colin fixed.skp (19.9 KB)
Ok, so you removed the small edge that was causing the problem. Once again if you know what you are doing that is the normal way to fix one of the things that cause clipping, but it doesn’t fix the fact that that one edge causes clipping.
I’ve often used zoom extents for this but it then it pulls you back out from the item you’re zoomed in on to the extent of the model? So never thought of this as the solution.
Sketchup::Edge:0x00007fee983d44b8 was such a troublemaker!
My other fixes are to do with something that could happen to anyone with a normal model. Edges or text items an infinite distance away introduce all sorts of problems, and one symptom can happen to look like a clipping issue. Amongst the clues that something strange was going on was that I could delete the cube and still have an option to export a 3D model.
I won’t take your model as a defeat!
My zoom selection suggestion helps to work around that downside.
I’m not an OpenGL programmer, but I’ve often wondered if the z buffering entangles with placement of the front and back clipping. For example if you set them too far apart the z bins have to be coarser and that increases bleed through. Also whether recalculating the front plane too often causes a noticeable performance hit. No proof, just speculation…
I want to show what is causing the clipping problem for most people. I believe it happens because of an intended feature, that may have its own use case. But for most people it only causes something they wouldn’t want to see.
Should I tack that on after these 48 message, or start a new topic? If I’m right that it’s the most common cause it could help people trying to solve the problem, but the main point of the topic would be to decide if the originally intended use case should be dropped.
I believe you should post it here and only post a new thread in Tutorials once it has been shown to be correct.
Good enough, thanks. Post coming up…
Will try that, thanks.
I read a post earlier that pointed out that the position camera tool could be used to set which way clipping would be seen, and talked about how that is a bit like having a section plane that surrounds what you’re looking at. As you orbit the section plane is still in front of you.
Maybe it was done that way for such a use case, but I wonder if the clipping plane was originally needed when SketchUp was using software rendering. Having parallel projection and ignoring all of the things behind the camera might have been demanding, and starting by cutting off everything not in front of the camera position would have helped.
Since SketchUp 2017 you’ve had to have hardware acceleration, and GPUs know how to clip geometry. Other than my hypothetical section plane use case, I’m not sure if there needs to be a clipping plane anymore. At least not for making parallel projection be easier to achieve.
Here’s a video where I show two ways to get into a clipping problem, and two ways to get out. The ways in are to switch from perspective to parallel projection after using the position camera tool, or after zooming and panning yourself into the middle of the model.
The two ways to get rid of clipping are to zoom extents, or to use the position camera tool to set a position and direction, to effectively move the clipping plane away from the geometry. SketchUp could be changed to not have that clipping plane at all, that would fix this variation of clipping.
I think what you are highlighting there is the bug in the Position Camera tool, it always creates clipping with PP.
As a side issue many people use PP as a camera choice when modelling. PP is really only designed for elevations, plans etc when you want a 2D visual within a 3D environment.
I used the position camera tool as a solution, and for the case where it causes the problem, it’s no different than zooming and panning to the same place, it’s just quicker.
The general case is that if the camera is inside the model area when you switch from perspective to parallel projection, you will get clipping issues.
What do you think of the idea that the clipping plane isn’t needed at all?
I don’t really have any further comments on the subject.
In perspective every model generates clipping. Usually its too close to the camera to be noticed but not in physically large models. Try drawing a screw in a model of a house or a piece of furniture in a model of a block or an interior in a model of a city.
This is the only post I have ever seen that seems to analyze and understand the nature of the problem.
What interest me is whether other 3D CAD systems suffer from it. If they don’t, the obvious question is why not? How have they resolved it in a way that SU hasn’t?
I can’t remember having seen it elsewhere.
it happens in all ‘Prosumer’ openGL dependant 3D software that has a cross platform core…
Modo, Rhino, Vectorworks and others all have the same discussions on their forums…
it will vary on platform, cpu and gpu and software bias…
there is no one shot software fix for all possible combinations of these three elements…
intel drivers differ on mac and windows
mac is moving it’s UI from openGL to Metal
windows uses an openGL a wrapper around Direct X
Nvidia writes openGL drivers that break on Amd
AMD do the same
software bias isn’t necessarily deliberate but any compromises tend to favour the original port or the primary market…
hidden debug screen relies on DirectX functions to and isn’t available for mac…
john
Sorry Colin. I didn’t read it. Maybe that will help those on PC.
David