Hi Jeff, thanks for the note - please don’t worry about this - hope you sort out the personal matters that naturally are the highest priority. Good luck.
-j
I still did not find any solution for this, but one thing I realized is that the camera target distance affects the clipping - if it’s closer to the camera, far geometry gets clipped, if far from camera, close stuff disappears. Still hoping for a way to see everything…
What happens if you scale everything down to 1% of the original, is the clipping tolerance equally affected so you end up with the same result (just on a smaller scale)?
I have tried scaling all (incl. my named views) by 0.01, 0.0001, by 100, 1000… the clipping changes slightly but is still very prominent and impossible to make a view that has both closeup and far-away stuff. I could badly use this working now…
thanks for the suggestion to try. I have zero new ideas how to fix this and I have spent hours trying 
Could you make a simple dummy file that illustrates the problem and your need? I would like to take a look 
Hi Holo, thanks!
I made a dumbed-down version of the same file.
It has 2 NamedViews - one with target close to camera does far-clipping, one with far from camera does near-clipping.
Here is the file:
LargeScene_ClipProblem.3dm (1.2 MB)
And here is how it looks:
I need to see everything in this file (close and far) to do the work and views evaluation properly…
thanks for taking a look at this!
–jarek
If you turn on the camera (F6), in each NamedView plan view you can see a dotted lines in the camera frustum that look like they correspond with the clipping that occurs.
@Pascal - do you know if these are accessible via any deep Rhino settings or RhinoCommon coding ?
Clearly they would need to be modified and not in Auto mode to deal with such large size scenes showing properly.
EDIT: would any of these have to do with it?
https://developer.rhino3d.com/api/RhinoCommon/html/Overload_Rhino_DocObjects_ViewportInfo_SetFrustumNearFar.htm
Hi Jarek - that (your link to Rhino Common) is where I’d expect to start, yes… I have not messed with this though.
-Pascal
Thanks Pascal, I tried a little bit messing with it but that’s the level of RhinoCommon that I still struggle with. Meaning: I can find the right methods, but that is the end-piece, I am having hard time tracking it to where to start (meaning: get active view/viewport and apply these methods to try to set these near/far numbers to see if they do anything). I would appreciate any hints.
–jarek
Right… it will be a matter of the one-eyed with a limp leading another one-eyed, but I’ll take a look…
-Pascal
1 Like
At least your one eye and limp should have direct access to some world-class Olympic Athletes over there… 
Yeah, only, the gold-medalists are not just across the room any more - we are all working from home these days… Slack…
-Pascal
that’s right…very smart. Please stay smart and safe. We all need you this way!
2 Likes
Hi Jarek,
this is as far as I got… So I get to harvest and set the frustum values, but the view doesn’t seem to get updated, so this is beyond my understanding and ability to fiddle with stuff I don’t understand
import Rhino
view = Rhino.RhinoDoc.ActiveDoc.Views.ActiveView
if view:
vp = view.ActiveViewport
vp_info = Rhino.DocObjects.ViewportInfo (vp)
vf= vp_info.GetFrustum()
print vf
vp_info.SetFrustumNearFar(1,100)
vf= vp_info.GetFrustum()
print vf
vp.SetViewProjection(vp_info, True)
view.Redraw()
Edit: Note that I don’t really know what I am doing here, I have just used bit’s of codes I found combined with knowledeless common sense, so it’s no surprice to me that it doesn’t fully work. But the two print vf outputs shows that the data has been altered. So I guess it fails in how I try to put that data back into the view object.
1 Like
Hi Jorgen,
thank you for trying, I have tested it here too and spend more time trying to figure out why the near/far frustum bounds are not changed by this code, but no luck. I feel like if this is doable we are pretty close, but clearly missing something. @stevebaer - would you have any hints to make this code work and affect the frustum near/far and make it update the clipping bounds in the vport?
(additional question: assuming it is possible and we are successful - is it possible to have the updated near/far clipping planes be saved in a NamedView? Now looks like Rhino adjusts these values automatically as we move the camera, but clearly there are cases where this fails)
I did not get anywhere useful either. Missing a step someplace to actually update the view. I’ll have another look.
-Pascal
I have also tried this:
import Rhino
view = Rhino.RhinoDoc.ActiveDoc.Views.ActiveView
if view:
vp = view.ActiveViewport
vp_info = Rhino.DocObjects.ViewportInfo (vp)
vf= vp_info.GetFrustum()
print vf
vp_info.SetFrustumNearFar(1,100)
vf= vp_info.GetFrustum()
print vf
vp.SetViewProjection(vp_info, True)
vp_info = Rhino.DocObjects.ViewportInfo (vp)
vf= vp_info.GetFrustum()
print vf
view.Redraw()
vp_info = Rhino.DocObjects.ViewportInfo (vp)
vf= vp_info.GetFrustum()
print vf
So the code checks the frustum values before, after the projection was applied and after redraw.
Not sure what to make of it, but if the camera is visible (F6 toggle), the last value reverts to the original one after redraw.
In general my wild guess is Rhino automatically readjusts the frustum clipping distances on each redraw based on the scene info/boundingbox etc, so even if we change the distances, they are being overridden by the auto adjustment. Question is, can this be prevented?
Or the automated version improved to deal with the scenes like my sample ?
–jarek
I think it sets it based on camera target, but I was not able to adjust that either, so I presume there is a different ‘check in’ of the data needed.
They must be taken from the scene bounding box or something similar, with some correlation to target since it’s distance affects the clipping in my sample file. Maybe its a matter of some tolerances that fail on huge scenes with closeup objects.
Take a look at this: the dotted lines represent the frustum clipping planes; when I measure the distances to them from the camera they correspond to what your code prints as first line. But they remain unaffected by the change via code…
1 Like
Yeah, I have a feeling that gathering the data and manipulating it does it on a similar matter that coercing an object and manipulating that one does so on a ‘theoretical’ object that is not in the document, so it needs to be replaced back into the ‘current view’. (I wish I could explain that better in english) But I don’t know how to do that in Rhino Common. So we need help from greater minds than ours Maybe @jeff can help?
1 Like