BUG in Clipping Drawings - doubled output

I’ve built the simplest of the cases (Clipping Plane as yellow srf):

to understand how it works after the recent changes

I noticed it doubles the output (checked on far more advanced example too). Hidden OFF, tangents OFF, yet there are 8 lines instead of 4.

I also noticed it is not responding anymore to Button Trigger, only to Boolean Toggle which is unfortunate. With an external button it requires 2 double clicks - 4 in total instead of 1. It is either constant update or no preview option. It was better before.

I also miss previous output structure - clear distinction between, curves, hatches and surfaces. Now everything needs to be exploded and filtered to get how it was before.

Clear downgrade, at least for me.

@Piotr do you still have that sample, so that I can add it to a YT?

Sure, files attched

test cp.gh (16.2 KB)

test cp.3dm (620.8 KB)

@andy @kike can you respond to the other two issues mentioned in this thread?

Thanks for reporting this. This does seem like a bug. I think it’s returning the “Visible” and “Visible Not Sectioned” lines together which is why there are duplicates. I think it’s only supposed to be showing the “Visible Not Sectioned” lines (at least in this setup). I confirmed this against the Rhino output and there should be only 22 curves (and we’re currently getting 44). As a note, you should be able to get to the original “line category” that we had before by using the User Text values. The categories (that used to be broken out by output) are written as User Text on the curves, so that might help you when trying to filter by a certain type.

I don’t know what you mean that the Button Trigger isn’t working. I was using it and it updated each time I pushed it. In your setup, you seem to have a button toggle to load the objects and perhaps that hadn’t been refreshed? But, the button trigger on the Create Clipping Drawing component seems to be working for me.

Lastly, I can definitely see the argument that outputting the drawing as a block causes more steps for a GH users. This was brought up, but it was decided that saving the drawing as a block in Rhino was much more efficient. Perhaps we can come up with a different way to be able to isolate the line categories within the block to make it easier to access like before. But currently it was decided to try to get the GH output match the Rhino output.

At the moment the CCD works with boolean trigger. When False - it shows nothing, When True - it computes the result, but also, at the same time, responds to any change made in the scene thus slowing everything down (quite substantially with complex scene). I created my own solution that updates the result on demand, if that makes sense.

It doesn’t make much sense to me. Blocks are fine when used multiple times, but I assume every CCD result is used once.

Yes, the “transient” nature of the block is a side effect of us having to change everything to use Blocks. Nevertheless, the simple fix is to use a data recorder (and set the limit = 1) and then it will remember the last block even if the CCD component flushes the information when something changes.

Blocks were used in Rhino because it makes moving “whole drawings” around much easier. In addition, there are certain meta-data things that can be added to the block which helps the Create Clipping Drawing UI pop back up and remember the settings that would have just been more difficult by keeping things only stored by layers or some other way. It does make more sense in a Rhino context, but I would agree that it adds more complexity for the GH user.

RH-97558 is fixed in Rhino BETA

@Piotr I know when we switched the output of the Clipping Drawing component to a block that it definitely made some workflows much more difficult. So, in the next BETA release of Rhino 9, there will be a new component called Explode Clipping Drawing which takes a block from Rhino and then deconstructs all of the elements into their underlying categories. This works for drawings created from Grasshopper as well as any created using the Rhino command. Hopefully this will help deal with some of your frustrations with the current workflow.

Nice. This one component should substitute my workaround:

BIG thanks for listening to this request.