"Deconstruct BREP" shuffles vertices

Grasshopper
1

Grasshopper not being very helpful here :

250217_IMG_Vertices shuffled
250217_IMG_Vertices shuffled1053×877 102 KB

250217_PROG_Vertices shuffled.gh (8.1 KB)

Now let’s have fun un-tangling this mess…

2

Hey there, Osuire

image
image2360×1031 235 KB

Does this help?

When you take the vertices of the single faces, the start/endpoint will be the same point listed doubly. They are not guarenteed to be the first and last items of the list. So, when you deconstruct the single faces into vertices and take the first 4 of the 5 vertices of face, you und up with gook. You can avoid this by using discontinuity, which will list the start/endpoint only once.
3

That is not true

4

You’re right. It isn’t.

I guess I jumped to conclusions when I looked at your first branch and saw 5 vertices for a 4 sided figure. Maybe it is a seam?

Does using discontinuity help?

5

Only questions from you, never answers. :roll_eyes: :yawning_face: :zzz:

6

Do you mean me?

7

No, @osuire, who has probably been using GH longer than any of us. In this case, I’m sure it depends on the brep - how it was created, the nature of its faces. I’ll take a wild guess that bounding boxes are always consistent? I know their faces are predictable.

8

True :bangbang:

vertices_2025Feb17a
vertices_2025Feb17a1443×480 76.7 KB

vertices_2025Feb17a2
vertices_2025Feb17a21443×480 86.5 KB

9

It looks like what it’s doing is preserving the vertex order of the original brep. For example, face 1 of the original brep uses vertices 1, 4, 5, and 6, so those locations get mapped to vertices 0, 1, 2, 3 of the exploded face.

2 Likes
10

Try this python script for a non-shuffled point list.
250217_PROG_Vertices ordered.gh (18.6 KB)

import Rhino
face = face.Faces[0]
corners = [trim.StartVertex.Location for trim in face.OuterLoop.Trims]
1 Like
11

When questions are answered, they become answers for other people having the same question.
:sunglasses:

1 Like
12

Thanks !
While I now have a solution to my problem, I’d like McNeel to consider changing how “Deconstruct Brep” outputs the lists of vertices

13

They already have. Given the discrepancy between R7 and R8, are you really sure you want them to do it again?

14

Not sure what you are talking about.
I’d like the lists to make sense, that’s all.

15

We don’t need to resort to scripting for this.

image
image1920×1260 105 KB

250217_PROG_Vertices ordered _ vr2.gh (33.7 KB)

I would be interested to know how or why the difference in starting point results.

1 Like