Deconstruct Brep returning vertices in *wrong* order

Hi McNeel forum,

I’ve just spotted an example where the vertices from Deconstruct Brep aren’t coming out in the expected order. Following the right hand rule, and given the normal of the surface being input, I was expecting the vertices to be returned in the reverse order to what’s happening.

Rebuilding the surface from the vertices output by DeBrep, by creating a closed polyline and converting that to a surface, produces a surface with the opposite normal to the input geometry.

Example Script:
Unexpected Vertice Order from DeBrep.gh (24.3 KB)

Is this the behaviour I should be expecting or is this a bug?

Thanks in advance,
Charlie

EDIT
In addition to vanilla GH this is using Wombat and BHoM, but I’ve also demonstrated this issue in vanilla GH components alongside and the script works without either of those plugins.

1 Like

Unexpected Vertice Order from DeBrep.gh (27.9 KB)

I can not fully understand your problem.
When I test with a newly created surface, all things are normal. So there is no bug here.

Your brep somehow has multiple faces with “reverse=1” attribute, (you can explode brep and use “list” command)
image

I am not sure how your brep is created, so in the GH file I recreated the brep and that fixt the reverse=1 problem.
your GH file has 3rd party plugin and I am not able to fully understand your problem.
so please check the file and see if problem goes away.

[what is reverse=1]
if X is to your right side and Y is to your front side.
Then Z must be the sky, right?
This is a normal axis system, and the same goes with surface UV direction and surface Direction.

if a surface U direction is to your right, surface V direction is to your front, then the surface normal direction (or surface direction) must be up (to the sky).

For a normally created surface, this is always the case.

but when you do something special such as ‘mirror’
that rule kind of “temporarily broken”.
Also when this brep/surface is not created by rhino, this might happen.

Assume you did a mirror to your surface.
mirror the surface to your left/right side.
the new surface U direction becomes “to your left”
because the mirror action only mirrors the U direction
V direction still the same.
in this case, if the U-V-DIR relationship still remain the same, the newly created surface normal direction should be pointing toward ground.

but no, Rhino does not do that, because a user just mirror a surface and Rhino assume this user does not intend to actually change the surface direction by mirror.

in this case the newly created mirror surface is like this:
U direction to left
V direction to front
Normal direction still to the sky.

that kind of break the rule, right? so rhino gives the surface a special flag, named “reverse=1” (for normal surface, reverse=0). The U-V-DIR relationship is abnormal but rhino accept this for user convenience, and secretly rhino just added a flag to this surface.

Did you consider the surface normals of each face? They all face out on “Closed Breps”.

Hard to see in this case, perhaps, but not a bug. Just deal with it.


Unexpected Vertice Order from DeBrep_2023Jun16aa…gh (15.5 KB)

Oops, forgot to reparameterize the surface - re-posted.

thanks @11165,

The geometry was generated by mirroring, skimming your response I’m pretty confident that this is what’s causing the behaviour I didn’t expect.

I’ll take some more time to go through the details of your response and pass it onto our core BHoM developers so that we can figure out how to handle this in our BHoM code.

1 Like

Here is another way to look at it:


Unexpected Vertice Order from DeBrep_2023Jun16b…gh (17.3 KB)

Brep vertices are not an ordered set. Or rather, their order is incidental and not guaranteed to remain in any way constant or similar after modifications to the brep.