tl;dr: When in parallel projection, Zoom Extents doesn’t actually zoom. Instead it moves the camera closer/further.
This is something between a bug and feature request. I’m working with huge models with tiny details so I often struggle with the near clipping plane. However I noticed that in parallel projection I can zoom in as close as I need without anything being clipped, so I added a keyboard shortcut for it.
Technical details about how it works:
In parallel projection the near clipping plane is still there, but scrolling doesn’t move the camera (as it does with perspective projection), it actualy zooms. That means if you move your camera eg. into a house using perspective projection and then change to parallel projection, the near clipping plane will still cut off the roof, but won’t clip details of the interior as you zoom in. (Which is very useful.)
The problem:
When I change to parallel projection, the view often zooms* out so that I have to scroll back all the way to the model. This should be possible to overcome using the Zoom Extents function (Ctrl+Shift+E), however despite the mouse wheel changes its behavior from moving camera closer/further to zooming, Zoom Extents doesn’t and it functions the same way it did in perspective projection. This means it moves the camera and the near clipping plane towards the model. This means the close details are often clipped off.
*) I know, the word “zoom” is technically incorrect in this context as we’re talking about two different types of projection.
Expected behavior:
Zoom Extents does the same thing as scrolling.
Actual behavior:
It clips off the model and wastes my precious 30 seconds every time I use it.
Though I’m understanding your problem I’m thinking that this maybe is the intended behavior. Other users rely on zoom extents to get rid of the clipping plane, while in your case you want to keep it.
I’m thinking that a completely different approach to this problem would be to fix the unwanted clipping in the first place, ie only clip what’s actually behind the camera, which would allow you to stay in perspective mode all the time even when working in tiny details. Switching to parallel projection to be able to zoom close is just a workaround for that issue.
For the record I’ve also struggled A LOT with clipping issues. I had to abandon my very first SketchUp project because of clipping issues after having drawn a huge landscape around it. Fixing clipping planes would be a dream come true to me.
Zoom extends extends the view of the actual Model, not the current displayed window’s extends. It is for this reason I use it a lot. For POI’s I rely on scenes , where Camera properties can be adjusted as needed and saved. A new POI is easily created with the zoom window tool in which you would be more in control of the clipping pane yourself , rather then relying on constant changing camera positions (orbit) , moving cursors and unpredictible scrolling of the mouse (zoom). Though the last is probably the reason why you would get this ‘unpredictible’ behavior , it might be that the software is doing ** exactly** what you want but is dependent on those , very inconsequent to reproduce , variables.
Use scenes to get the view that you want, disable scene-transitions to save a lot of 30-seconds
I would say it’s quite the opposite. There is no zoom in perspective, only moving the camera forwards and backwards. Parallel projection has zoom though that changes the size of what you see on the screen without moving the camera.
In perspective mode there are two ways to change what is shown on your screen: Moving or rotating the camera or changing the field of view of the lens. In traditional photography or filming only the latter is called Zoom. Paradoxically, in computer graphics moving the camera towards the target or away from it is often called zooming even if in camera terms it is a dolly movement or tracking.
As said, in parallel projection none of this makes any sense. In SketchUp, what using the zoom tools in parallel projection does is moving the projection plane. I would call this somewhat a functional bug, as it sooner or later leads to unintended clipping. We really wouldn’t want the projection plane to move. It would be better to use some other kind of method to make objects smaller or bigger on screen, as theoretically the position of the plane would have no effect whatsoever on that.
