Hello!
I’m having major issues with Rhino clipping objects like shown in the images below. I’ve used zoom select and the zoom commands to fix this super temporarily but the moment i zoom in again, this occurs. Is there a setting for this? Please help as it’s making me have to zoom select every single move and is very annoying. Thank you so much in advance!
Yes, I get this all the time as well. It seems to be a massive limitation of how Rhino deals with a mix of small and large geometry that are visible in the viewport. If you hide the larger pieces of geometry and only display similar sized geometry you probably won’t have a problem.
It’s very annoying/limiting and wish this could be fixed asap.
Yes, hiding the large context geometry is the right call and currently the most practical workaround.
The near clip distance is driven by the ratio between the closest and farthest visible geometry in the scene — the bigger that spread, the further out the near clip gets pushed, which is what cuts off your close-up objects. Reducing that spread by hiding large context pieces gives the depth buffer room to work properly around your detail geometry.
ZoomTarget can also help — placing the camera target directly on the area you want to work in shifts the clipping balance in your favor. And if perspective isn’t essential for a particular task, switching to parallel projection avoids the problem entirely since it doesn’t use the same depth compression.
Is there a reason why the near clipping distance can’t be set to something very small by the user and kept there?
Good question. I’ll assign this to a dev and see what the constraints are.
Please provide an example that demonstrates what you’re seeing… pictures don’t really help me here. When you run across situations like these, it’s always good to run ShowCamera and then look in the other views to see where (and possibly why) the near and far clipping planes fall the way they do… as you rotate the view you can watch in the other views as the camera icon/frustum updates in real time… If/when the near plane jumps further away than you think it should, then something in the frustum (or not in the frustum) can usually be easily identified. Note: HideCamera will turn off the icon.
Manually setting the near plane is not a solution… you’ll just be introducing more problems elsewhere. You can’t just pick arbitrary values because you think they’ll work, or that you somehow can pick better values than Rhino… It all has to do with depth buffers and depth buffering… The precision of the depth buffer is not linear, and most precision is kept close to the near plane. If you just change that because you think it’ll solve the problem, then you’ll most likely be impacting everything else in the scene that moves away from the near plane. Things like meshes/wires and z-fighting will all now be a lot more sensitive and prone to error, especially if a very small value is allowed for the near plane and at the same time a large value is used for the far plane.
Yes, a small value will definitely prevent things from getting clipped near the camera, but it will introduce all kinds of errors elsewhere as mentioned.
IMO, the best (only) solution to this is to allow some kind of bounding volume to be set (i.e. set both near and far planes), and only draw things within that volume… And if you set near to be really small and far to be really big, thinking “that should cover everything and just work”, then you’d be mistaken, and you will immediately see the problems it produces. Other programs do allow for manual setting of the near and far planes, placing the onus on the users…meaning, if/when problems arise based on improper values, then it’s up to the users to fix it… Rhino just has yet to add that type of capability.
A long time ago I wrote a plugin that provided a suite of camera tweaks (CameraDoctor I think is what I called it)…which allowed for this among other things like fog… but very few people picked it up and it fell into obscurity. It wouldn’t work in today’s pipeline so please don’t go looking for it… I only mention it here briefly because if this seems to be a recurring problem with the things you model and how you model, then I can revisit at least the near/far clipping settings and possibly provide ways for you to set them…and since this is extremely scene dependent, they would also need to me saved/loaded with each individual file.
But first, please post an example that I can take a look at…if it’s something stupid that Rhino’s doing, I’ll fix it…but if it’s truly a near/far clipping issue, then I can possibly start looking at interim solutions.
Thanks,
-Jeff
@jeff I sent @Gijs some models several months ago showing this problem, it also seems to affect viewports which have been scaled in one direction while zooming as well.
This is probably the worst part of Rhino at the moment and needs serious work. It makes my navigation of models and working on fine details very tedious, tiresome and time consuming.
I’ll create some videos to show my experience and send some models again.
Ok great…I’ll take a look at it.
Thanks,
-J
@mcvltd I can see the issue using the example in the bug report Gijs referenced above… So no need to provide anymore examples or videos. This looks more like a glitch in Rhino’s near plane calculations when the viewport scaling setting is less than 1.0 (which the display mode provided does).
I’ll see if I can tune this up.
Thanks,
-J
However,
I’m still not sure if this is the same thing that @lilabaghzouz is seeing. The screenshots seem to indicate something different.
@lilabaghzouz Can you please provide your example, and also confirm that you’re using (or not using) display mode defaults and which display modes in which you’re seeing the problem.
Note: If you’re using tweaked display modes, then please export them and post their .ini files here.
Thanks,
-J
Thanks @jeff , yes, I was wondering if the two were related? I still see what the OP sees in non scaled viewports when trying to work on shuffling control points by very small values on large surfaces - I’ll send you some videos and examples next time it happens.
My workaround is usually turning “showcamera” on for the affected viewport and viewing the camera in another viewport as Jeff mentioned. Then, modify the camera control points (moving closer to the camera) until it’s fixed. However, the issue easily reverts back sometimes days later when the file is reopened or on another computer. It’s the best solution I’ve figured out over the years.