Hi folks, I was dealing with this problem to get these isotrimmed surfaces with this messy topology.
I think a loop would be the best option to subdivide into smaller domains, considering that the corners of the adjacent surfaces would define my new List < UVInterval > and loop it,
I don´t know If evaluating as Brep to find the FF topology would be the best option or just test the collision to get the necessary points(adjacent corners)… If someone could suggest or could help me I’d really appreciate it, thank you!
T.
Here is a simple enough method that does it with standard components + Anemone.
The logic is quite simple, no neighbour search needed:
. find all surface corner points
. for each surface, compute all corners closest points and filter only those at distance (almost) 0 from the perimeter
. compute the U and V values of those points and discard values of 0 and 1 (cull corners)
. if the count of remaining U and V values together is 0, exit loop
. use the U and V to build consecutive domains and isotrim the surfaces along the resulting domains
. rinse and repeat
If you check the definition it might be easier to understand the steps.
NB: the definition contains also a component from Human, but it’s only to enhance the edge preview - you can disregard it if you don’t want to install the related plugin.
Thank you @ale2x72 a pretty clear explanation and smart logic, if it’s not too much to ask what woulb be a good start to develop this in C#, I’d like to study this gh to code translation and working with this loops and please.
regards,
T.
Here’s a C# implementation. It was easier for me to do that than trying to describe the steps, also because it will probably become a froGH component in a future release. There’s no difference in the logic (the steps are those of the pseudocode), although there are a couple of caveats:
. translating what standard components do in C# requires a bit of search in the RhinoCommon API doc (component might package multiple methods);
. removing duplicate values for U and V means dealing with a cursed aspect of floating point numbers - in this case I had to resort to a custom comparer that rounds values to the 7th decimal digit (I thought that was enough precision);
