Suppose you do a straight loft between “n” curves.
If you explode the resulting B-rep, you get “n-1” surfaces.
Now if you use “Deconstruct Brep” to get the faces, and plug another “Deconstruct Brep” to get a structured list of edges, you realize that the order in which the edges are given is messy.
By messy, I mean that the order in which the edges are given bares no logic in respect with the initial loft curves and order in which they were picked.
This is very surprising because the “ExtendSrf” Wombat component allows to accurately select one of the edges, through the terms “West” / “South” / “East” / “North”.
Here is my definition.
The 8 initial curves used to produce the loft won’t help much.
I want to order each quadruplet of edge curves from my 7 resulting surfaces.
I appreciate your effort, but I know how to painstakingly sort geometry.
Your solution works in this particular example, but will fail in other specific cases.
My claim is that the “Deconstruct Brep” component could do a better job at retaining the edge order here :
-My initial curves all have the same direction
-The loft with “straight” option results in surfaces with consistent normal, U and V direction
Therefor, there is no reason tu jumble the order of the edges given that the base surfaces are so similar topologically.
Not only is the first edge non-consistent throughout, not only are they not listed in the same circular order, but they are not even consecutive : it’s complete chaos !
Any attempt to re-order them will always fail in some particular instance, no matter how elaborate the sorting is.
This is very surprising because the “ExtendSrf” Wombat component allows to accurately select one of the edges, through the terms “West” / “South” / “East” / “North”.
Breps are polysurfaces so I guess not always possible to predict order (like something such as a cube could have many potential edge orders), maybe there could be some test to see if the brep is a surface first.
Just align your surfaces on the global plane with the centroid located at global 0. Explode the brep. Make sorting options for East, West, North & South. Sort them. Align them back onto their original planes. Done! Will work always. Make the solution a cluster.
Or even better. Use the origin of the orininal planes and do the E,W,N & S sorting relative to them.
The Wombat component does not output edges.
E,W,N,S are inputs which dictate which edge should be extended.
What is frustrating here is that Wombat manages to sort the edges easily, so why doesn’t the “Deconstruct Brep” output an ordered list ?
I have no C# competence… All I know is that Wombat can access to ordered data while I am stuck with a scrambled list.
Again, even if the forst item is randomly chosen, and the circular order is randomly chosen, at the very least, the edges should be given in a consecutive order, don’t you think ?
Yes, I ment the E,W,N,S as input options.
Michael explained why the native component doesn’t do this. the Wombat component does it, because it was coded to do it. If you want to do it without additional plugins or code, then you have to create the logic you need and create a simple cluster.
…or formulate a request for the “Edge” output of the “Deconstruct Brep” component to do a better job.
I still don’t see how you could use the E,W,N,S inputs to sort the edges in an elegant way.
It is not because a problem can be solved that we shouldn’t try to avoid it in the first place.
The extend method is for surfaces. Brep faces could be trimmed, the edges are not necessary the boundary of the surfaces. Assuming untrimmed surfaces, you can get what you’re asking for like this:
The trim tree component will contain the 4 borders in a predictable anticlockwise direction.
There’s an important bit of information here regarding brep structure. A Brep consists of two principal top-level geometric lists, and a large amount of subservient data.
Primarily, a brep is a collection of faces and edges. Edges here are 3D curves and they are shared amongst the faces that use them as boundaries. Edges are only coincident with the faces within tolerance, and sometimes not even that if the brep gets scaled up enough so that small inaccuracies become large inaccuracies.
Below the level of faces and edges we get to the second order geometry:
Vertices are all the places where edges terminate and meet other edges.
Loops are edges or collections of edges that are closed and on a single face.
Trims can be thought of as the edges, but on a per-face basis. I.e. if you have a single edge which is the crease between two faces, there will be two trimming curves associated with it.
There’s also lists of xyz and uv curves, which I imagine are used to rebuild edges to within tolerances while keeping as close as possible to the original intent of the shape, but honestly I’ve never used these curves.
The Deconstruct Brep component returns the edge curves in whatever order Rhino stores them. It appears to be random, but it’s probably due to some spatial tree lookup or something, in any case, not an order that is useful for anyone except the brep itself.
It seems that Wombat is dealing in Trims instead, which, since they are associated with specific faces, can be easily categorised as u^-, u^+, v^- or v^+, whereas an edge may get conflicting orientations from the adjacent face UV domains and therefore cannot be said to be consistently ‘east’ or ‘north’.
Wombat uses a rhinocommon method for surfaces which is designed in that ordered way, Wombat calls that method. Deconstruct Brep uses brep methods which are not designed that way.
Check this out. The only problem is the first surface, For some reason when I align it to the global plane it rotates itself. If you manage to solve this, then make a cluster and you are ready to go.
Here is another edge sorting method (white group) that produces consistent results, though the edges are not sequential. Instead, they are (consistently!) top, left, right, bottom (N,W, E, S?).
