Bug: Surface orientation / curve direction inconsistency

[martinsiegrist]

I used sporph to orient a mesh onto box surfaces today and noticed an inconsistency in the surface direction on boxes.

The Grasshopper definition contains five inputs:

The first box is created in Rhino with the following command:

Command: _Box
First corner of base ( Diagonal  3Point  Vertical  Center ): Diagonal
First corner ( Cube ): Cube
First corner: 0
Second corner: 100,100,100

The six surface normals all point towards the outside but the curve orientation seems off for the underside of the box. The sporph component places all meshes correctly except the one where the curve direction is ‘1’.

I’m expecting the curve direction to be ‘-1’ for a surface when looked at it from the front side.

Both the Grasshopper box and bot 2pt components create surfaces with confusing curve directions but the result of the sporph is correct.

The surface normals are correctly evaluated for all surfaces and the offset curves are also offset in the right direction.

The only time the curve directions match my expectation is when I extract the face boundaries from an undivided mesh box with six faces. The mesh box is also the only object where the curve seam of a face is consistently in the second quadrant / left-top side region of the surface frame.

I’m confused and it seems something is off for how the boxes are deconstructed and the curves are derived.

Unless I’ve overlooked something, the results seems to be identical in Rhino 8 WIP.

surface_curve_direction_inconsistency_sporph_problem.gh (138.1 KB)

[martinsiegrist]

Can someone please take a look at this problem?

[Willem (Willem Derks)]

Hi Martin,

I had no time to really dive into the details, but my first suspicion was that the odd face had a ReversedOrientation. Maybe I’m wrong but FWIW:

This screenshot is after running the macro and next the script with the box selected.

More info:

Brep.Flip(), Brep.Face.Reverse(), Brep.Surface.Reverse Inconsistencies

To add to the answer that @pascal gave, to properly obtain the normal direction of a Brep face, BrepFace.OrientationIsReversed needs to be taken into account. Every now and then it’s worth showing this. [brep-data-structure-01] – Dale

How to “fix” the Reversed orientation is like so iirc

    for face in brep.Faces:
        if face.OrientationIsReversed:
            brep.Faces.StandardizeFaceSurface(face.FaceIndex)

HTH
-Willem

[martinsiegrist]

Thanks for your reply, Willem.

I copied the scripts shown and I’m not sure if that solves the problem.

So I run this on a simple 100 x 100 x 100 mm box I created in Rhino:

and afterwards again this here:

Referencing the brep in Grasshopper after running the scripts doesn’t show anything different. The curve direction is still 1 while it should be -1.

[Willem (Willem Derks)]

Hi Martin,

The script changes the brep which is a duplicate of that on the Selected Object.
So you would need to Replace the brep geometry on that rhino object in the file.
My examples were just that, examples to show the face orientation reversal.

A better option is to create a GH python script to fix input.
Does this help:

standardize_brep_faces.gh (5.5 KB)

[martinsiegrist]

Hi Willem, thanks for the script. I added it to my definition but it doesn’t seem to do anything helpful.

While breps.out shows one face was flipped, it does not have any effect on the sporph component, curve direction or evaluate surface. The bottom side still is the odd face with the curve direction 1 and all other faces have curve direction -1.

Shouldn’t a standard box have all faces with curve direction -1?

Actually I think every closed brep should have all faces with curve direction -1.

Why isn’t that the case?

surface_curve_direction_inconsistency_sporph_problem.gh (141.2 KB)

[kev.r (Kevin)]

@martinsiegrist

Hi Willem, thanks for the script. I added it to my definition but it doesn’t seem to do anything helpful.

There is a problem with the code that @Willem posted.

• Line 14 duplicates the input breps
• Line 18 modifies brep.Faces of the original input breps
• Line 20 appends the duplicated (unmodified) breps for output

The code works if you make this change to line 18 (Sporph works as expected after this change)

This simplified code works as well.

Here’s the code I was using to investigate this.

sporf_problem_re.gh (114.6 KB)

-Kevin

[martinsiegrist]

Thank you @kev.r this is interesting. I added your scripts to my file and even the curve seam is consistent in the third quadrant / bottom-left side region of the surface frame.

surface_curve_direction_inconsistency_sporph_problem.gh (139.3 KB)

Now we have a solution to the problem but once again I believe the normals of a regular extrusion are messed up and I think this should be fixed in the source code or wherever it is set. I’m fine analysing surface normals and curve sides after some random deconstruction and rebuilding of arbitrarily oriented surfaces but the problem here is at the very start of a standard geometry.

[Willem (Willem Derks)]

Hi Kevin,

Thanks for pointing out my mistake!
I probably did some final formatting that caused this bug to be introduced.

-Willem

[dale (Dale Fugier)]

@martinsiegrist - there is a lot going on here. Can you prune down a sample to just show what you think is not working?

Thanks,

– Dale

[martinsiegrist]

Ok, so this topic started two years ago and things might have changed.

Anyway, I was wondering how the points order works.

brep-dec.gh (11.1 KB)

[dale (Dale Fugier)]

@martinsiegrist

I was wondering how the points order works.

Sorry, the point order of what?

– Dale

[martinsiegrist]

Looking at my screenshot what determines the order of the corners of a face from deconstruct brep? I offset border to make it more clear.

[dale (Dale Fugier)]

Hi @martinsiegrist,

As I mentioned here:

Deconstruct Brep on deconstructed brep Faces returns weird Vertex lists

Hi @inno, One of my favorite images: [image] The DeBrep component just returns the Brep’s vertex array as is, unordered. Without knowing the trim or edge, they are pretty much useless. I’ve attached a solution that might help you. Deconstructed_Deconstructed_Brep_Faces_Less_Weird.gh (10.0 KB) DeBrep should probably return vertices in this manner. – Dale

A Brep’s vertex array is unordered and, imo, useless without having the trim and edge curves that reference them.

– Dale