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/

Hi james
u-v direction is one thing that I still have a problem with it.
I couldn't find a way to force it to use one direction for "uvs".
But for your problem, I suggest to use "method 2" to generate normals.

About ordering issue all that rebuilding surface functions (network, join and separate) make new objects with new object "ids" and new ordering.
But, I managed to reorder surfaces to their original state. (Uploaded)
https://moi3d.com/forum/messages.php?webtag=MOI&msg=9581.321

And about the "surface" output I thought it would be nice to see the surfaces after rebuild function,
Because all surfaces are not simple and planar, and rebuild method in this node has its limitations.
In this example you can see the surface's form has changed after performing rebuild function.

"Extract" node update:
Changed default input/output to "numarray"
Changed "Mode" function

Added new functions :
"Swap": Replace biggest and smallest numbers
e.g. : [0,0,1,0] => [1,1,0,1] , [1,4,2,3,5] => [5,2,4,3,1]
"Duplicates": Outputs the duplicate numbers
"Make Unique": Removes the duplicate numbers (keeps one of them)
"Shuffle", "Reverse", "Sort Ascending", "Sort Descending", "Length"
"Volume", "Area", "Curve Length" (Object mode)

Address: "Basic/Extract"

Thanks MO,

I applaud your development to Basic/Extract node....you have made it into a very useful and powerful tool, and in doing so reduced the bloat of the node library. We can now retire several nodes: Length, arraySort, FlipNumArray, stlArea, & perhaps also stlVolume.

There is an additional output from "stlVolume" node that may be incorporated in a future extended "Centroid" node (originally contributed by Brian/bemfarmer). Presently this node operates only on closed polygons. Ideally, it may be replaced with a universal "FindCenter" node that accepts both pt and obj data types: finding the centre of point arrays, curves (open & closed), surfaces, polysurfaces, groups of objects, and solids.

Returning to "Extract" node: there are 2 further functions that logically may fall within its scope ie "Shuffle", "Reverse" for point arrays (similarly to numArray options). If this is possible, we may retire 2 further existing nodes. See image

It heartens me that you've taken up the mantle and continue to refine nodeEditor.
James
https://www.instagram.com/nodeology/

Thank you James
Your comments encourage me to keep making stuff. :)
I searched a bit on finding the center of gravity, Its math is way beyond my knowledge.
Although, I've made a macro months ago to get the average of points.
I'll attach it here, so if it was helpful It can be a starting point to write a node.js file.

About adding "Shuffle" and "Reverse" options to the "extract" node's point mode,
I had some success, (added "Shuffle" and "Reverse" to points and objects mode)
But, I have to study more on adding extra outputs to the node.
Specially adding output for a specific option rather than all options.

Gallant Effort MO,

I recognise that liteGraph framework make it difficult (or impossible?) to alter the output datatype with mode options.

Perhaps the scope of this node is too broad. Maybe the solution is to have another node: "Basic/Sort" for reversing and shuffling arrays of all datatypes. NumArray options: SortAscending & SortDescending would also logically fall within the scope of this node as well.

What do you think?
James
https://www.instagram.com/nodeology/