I am cutting a construction section through the axis of a bilaterally symmetrical object. Blocks are mirrored across the axis. If I place the clipping plane at the central axis, it’s at the boundary of all the objects and display of clipped edges is inconsistent. If I move the section away from the axis, it’s not accurate. Suggestions?
Hello - do you mean the clipping plane lies on the objects’ face edges where they meet on the centerline? Does it make a difference if the same geometry is in the same setup but not as a block instance, can you tell? Hm - So far here, clipped block instances do look funky but not just on edges…
-Pascal
Hi Pascal
If the clipping plane is snapped to the CL where the edges of same objects’ faces where two mirrored instances meet, the display of the clipped edges blinks on and off in layout depending on what detail views are active, but without apparent consistency. If two surfaces of the same object are joined across the CL, the problem is different: display of a clipped edges’ continuity is interrupted by gaps (or so it works on my project) in a consistent way. Moving the clipping plane fractionally, corrects both problems but it’ll mess up the display of apexes in such a location.
David
That’s a bit low res but it looks like the heavy clipped edge display is only happening in a U shape at the top. This is similair to the way it works for me where surfaces are joined. Along axis-sharing edges of mirrored block instances, it’s all or nothing. In my case it has to do with display in detail views in layout, I haven’t thoroughly tested it in direct model view windows.
I may have spoken too soon; though clipped edges appearing randomly is corrected by moving the cut plane off-axis. But all clipped plane display (including those) turn off and on without a pattern I can discern, regardless of layer visibility settings.
I am now told by Rhino support that clipping display is a known bug. I hope they understand that it’s buggy no matter where it is, doesn’t matter if it’s close to a joint or not. It’s inconsistent.
Hi David - this is the bug we have
https://mcneel.myjetbrains.com/youtrack/issue/RH-44573
Nothing really there to see for the public but there are files etc attached.
-Pascal
Thanks Pascal, and yes, attachments aren’t viewable, so there isn’t much to see, but I hope I have clarified that the issue I am having goes beyond the one illustrated in your image posted above. In my case, in addition to the dropouts shown above, the entire clipped edge disappears without discernable pattern. It does that in V5 too. And neither the dropouts or this phenomenon are entirely related, as first thought, to being at a join (though that may exacerbate the issue.)
Thanks. I’ll look forward to the SR release (need ultra-stability currently so no SR Candidate for me.) Have taken a look at the Bug report listing. It would be really great if fills could work. I’ll just clarify that unreliable display and non-printing of clipped fills in my case isn’t apparently related to the edge of an object being within tolerance range of a clipping plane (as interpreted by this McNeel post https://mcneel.myjetbrains.com/youtrack/issue/RH-46205#focus=streamItem-74-238894-0-0). If the fix here is oriented to solving a proximity-related issue (as assumed in that McNeel post from this month) it likely won’t solve the problems on my system; which have been with pretty much all fills regardless of the proximity of the objects boundary to the clipping plane, as clarified in the name of this thread.
As to it being a major issue or not (as addressed in that same post), that depends on McNeel’s development priorities. I believe that those who - like me - have been decades in the design field look for clarification of elements being cut in section as the primary value of a design section. If that’s not shown consistently, with the strongest graphic element on the drawing, I think the section has the value of a bridge that goes 80% of the way across a canyon. At this point only Section Tools (still in beta for R6) can provide what’s necessary, so if it’s indeed fixed soon, it’ll be cause for celebration.
Brian,
I’m not sure if this bug is completely solved or if there is a related bug.
We are seeing clipping planes fail to clip in layout viewports. We can open a drawing and look at a layout and the drawing looks fine, everything is clipped as expected. After some time of working with the model, if we go back to that layout, some of the clipped edges have disappeared. We can click into the detail and back out and then the clipped edges will reappear. So it seems like Rhino is forgetting to redraw them.
The biggest issue is that the missing clipped edges is inconsistent. We never know which views will not be redrawn correctly. Additionally, if the edges aren’t drawn, then they won’t print. If there were some sort of RedrawAll command that would be nice, but in lieu of that we’d like to be able to trust that all the clipped edges are be displayed without having to check through every sheet before we print.
Just to be clear I am working with the latest SRC.
Thanks
Ian
I am having the same issues. I would be interested in knowing if Navarch can ever print the clipped fills in a detail view on a layout. That never works for me whether they are displaying or not.
@djhg,
We tend to only work with surfaces so I unfortunately can’t speak to if clipped solid fills print correctly or not.
That does sound like it is something else and I remember seeing that in Rhino 5.
If you find a pattern in this behavior, please upload a file and description (and reference to this thread) on this page: https://www.rhino3d.com/upload
I hope to learn soon how to create displayable and printable clipped fills on perspective views in detail ports on layouts on my system, using whichever work-arounds you recommend to circumvent the obstacles which have dogged me for months.