I see that in the file that you attached. When I delete the clipping plane, all geometry in the clipping drawings should also be deleted but here there are a few curves that are remaining.
Do you know which steps it takes to get into this situation?
Trying to open that file instantly crashes Rhino on my end. I’ll try opening that on a different machine…
-wim
Geometries are IsolateToViewport A, because of that “Surface” portion of section is only visible in A and not in B. I think Surfaces should be visible in both view ports, similar to produced lines.
IsolateToViewport will make all geometry that is selected for that command only be visible in the viewport that is selected. In all other viewports (including details), that geometry will not exist. That is the entire point of that command.
I’m not sure if you are reporting that you are selecting a curve and a plane during that command, and that, when the command is done, the curve is still visible in all viewports? If so, I’ll need steps to reproduce that issue.
-wim
I got what IsolateToViewport does, but now I think I also understand why produced by ClippingDrawing command Surfaces and Hatches are not visible in other viewport, but Curves produced from edges are… it’s because in ClippingDrawing AddBackground=Yes.
So, even if objects are not visible in given Viewport (and thus are not sectioned) they are still visible as a Background. I must rethink that, but at the first glance it’s strange that something invisible will still be visible as a Background.
Also, AddBackground seems to be the reason for the Curve “retention” when I modify the ClippingPlane position. Take a look.
They are on the MODEL::320 Layer (which is hidden).
I think it does (at least for now) - at the current state of things, there are so many ways to cut the mustard that it can be somewhat confusing, but I like the direction. Stacking drawings might result in some very sophisticated 2D representations that are non-destructive, which is great.
Dear Rhino team,
one problem I encounter very often as an architect is, that I can’t hide the intersection line between two elements, if they have the same material. This is for example the case for every wall corner. Drawing codes ask for no line in the corner, but if I join all solids, they become too complex to change or even get damaged completely. It would be great, if the elements would look unified, if they have the same section attributes like in Visualarq.
Could you please elaborate?
Is the issue in display when clipping your 3D model, or in the extracted drawings when use ClippingDrawings? Please include an example for clarity. Thanks
I have not tried the new Clipping features in WIP yet, but I am curious: do the clipped objects maintain information about their source objects? Like the GUID or something so I can use that information later on for annotations and stuff like that.
Drawing objects generate user-text for the name of the clipping plane and what part of the drawing it is (hidden-lines, silhouette, etc).
In the following example, when explode a drawing block to get to the elements, you can see that each has the key=clipping-plane-name, and value=drawing-category
Good point @wim so if you tag your source object with user-text and this will be carried to drawing objects:
See in the example, source objects are tagged with their name, and this user-text is passed to the drawing objects. Will this answer your request?
I believe so since it allows to get access to the source object by user text attribute mapping.
The idea is to create dynamic section views for example. Sections could be given leader lines or text tags illustrating their name, or any other piece of information. Without this, they would be just ”dumb” objects in 2D and tracing them back to their source objects would be difficult.
If the source object ID would be automatically written to the clipping-objects User Text Attributes, that would be even better. Please consider adding that.
