Hey @colin, I have another puzzle to for your clipping files. I’m putting it in corner bar because I’m not really looking for a solution, just curious about the phenomenon. This is a 10" cube with a circle on the top, made in a blank file. Using the move tool with the blue axis locked, I’m moving the circle up to distort the top surface. If I orbit via scroll wheel with the move tool still active, this clips like crazy. If I stop orbiting but leave the move unfinished, clipping stops, or if I finish the move, clipping stops.
I think you have found another way to get the geometry to go behind the camera. Why it doesn’t clip when you stop moving I’m not sure. But maybe SketchUp has more time to get it right then. I can easily get the same effect, and zoom extents fixes the clipping if it is still there after the move.
For whatever reason different logic seems to be used in Orbit tool vs other tools. I don’t know if it’s a heavier optimized code that is intended to make the camera movement smoother.
It does intentionally drop textures and other things if the model is complicated enough to give a low frame rate. But maybe it also always drops other things, such as clip detection (or whatever the right term is for the thing that would normally prevent clipping).
My theory is that the front plane of the camera fustrom is calculated to avoid “existing” geometry, and that the moving geometry does not “exist” until the move is finished. So the rising section of geometry is not included in the anti clipping calculations until the move stops and Sketchup recalculates the fustrom based on the new “existing” geometry. It seems to be the geometry in the act of being created that clips, geometry that is in limbo, not yet officially created by finishing the move.
However, if there is no orbit the same geometry is not clipped even if the move is not finished. It’s like camera fustrom recalculation is suspended while in orbit mode, and the last known model bounds are used until orbit stops. Normally we would not notice because the last calculation taken on the model just before orbit started would suffice to not clip the model during the orbit, but in this special circumstance the model bounds change after that calculating was made?
Admittedly, I am way out to sea here, one could write everything I know about clipping on the back of a bar coaster. Just speculating.
Of course, none of us who don’t have access to the source code (and OpenGL expertise) can’t do anything but speculate. But I suspect you are on track that it is an intentional optimization to avoid slowing down the orbit. For all we know it may be something that was done way back at the beginning but isn’t so necessary today when CPUs and graphics are a lot faster.
The one thing I would quibble with is that no new geometry is being created, all that is happening is that the transformation placing it in the view is being manipulated. But that manipulation can cause parts to fall outside the current frustum, which will lead to clipping.
Checking where the nearest geometry is would be a quite heavy operation I think. At least in the past it seems the far clipping plane (because there are always clipping planes; just that we don’t notice them when they work properly) is defined by the model bounds and camera position and direction, and the near clipping plane seems to be some fraction of this.
Maybe when the camera stops there is special handling that takes the geometry into account, but it doesn’t seem to be the best solution for clipping, due to its inconsistency when the camera moves.
