Intersection using exact calcuations

How “non-trivial” might it be to extend the Intersection class with a cone-cone intersection script using exact calculations?

Can you give some more details about what you mean and what you want to accomplish?

Yes, thanks for asking: I have quite a lot of cones, all of which generally face the same direction and overlap. I want a quick way to calculate the intersections between them and trim away all the overlapping areas. Currently, we have it working in rhinoCommon using the brep.split method. However, it is taking a very long time, even though its multi-threaded. I was thinking an exact, or analytic method might work faster. What do you think?

This is probably a bit above my pay grade, but I’m sure that if you post before and after screenshots and some code or pseudocode there will be several people here that will make some excellent suggestions.

It the bottleneck the intersection calculation or the splitting of the cone (Brep)?

We might be able to add a cone-cone intersector for V6. But since you want something returned that you can split with, surfaces from the cone(s) will have to be generated anyway, which might nullify any performance gain.

Thanks Dale. I don’t really need the intersections returned. Ideally, I am imagining a tool that would allow me to place a whole bunch of infinite cones that are defined by their: (1) apex, (2) direction, and (3) theta. I would like this to be represented by a display pipeline that allows me to position the cones by moving their apex (or origin point) and dragging on their direction (or axis) to orient them. I am hoping the intersector would be fast enough to return some virtual display pipeline surfaces of the cones that are intersected and therefore no longer infinite. This would help the positioning before executing the tool and baking out the geometry. The only thing I am missing right now is a fast intersection method.

Clearly this is nothing we have, so some work is going to have to be done if we are going to provide these calculations. Just curious, what are you working on and why do you need this?

This is one of some tools we make for architectural design. Currently, a lot of them involve trims. Everything runs fairly light and is coded in python using rhinoCommon. We do rely heavily on the display pipeline for real-time visual feedback and interaction, hence the need for fast intersectors. Thanks for asking.