Grasshopper

algorithmic modeling for Rhino

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:

Views: 12427

Replies to This Discussion

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.
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
any tips on flipping a surface it is facing the wrong way? I don't think the flip component works...
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:
@ Thomas,

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

so here it is:

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:
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:

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:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2022   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service