Lock list order

Hello everyone!
Hoping that someone can shed some light on an irritating issue I encounter from time to time.

I can’t upload the file, but will try to replicate the effect with a new file later today. But here is what is happening…After constructing an object using simple loft, region difference, etc. components I sometimes encounter a situation where the list order changes after a tweak to the overall shape.

In this latest instance I used the List Item component with a Deconstruct BRep component to grab edges and use those curves for other downstream processes. After the tweak to the overall shape I need to go back in and find the proper curves again.

Has anyone else encountered this behaviour?
Thanks in advance!

Hi.

Yes, it happens and it’s expected.
Some objects have a predictable “structure”/topology, like a box and its vertexes/edges, or an extrusion out of a base curve, if you have a repeatable segment order, you can expect a repeatable order of the faces of the extrusion. Similarly with loft. Or offset curve loose.

But many other functions will mess up your order. You can’t expect a constant order in them.
Like Sweep, Offset, solid booleans, 2d booleans, etc etc.

1 Like

Edge order can be super unpredictable. Best practice is to sort edges after a debrep if the input geometry is going to be changing.

Thanks to you both! I think that sorting in relation to other geometry is the way that I will go in the future.

In this case what was frustrating, was that a MINOR dimensional change in the Brep made all of the input curves lose their sorting order, and in half the cases their direction as well got flipped.

It would be great if once you initially made your Brep, that as long as you were not changing the shape dramatically that the order of the data trees stayed consistent. In my case I edited a curve control point 0.05mm on a 10 x 8mm object resulted in completely redoing the lists and curve directions - which was painful.

I would add that to the wish list for the future in case David is reading :).

Hi, all Rhino geometry is deriving from a ‘CommonObject’ base. This means you have the ability to store some user-data inside. You can inject a unique ID and identify the surfaces with that. However, this assumes you still have the same instances after an Brep operation.

In practice, I found it much easier to just properly sort a set of geometries by some obvious criteria. The “key-value” search is perfect for this. A common trick is just to extract the point on the UV center of the source and target surfaces and then finding the closest counterpart.

I also have this issue whenever I do a change on BReps. I always include another definition in just to flip the edges and surfaces back to the original directions and sort the order.

It would be marvelous if had this issue solved in future releases.