"surfaceNormals" node

Outputs the normals of the surfaces in 2 methods.
method 1: Faster, better flow ==> by using normal output
method 2: Slower, more reliable ==> by using "Dir" and "Base" outputs
"Dir" and "Base" can match with "vector/LinebyVec" node and "Points2/GetCrvSFrame" node to generate normals.




inputs:
surface/surfaces
u and v divisions

outputs:
Dir: direction of the normal.
Base: points on the surface.
Normal: surface normals

address:
Points/SurfaceNormals

updates :
Unified Normals option added
Rebuild Surface option added
Invert mode added
Small improvements :)
Instruction file attached

Hi Mo,
I can't run your instruction nod because I don't have the Box Center nod.
Can you please post the js file that contains it please.
Cheers
Barry

Thanks MO for surfaceNormals node and instructional NOD file.

I have been experimenting and have found a possible bug with displaying normals of poly loft surfaces (NOD file attached).
Similarly if you use "Base" pts for locating objects (eg a sphere) the result is spheres bunched up in the same plane as the normal arrows.
Initially I thought it may be that all the facet were untrimmed surfaces, but this did not turn out to be the case.
I'm not sure what it could be...


Any thoughts?
James
https://www.instagram.com/nodeology/

Hi Barry
See attached file :)

James
It's interesting.
I extracted edges of a surface and made a new surface with network command and it worked.
I need to check that more.

Hi Mo,
thanks working now.
Barry

James
I checked your .nod file and tried different ways but the result wasn't what I expected.
I think this situation is something like the one I had earlier :
https://moi3d.com/forum/index.php?webtag=MOI&msg=9581.313

Quote from Michael:


anyway, I've written a small node to solve this problem.

"QuadRepatch" node
Gets quad and triangle trimmed surfaces and regenerate them with "merge" and "network" commands.
Use it before "surfaceNormals" node.
address:
Construct2/QuadRepatch

Thanks MO,

QuadRepatch.js did the trick.
I don't think I have encountered this issue before.
Could the code be incorporated within subD/polyLoft node?
James
https://www.instagram.com/nodeology/

Hi James

It's because "evaluatePoint()" and "evaluateNormal()" functions work with uv parameter space not 3d space.
You need to keep the spacing of surfaces' control points even. Using "QuadRepatch", "Network" or "rebuildcurve" node.

This is possible to integrate "QuadRepatch" code inside "PolyLoft" node,
But I think it's better to keep using "QuadRepatch" node.
As you see in the attached image, "Extrude", "Loft" and "Sweep" nodes cause the same issue as well.
And I'm not sure how many nodes like them need to modify.

Hello All,

Is it currently possible to get nodes from direct modeling in MOI? something like what Nick does here: https://www.youtube.com/watch?v=Axtxwt9-gww&t=20s

I think this ability could be quite useful because I think you can make node Kitbashes very easy.

I am not sure if Nick's elephant is compatible or is working anymore because it seems he has abandoned it. Anyway here is his Git repository: https://github.com/nkallen/elephant

He don't develop anymore but you can use that he previous made!
I believe that will work with the principal native " functions" of the V4 !

Hi PILOU,

I know he stopped developing it further.

What I mentioned is a kind of wish! ( because it is a Node Wish List topic) :-)

I wish I can see something similar (or even better and more robust).

I am not sure he will make that...he is full time at it's own Nurbs prog for the next years! ;)

;)

Hi
I've updated "SurfaceNormals" node.
Rebuild Surface option added.
No need to use "QuadRepatch" node :)
Link:
https://moi3d.com/forum/index.php?webtag=MOI&msg=9581.321

MO,

Rebuild Surface option is a great addition to your node,
however is there a way to ensure that the rebuilding maintains the orientation of the original surfaces?

If you look at image below, the combination of "Join" & "separateObj" (green nodes) should unify normals (if not already), however the resulting vector array is not directionally consistent.



James
https://www.instagram.com/nodeology/

PS: I had assumed that "INVERT" option would flip the surface normals, but it does not appears to have that effect. Is it doing something else?

James
I didn't know that "join" and "separate" commands can unify normals. Thanks you for your comments.
It's good to see a problem from different perspectives. Like the "Invert" mode that I was rotating normals around their "y" axis. (BurrMan mentioned "flip" factory but I didn't get it)

I've added a third option to the "RebuildSrf" drop-down menu. ( Still has some bugs)


I'm not sure how to do that. That's why I've added the "Invert" mode. :)
I also changed the "Invert" mode so it flips the surfaces instead of rotating the normals.
Link:
https://moi3d.com/forum/index.php?webtag=MOI&msg=9581.321

Does your nodes of normal orientation work with only one surface selected or several surfaces in the same time ?

Hi PILOU
It works with multiple surfaces. :)

Excellent! :)

MO,

Thanks for the "Unify Normals" option.

The problem with this method though, is that in forcing unification of the W component of the surfaces, the U & V components may be altered, even in cases where the faces are already aligned such as they with a polyLoft.
If you look at the image below; the magenta dots that are coincidental with the black circles are consistent with the original face alignment. Where they are shown in different locations, the new face has been rotated. Indeed the "showFrames" elements at the centre of each face are consistently aligned along blue axes, but not so with the red or green, as would be the case of the original polyLoft output.



Ideally the finding of surface normals should not alter the referent surfaces, but at the very least as a first step, I think it would be preferable to remove "Surface" output from the node, since it would be generally assumed that surface output would be the same as that input.

The other issue that the join/separate method has it that it reorders the faces, so that any regular indexing of rows and columns of faces in say a polyLoft is lost. This means though that if a user wants to address a normal vector for a particular surface, they are unfortunately not similarly indexed.

I see this problem stumped Wayne, and I'm am realising it must be very difficult. Thank you for persisting as long as you have. I would understand if you threw your arms in the air and said "Too Hard, I give up"

James
https://www.instagram.com/nodeology/