Normal Flipping in Grasshopper

Hi Folks,

I've been having some problems with a valid closed polysurface that has all surface normals oriented correctly in Rhino (used the Direction command). However, when I work with it in Grasshopper, it appears that half of the surfaces are now flipped (normals now pointing to the inside of the polysurface). I've tried to use a guide surface, I tried offsetting points along the normal to test for inclusion and then flip. I've even tried to flip normals manually by mutliplying the normal by -1.0...no matter what I try, can't seem to get all surfaces to be in the same orientation. Any insight would be appreciated...

Using:

Rhino SR6 on win xp
Grasshopper version 0.6.0019

Thanks!

~BB~

here's an image of what i get when i do the dir command in rhino:

here's what i see when i display normal vectors in grasshopper:

Tags: grasshopper, normals, polysurface, rhino

▶ Reply to This

Replies to This Discussion

Permalink Reply by Theunis du Toit on November 24, 2009 at 4:37am

I speak under correction, but I do not have time to go look for the discussion now, I think there was a discussion about this and if I remember right it was a known bug in GH 6.0019, I am not sure if it have been fixed in the latest release. Search for the discussion though, just to make sure.

▶ Reply

Permalink Reply by Thomas Bildsøe on November 24, 2009 at 7:46am

If i remember correctly the actual normals could be found by dividing the surface fx. into 3x3 uv points, Extracting one of them using List Item og the normal output and and voila you have the correct normal vector. "Divide surface" returns the correct normal whereas "evaluate surface" sometimes flip the normal

/Thomas

▶ Reply

Permalink Reply by Gabriel on November 24, 2009 at 6:14pm

any tips on flipping a surface it is facing the wrong way? I don't think the flip component works...

▶ Reply

Permalink Reply by Brett Ian Balogh on November 24, 2009 at 7:19pm

Ok, there has to be a more elegant way of doing this, but what comes to my mind (given that the flip component doesn't seem to be working) is to orient the face along its flipped normal vector multiplied by -1 which should flip it back.

here's what it looks like in rhino:

the definition and the 3dm file are attached... hope that helps. if anyone has a better way of doing it, please chime in!

Attachments:

flip_it.ghx, 185 KB
flip_it.3dm, 197 KB

▶ Reply

Permalink Reply by Brett Ian Balogh on November 24, 2009 at 11:04am

@ Thomas,

well, whaddya know, subdivide does indeed return the proper normals! thanks, Thomas!

so here it is:

▶ Reply

Permalink Reply by Kaiko Kivi on February 16, 2010 at 12:21pm

I had the same troubles and solved it by reversing u or v directions. It seems that GH eval component is deriving the normals from u and v (Curvature component also gives a plane at uv but behaves the same). Essentially the cross product u X v gives the normal. I had to find my normals at specific uv-s so the Divide did not work well for me.

While I was looking into C# and SDK I found that the Brep class actually has a property that tells if a face surface is reversed. Now I wonder why this property is missing for surface. Might be that for Rhino any surface is a Brep also.

Interpreting the surface as a Brep in a script I was able to create this C# comp that does exactly the same as "Eval Surface" but gives the normals in the same direction as Rhino.

I am not sure it's absolutely fail safe, but given proper data it seems to behave. If anyone knows a simple way to turn a Surface into a Brep in the script it could make this probably safer by making it accept only surfaces. I couldn't figure it out.

Attachments:

EvalSurfWithRhinoNormal.ghx, 86 KB

▶ Reply

Permalink Reply by Dean Foskett on November 16, 2010 at 7:16am

Hey Guys,
I appreciate this discussion is slightly old now, but I've run into a similar problem myself. I have tried the suggestions listed above and still without a solution. Could anyone shed some light on what I'm doing wrong? If I try to sub-divide my surfaces as Thomas suggested, some faces return with a null calculation

Attachments:

Evaluate surface problem.ghx, 494 KB

▶ Reply

Permalink Reply by machinehistories on October 27, 2012 at 5:55pm

I just had this same problem. I tried flip, evaluate, you name it and even when I would get the vectors displayed properly, the surfaces would still offset in different directions. What worked for me was to input the surfaces into an explode brep component and then run the edges into a new planar surface component. This is strange because if I made a brep first and used it as input into the explode component, it would output faces with differing normals. To me I thought once a surface was joined the normals of the brep all became oriented but this doesn't seem to be the case for the faces and yet it is for the curves???

Attachments: