Is it possible to get original curves linked with created boundary curve when using Curve.CreateBooleanRegions?
I want to to use boundary curves to create hatches with the same color as the original curves forming the boundary (please see the picture below). Is there an efficient way how to achieve this? I want to avoid reversely searching for the curves by checking the intersections with the boundary curve if possible…
This requires a medium level of coding skills (and a full knowledge of connectivity matters). That said there’s various ways to do it but the fastest - by far - is done in 2 steps:
First get all the segments (and their connectivity [notably VV, EV]) derived from crv/crv ccx events.
Then using solely the connectivity Trees find [I would suggest recursion] the primary closed cirquits, sample the related segments in a tree and then join them into a closed Curve (and/or make a planar Brep out of that). This approach is kinda similar with finding islands in Graphs using solely the VV connectivity.
The 1st is rather easy. The 2nd is a bit tricky (and anything related with cirquits/islands is strictly internal to the practice).
But I could provide a hint or two if you post some WIP C#.
Thanks for the reply Peter! Medium level of coding skill is ok. Knowledge of connectivity is none,) I will do some research on that matter. So far I managed to make it work with curve intersections but it is obviously very inefficient for large dataset. I thought optimize that with RTree search. I’ll look at it and come back here with some examples. Thanks!
Hard to see the point unless you really deal with lot’s of Curves.
Anyway: In a nested loop … for each (valid and planar) Curve (say: the current) in the crvList you should get the ccx events (say: double[ ] t) VS the rest, sample t’s in a tList split the current Curve (using the tList) and add the pieces to a pieces curves List. At the same time you should deal with the pieces connectivity since this is critical for recursively find the cirquits. That said … given the connectivity that part is almost real-time fast since we are talking solely int ops.
But first take a break and get the gist of connectivity. Given 2 Lists of things connectivity is a DT (of type int) [or an int[ , ] array] where the last path dim is the index of the item in the 1st List and the content are indices of the items in the 2nd List. That way we correlate, say, vertices to edges. In real-life connectivity Trees have at least 2 dimensions (for instance: get a List of Meshes and do the CT’s where the 1st dim is the index of the Mesh in the List).
Note : same If the 2 Lists are just 1 List (say vertices to vertices).
Note: a good challenge to master connectivity is to get a Mesh and try to do the 9 connectivity Trees that correlate TopologyVertices, TopologyEdges and Faces (3 classes of objects: meaning 3*3 = 9 possible combos).
An other break MAY be the one required for the recursion: what is, why to use, what are the pros/cons etc etc.
BTW: If you are in the AEC market sector and the scope is to create some sort of facade … then cirquits are 1% of the problem because you’ll need a packing solution (otherwise the pieces - hydro/laser cut from a sheet - may cost an arm and a leg due to the wasted material [unless they are custom tiles]).
BTW: Using another C# (far better optimized for the task) for ~600 cirquits Rhino needs 2.5X the time required for the solution in order to make the BrepFaces (compare Elapsed for the 3 result options [just Solve, Join, make BrepFaces]).
Yes, what you’re looking for is a doubly-connected edge list, a data structure that represents a graph of nodes and their connections, and thus provides simple ways of extracting topological information, such as vertices, edges and faces. In your case, you’re looking for the faces.
Here’s a demo of a Python implementation, I did a while ago and use all the time.
It’s truly an amazing data structure and very useful for many things!
There is lots of material and sample code online about doubly-connected edge lists.
If you want to dive in deep, I’d recommend chapter 2.2 The Doubly-Connected Edge List from Computation Geometry - Algorithms and Applications by Mark de Berg, Otfried Cheong, Marc van Kreveld, and Mark Overmars.
In a first implementation, I’d do it without rtree, since it’s one more thing you need to wrap your head around, even if it’s pretty straightforward to use with RhinoCommon.
It’s only needed to evaluate edges connected to other edges, while constructing the doubly-connected edge list. This can also be done, by simply comparing distances. It’s slower, yes, but the benefits of the rtree won’t manifest, unless you’re dealing with examples of more than a couple of hundred lines to start from.
Thanks a lot for the references and your help! I have made a script with the approach I mention in my first post - checking intersection between closed curves and open curve network optimized with RTree. This reflects my current knowledge. It’s not perfect and has it’s flaws. Example attached…
This is a very old/slow/outdated/useless way to cut the mustard. Re-invents the wheel as well since the only thing that you really need is to get the ccx VV, VE connectivity from phase 1. See a demo on VV, VE (where V [vertices] is the List of ccx Pts and E [edges] the List of the Curve pieces due to crv/crv ccx events).
BTW: If you are in the broad AEC market sector and since geometry is nothing while connectivity is everything … well … I do hope that you get the gist of my message,