My apologies if this has been asked, but I couldn’t find an answer in any of the related posts. First, I must say that it is pretty amazing to see section tools integrated with Rhino 8.
@rajaa — I noticed, that the selection of objects and layers for clipping planes is not taken into consideration for the added background in clipping drawings. In other words, the clipping drawing sees all objects in the scene. Is this intended behavior? Am I missing a setting somewhere?
They should be taken into consideration. Can you share the example where you see this happening?
I ran quick example where I followed the workflow
Dear Rajaa,
Thank you for checking this so quickly. It turns out I was mistaken. The feature actually works as expected. My initial confusion arose yesterday when I had both objects and layers selected. I incorrectly assumed this would function as an AND condition, meaning that only selected objects on the selected layers would be considered. Clearly, this is not the case.
This is fantastic! It will be incredibly useful for detailed architectural documentation.
May I ask if there are plans to introduce other mechanisms for selecting objects? The ability to select objects based on their names or user-defined text would be extremely beneficial. For example, I’m working on a project that has 4 building parts. I can’t put them on layers per building because the layers are reserved for element types (walls, columns, etc.) If, for instance, I now was to draw a section of just one building, I could filter by the user text “Building A” and would not have to re-select objects for drawing sections whenever all elements are re-generated / re-baked.
How do you see this best integrated in the UI?
For example, would be a selection option when the command run, or something you can set in the clipping plane properties. How do you envision it looking and working?
Hi Simon -
You can use the NamedSelections panel to create selection sets.
-wim
Hi @wim, yes, that is indeed another possibility for selecting objects. However, it would not work for our use case. We usually generate and replace all objects via Grasshopper / Elefront. That named selection set would be lost with every baking as the GUIDS are different every time.
@rajaa at the moment, I think it could either be a filter, that can be constructed from dropdowns (similar to filters in a Notion Database). Something like this, maybe.
The second option, in my opinion, would be just a text field, where object selection rules could be provided by the user.
For both options, a button for applying the selection rules would be required as it is probably not practical to trigger an update immediately with every new object being created in the file.
@andyopayne is there a way to keep selections consistent in this workflow?
I think you could probably use the “named” content cache so you can bake/update objects into a specific named cache in the document and then retrieve those objects at will. Alternatively, you could create custom filtering rules and use those to filter/select objects that meet those rules. For example, you can assign specific User Text to your objects with a value called “Option 1”. Then you would create a filtering rule that looks at User Text values on all objects and only returns the objects who have a User Text value that matches Option 1. One final alternative would be to assign a “Tag” to any object you want. So again, you might tag objects that you want to be in Option 1… then you would create a filter rule that looks at object tags and only returns those that match the word Option 1. So, I would think there are several ways you could still get a selection set that you’re looking for.
I should also mention that if you’re using the Content Cache component then the guids of objects remains the same… so in theory, you shouldn’t be losing any named selections etc as it the Content Cache component only updates existing objects.
Dear @AndyPayne,
I think your suggested workflow could work well, as long as no new objects are generated.
I did a quick test where I used a named content cache to get Grasshopper objects into the Rhino document. My setup involved three clipping planes for creating drawings, plus a sphere on its own layer that should not show in the drawings.
When I switch to object based selection (around 1:40 in the clip) (instead of selection by layer) and increase the amount of boxes, the clipping plane doesn’t know the IDS of the new objects and keeps generating the drawing based on the original 25 boxes.
Long story short, I really think adding some custom filtering rules could make a big difference for our architectural documentation processes. Keen to hear your thoughts!
We also plan to add support for clipping planes in GH1… so perhaps this would all be fixed once that is added?
Yes, most likely, that would fix it all. 
