Adjusting normals

I import a bunch of surfaces I have received from a client and flip the directions in Rhino so they point correctly (out of the enclosed volume) on all surfaces. I then proceed to draw a number of squares on the surface and place them in the center of the surface…so far so good.

The problem is how to make sure that the normals for these squares all point in the same direction as the surface they are on/derived from (the original surface have varying point orders and this results in different normal direction on the squares)…I’ve tried replacing items in the list set with flipped version, but can’t find a way to select them (I think due to the different list lengths)…

I’ve tried adding the normal vectors of surface and squares and also comparing the angle of the vectors to get a boolean list that I can feed to the Replace component, but with no success.

Any suggestions?

Compare your normals with the Dot Product component. If you get a negative result the square needs to be flipped.

Here’s a simple example that uses the Dot Product component to compare surface normals to a Unit Z vector. Positive results are colored blue, negative results are colored red, and zero results are colored yellow.

dot_product_example.gh (38.5 KB)

-Kevin

1 Like

Thank you @kev.r, and sorry for the cross posting.

I’ve tried the dot-product and hope used it right, but can’t get it to work either and I feel my problem may be somewhere else… one square got flipped, but most didn’t and two of the squares even moved around from surface to surface…

The fat White arrows are surface normals (checked and corrected in Rhino)
The fat blue are normals based on point sequence of surfaces
Thin Yellow are normals of squares after creation
Thin White are normals of squares after my attempt at flipping them to follow the fat surface normals

Thanks
anders


I played a bit more with the input parameters and now all the squares are there and al the surfaces flipped…also the ones that shouldn’t and I get a error regarding the index/list length.

Could the list length be the root of the problem?..I have four surfaces with a total of 126 squares

I’ve uploaded my gh file as well to make diagnostics easier.

Thanks
anders

squares on surfaces c.gh (38.9 KB)


For your example, these two components not enough ?
One of panels used as refernce
unif

It seems you are struggling with a simple datatree issue…
Shift Paths or Trim Tree is useful here.


squares on surfaces c_re.gh (32.0 KB)

1 Like

This is like christmas!.. Two new toys to play with and a solution to a problem
Thank you @HS_Kim & @eddi

Hi @eddi

Can the reference surface be one of the surfaces or would that cause problems?
…ie could i just select all facade surfaces and pick one as the reference or does it have to excluded?
(having it included would make the workflow easier… :wink:

thanks

Now that we are at it… is there a clever way to redo the point order of the surfaces?

If I could unify all surfaces to have point 0 in a specific corner a lot of the work would be easier as would the placement of the squares…I need different spacing on top and bottom from on the sides!

Unify UV’s is super cool, but I’d to achieve the same on a Mac where I can’t use it…
I’ve been playing around with ‘eval surface’ and ‘vector dot product’ along with ‘swap surface direction’ directions, but with out finding a solution that will align all the ‘V’ directions…
Any suggestions on how to do this?