I have been working on a definition that sweeps a polygon (pentagon for this example) around differently shaped curves. When I deconstruct the resulting Breps, the faces are listed in a different order depending on the initial input curve.
The Brep that uses the rectangular rail curve lists the faces starting on the bottom. Next is the lower outside face, then the upper outside face, and so on.
The Breps that use the ellipse, circle, rounded rectangle, and squiggly rail curves list the faces starting on the lower inside. Next is the bottom face, then the lower outside face, and it loops in just the same way as the rectangular example.
So the only difference is that the lists start with different faces, but the order is much the same.
From reading forum replies, relying on order is not a good workflow, so I will find a more robust method to move forward.
I am intrigued if anyone has encountered this behaviour before, and if they might know any possible underlying reasons as to why the rectangle-derived Brep is behaving differently (and for my purposes more favourably) than the others. I thought this was quite interesting!
PS. I tested curves from Rhino and curves made in Grasshopper and there was seemingly no difference to the outcome.
you can not rely on the order of faces in a Brep.
there is no documented face order that will allow you to understand how faces are ordered.
you have to use / sort / set up some sorting-mechanism.
boundingbox - evaluate min / max x/y/z
use (shape) curve segment midpoints, get closest point to each face.
Evaluate shared edges to determin neighbours
compare Isocurve length against segement length…
Don’t waste your time with “why?”, just deal with it.
WOW, this turned out to be far more complicated than expected, in part because your rectangular rail generates way more faces than expected. Did you notice that?
mcneel are definitely not the people to blame for being lazy or indifferent. They respond all bug reports, actively communicate with the community etc. And they do not make you pay subscription for rhino 5k per year like some other companies. When it was done this way a long time ago and can not be easily fixed, that probably has reason behind it. Of course that would be nice..
There are some methods in rhinocommon though, that might be helpful. We can get indices of surfaces used for brep join operation:
