The clipping plane issue is in my view by far one of the worst issues in SU. I want/need to be able to zoom in and work with tiny details like nuts and bolts in the foreground of my view as well as having a low res landscape in the background. Having to use external models or copy entities into temp models is cumbersome and not intuitive at all.
How close you can go to geometry before it gets hidden by the front clipping plane depends on the model boundaries. For small models you can be very close but for physically large models (e.g. those containing an imported DWG with many pages) it becomes a huge nuisance.
Even when editing an individual group or component with the rest of the model hidden the clipping distance is relative to the whole model. If the clipping distance can’t be set to 0, could it at least be relative to the bounds of the active entities when working inside a group/component with the rest of the model hidden? This would solve the clipping plane issues for any properly organized model and allow us to model those nuts and bolts regardless of whether the same model also contains a mountain range.
Based on the frequent posts here by people who struggle with clipping, this certainly seems like something that should receive attention by the development team. So far as I know, they have never publicly discussed when or by what logic the placement of the front and back clipping planes is determined. It would be very useful if the developers could provide some public comment on this question, and in particular whether dynamic calculations such as @eneroth3 suggests would cause unacceptable performance issues. If recalculating for every camera change would be too expensive, what about a manual reset option?
How big is the box? If you need to get the camera 10 times closer to it to work on some detail of its corner the clipping issue would kick in on 800 m already.
There is also the second kind of clipping that happens with Parallel Projection. When you zoom in and out, the picture plane gets moved inside your model. This, I think, is totally unnecessary, and happens, perhaps, only because Perspective and Parallel cameras are treated similarly by the application.
I’m not convinced this statement is true. If you look at the camera properties while zooming in parallel projection, you will find that it changes the scaling of the view frame in model units but does not move the camera (neither the GUI nor the Ruby API exposes the clipping plane location, but visual evidence as seen in the clip below suggests it also does not move). Changing the view scaling makes things look bigger or smaller, which creates an impression of nearer or farther, but that is not what is really going on! In parallel projection, because the entities project to the view along rays perpendicular to the view, camera distance has no effect on visual size! As a result, once clipping happens (usually as a result of orbiting, not zooming) you can’t get rid of it by zooming out.
By comparison, in perspective projection zoom is accomplished by moving the camera closer or farther from the model contents (again, you can verify this by checking the camera properties). Because the projection rays diverge, moving the camera also causes scaling of the view to change, but it is a consequence rather than the controlling factor. In perspective, clipping produces the impression that you have moved inside the model by getting too close to it. Sometimes that’s what you expect, but not always.
I think that in both cases the real problem is that SketchUp seems reluctant to recalculate the clipping plane location as you manipulate the view.
The clipping plane in parallel view is actually necessary. Zooming in parallel projection does not move the camera, only change the zoom/scale value. If you switch back to perspective you’ll see the cameras actual location and why the clipping makes sense. If the model weren’t clipped at the camera location you wouldn’t be able to use parallel projection when being inside an object, e.g. inside a room, only when you view the model from the outside. I think that is how the Maxwell renderer works which to me has proven to be a quite annoying limitation.
