Normal Direction..again, sorry!

Hi all!

Having some problems pointing my surfaces normal in one uniform direction. I'm trying to generate an inner surface for this folded geometry (similar to a 'shell' operation) to eventually be left with separate panels. I'm starting with the intersection points at each of the surfaces corners. I'm thinking if i can find the 'average' vector direction at each intersection point I can use this to generate the intersection points for the inner surface (or outer)...

The problem is once I start to evaluate the surfaces that share each intersection point, their normal's appear to be pointing in different directions.. I have been through many discussions on the forum which have raised similar issues (including flipping curves and surfaces using guides) but having no luck resolving the problem. I have attached a definition showing my approach... Is there another way? can anyone help?

Thanks

Dean

Attachments:

vector direction.ghx, 386 KB

Replies to This Discussion

Permalink Reply by Dean Foskett on November 16, 2010 at 12:13pm

Sounds promising Vicente, thank you!

I have never converted surfaces/breps into meshes in grasshopper before - can you advise how I go about finding the normal of a mesh face?

I'll start investigating now!

I quickly tested the code (hope I followed your steps correctly) again same problem?

Permalink Reply by Vicente Soler on November 16, 2010 at 12:21pm

I see you are inputing a list of items into the vb component. If what you show in the viewport is the only objects you have referenced, then there is something wrong. You have to select those surfaces in rhino and run the _join command to convert them into a single polysurface.

Permalink Reply by Vicente Soler on November 16, 2010 at 12:24pm

About the meshes, if your surfaces have no trims (i don't know how you constructed them, but from the look of it, it could very well be the case), then the safest way to avoid more triangles than necessary is to use the "mesh surface" component (set the U and V inputs to 1) and then join them together with the "mesh join" component.

Permalink Reply by Dean Foskett on November 16, 2010 at 2:22pm

Vicente,

just generated normals from a mesh surface and there still appears to be a couple of flipped normals? Does the definition look correct to you?

The geometry is grasshopper generated, no. of folds, depths and plates lengths etc are all generated from points which are then ordered, joined then turned into surfaces so there are no surface trims. perhaps I need to find a way of retrieving the vector direction from the original points instead of the surfaces?

....not sure where to go from here

Permalink Reply by Dean Foskett on November 16, 2010 at 2:23pm

image attached

Attachments:

mesh convert.jpg, 116 KB

Permalink Reply by Vicente Soler on November 16, 2010 at 4:07pm

Ok, you are generating the surfaces using the planar surface component, which will generate trims. I think it's better if you directly generate a mesh using the vertices of the polyline:

This assumes all polylines have 4 sides.

I had to add a scripting component because the join mesh component doesen't clean up the mesh nicely. The following script removes the duplicate vertices and unifies the mesh normals so that they all point in the same direction:



x.Vertices.CombineIdentical(True, True)

x.UnifyNormals

x.Normals.ComputeNormals

a = x

Permalink Reply by Dean Foskett on November 17, 2010 at 6:56am

Quick question Vicente, Shouldn't I add anything to the A/B input on the Mesh Quad component? Its giving me an empty parameter at the moment with just the C and D inputs.

I've added a list to the split list component index as some of my surfaces are 3 sides. Do you think the mesh quad would still work with 3 corners?

Permalink Reply by Vicente Soler on November 17, 2010 at 8:21am

I only changed the C/D inputs because in the latest grasshopper release, the A,B,C,D inputs have the values 0,1,3,2 set as default respectively. For this definition you want them to be 0,1,2,3.

Mesh quad should also work for triangles, but D has to be the same as C. To fix this, change the definition to look like this:

Permalink Reply by Dean Foskett on November 17, 2010 at 12:56pm

ok, I've been sat here scratching my head trying to work out why this still isn't working....

I'm Struggling to see how this should be any different to your example. Perhaps its because the angles are much smaller?

Attachments:

mesh quads.jpg, 113 KB
mesh quads.ghx, 262 KB

Permalink Reply by Vicente Soler on November 17, 2010 at 4:30pm

You are only missing one thing, you have to flatten the input of the mesh join component.

Permalink Reply by Shawn Fernandez on November 17, 2010 at 7:51am

It most likely isn't the most efficient method, but if your normals are all in the same general direction or can be said to approximately radiate from a central point you can check each one for their relative direction to that reference point or vector and flip only those that are going the wrong way.

Permalink Reply by Dean Foskett on November 17, 2010 at 1:15pm

hey Shawn,

I did try something similar using a reference point but couldn't work out the best method. I found that if you generate a vector between two points it will always return a positive direction regardless of the direction of the surface it is on? I tried constructing lines from a uv point on a surface to a reference point central to the geometry so see if lines read as a negative direction but I found no relationship between the two points and the normal direction of each surface? Unless I've missed something?