Some may have seen me lately in the forum since I have been asking a lot of questions. I am Working on the second part of my research trying to implement an urban model in an existing context. At the moment I have run into a new issue in my GH file: Data conversion failed from Curve to Surface which ends up not creating all the surfaces I need for the next steps.
i decided to use the BREP | BREP (BBX) component since the Region Intersection component would give me no outputs. Have been trying different combinations of grafting and flattening the information to try to get the desired outcome but have failed.
I am attaching the GH file with the internalized data. If someone has any idea of what might be happening it would help me a lot since in our GH courses in the university more than once we had similar issues that were not solved.
You have to use “Boundary Surface” to turn curves into Surfaces. Also like Baris said, check all curves are closed first and close them if not. (you will need the Pufferfish plugin, since that has the “close curves” component, but its good to have anyways).
They were the same because the inputs were grafted, which defeats the ‘Union Box’ feature anyway. ‘Union Box’ encloses all the geometry in each branch of the tree. When there is only one surface in each branch, it has no effect at all.
None of my “fast” tricks worked for orienting minimal bounding boxes in this case, due to irregularities in the curves. So I ended up replacing your C# component with an Anemone loop, checking angles from “-x/2” (-45 degrees when x=90) to “x/2” (+45 degrees). It seems to work well, even though it’s checking only 1/4th of the possibilities and takes about the same time as 360 degrees in C#, perhaps slightly longer.
All curves start at the top left of each box and proceed CCW.
Being uncomfortable (incompetent?) with RelItem, especially the hard-coded manually configured offsets, I took an entirely different approach to subdividing these surfaces. From what I can tell, the results are identical.