Here's a node circuit for the generation of a interlinked woven screen.
Be warned that it may take a minute or so for geometry to generate.

Requires most current extension nodes, found here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=9358.10

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

It's unbelieveble what interesting geometry you can create via nodes.
Excellent!
Mik

Hi :)

New NE core build:
http://moi.maxsm.net/files/nodeeditor/nodeeditor.v.1.1.2020.07.14.zip

Minor interface updates, bugfixes etc.

Welcome back Max,

So good to hear from you.
I've downloaded... can't wait to see the changes

Thank you for your continued support of NE
James
https://www.instagram.com/nodeology/

Evergreen! :)

v.1.1 (14-07-2020)
Changes since v.1.0.rc3 version (03-10-2018):

index.html
added:
- utf-8 support

--------------
color.js
added:
- io_text_highlight and io_highlight variables

--------------
editor.js
fixed:
- open file dialog error

--------------
init.js
added command line parameters: file, step, run, close

examples:
open C:\NE\test.nod file
moi.ui.createDialog( 'moi://appdata/nodeeditor/index.html?file=C:\\NE\\test.nod', 'resizeable,defaultWidth:1,defaultHeight:1', moi.ui.mainWindow )

open C:\NE\test.nod file and run it
moi.ui.createDialog( 'moi://appdata/nodeeditor/index.html?file=C:\\NE\\test.nod&run=1', 'resizeable,defaultWidth:1,defaultHeight:1', moi.ui.mainWindow )

open C:\NE\test.nod file, run it, close window
moi.ui.createDialog( 'moi://appdata/nodeeditor/index.html?file=C:\\NE\\test.nod&close=1', 'resizeable,defaultWidth:1,defaultHeight:1', moi.ui.mainWindow )

--------------
lang.js
added:
- minor inprovements

--------------
main.js
fixed:
- open macro dialog error
added:
- more node colors
- macro inputs/outputs reorder (hold alt and drag input/output dot)
- select -> same type/color menu
- minor improvements

--------------
added ext.nodelist.js

--------------
nodes/interface.js
added:
- remapper widget
- minor improvements

Max,

Thank you for the info.
I have a few suggestion that may be worthy of your consideration.

1) I think it would be operationally consistent with the menu logic for "Output" to be included in the first tier, just as "Input" "Output" & "Close" are in menu within a macro. See image below



This is a small thing; but I do think "output" is distinct from other nodes & deserving of first tier status.

2) I don't believe "Point" node is fittingly part of the "Basic" grouping, as it is a geometry node. It belongs IMHO within "Points" menu. To removed the inevitable confusion, I think, "points" would more appropriately be renamed as "pointArray".



3) Wayne made a minor but significant change to your curve nodes: "Rectangle", "Circle", "Star" & "Polygon" with the addition of a surface output option. I have attached below.

Although generally connecting to "construct2/Planar" node satisfied the requirement of generating surface shapes, it fails in some instances (with complex patterns), & in these cases, incorporating surfacing within the node has been a real improvement.

Please have a think about these suggestions and let me know.

Thanks again for your support,
James
https://www.instagram.com/nodeology/

Hi James

1) OK. Done.

2) You're right. I've moved Point node to Points.js and renamed Points to PointArray. Also I updated compatibility.js file. Old projects should work fine.

3) it fails in some instances (with complex patterns)
Could you send me an example?

Hi,

I'm new to Node Editor.

Just curious about the arrangement of items in the menus.

For instance why is there a "Points" item and a "Points2" item but they are not together, one right after the other?

For that matter why are there two menu items related to points as opposed to just one?

Not a big deal at all but was just wondering how things came to be the way they are.

Frederick

P.S. I do try to keep my OC nature under control.

If you go there you will see that Points is "Native Nodes" an Points 2 is "Extensions Nodes" ! ;)

https://moiscript.weebly.com/biblio-elephant.html

Hi,

That seems to be a matter of how the underlying code is structured.

From a user interface point of view that is really of no interest.

Thanks.

Frederick

Max,

Thank you for implementing those changes.

"3)....Could you send me an example?"

Regarding the inclusion of a "Srf" output on shape nodes ("Circle", "Rectangle", "Polygon" & "Star"),
the following shows the situation when this need first arose.

From Top down:
1) connecting directly to "circle" node gives the expected result in arrangement of circles & their colouring,
however the desired effect, is lost because the circles are outline only.

2) now connecting the "Construct2/Planar" fails to achieve the desired result because the order is lost.

3) attempting to go via "CloneToPts" does not work at all.

4) using Wayne's "Curves2/Circle2" node "Srf" output work perfectly!



I have since found that I use Wayne's shape nodes all the time. For example "Curve2/Rectangle2" has for me, made Karsten's "SubD/selCenterPane" obsolete. But perhaps the main application is with complex variegated screen images with hundreds of shape elements, where connecting to "Construct2/Planar" node after pattern articulation, will hang the computer for a long time while it calculates all the trimmed surfaces.

It seems to me a small change that would produce no backward compatibility issues & yet is very useful.

Is your resistance to this change because it somewhat invalidates these nodes from being grouped within "curves" menu? I don't see it as a serious contravention of UI logic, but if so perhaps there could be a "Shapes" menu.

I am happy to continue using wayne's versions, but I do think there needs to be a rationalisation of node hierarchies.

Thanks again for you ongoing stewardship of NE

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

Hello, Frederick,

maybe I should explain a few things about this. The node editor has not been developed by a large team with a master plan and interface designers, but by a single person - Max Smirnov based on code from litegraph.js. So it is understandable that he can't program all functions by himself. Especially since you don't know and can't capture all aspects and wishes of the individual users. So I and some others ( James, Al, Marco, R3D3, Wayne, Pilou ... )started to support and extend the work of Max through nodes, tests, documentation and discussions. But I am not a programmer and my code is sometimes bad. Furthermore there was a discussion my code not
to mix with Max's. My goal was not to extend the functionality, but to experiment what is possible. From the dialogue with James and Al ( I hope he is doing well - nothing read for a long time of him) I also started to implement functions that were not of direct interest to me. I think the separation from Max development is right, because there were many changes in NE and the extensions in the initial phase
which gave and which caused a lot of confusion in the forum. Compatibility, versions, bugs ...
But it is very easy to redesign the menus and build your own NE as you wish.

Have a nice day
Karsten

Hi Karsten,

That information was very helpful in understanding the Node Editor as it exists today.

You said "But it is very easy to redesign the menus and build your own NE as you wish".

Could you point me to something (code, document, articles) that would help me get started? I was a programmer for many years quite some time ago but I think I can still do it.

Thanks much.

Frederick

Bug detected.
Back compatibility function didn't work with macros. Fixed.

James, could you send me the nod-file? I'll try to find a solution.

Max,

"could you send me the nod-file? I'll try to find a solution."

I have attached .nod file, but please don't spend any of your precious time
trying to find another solution, I'm happy with existing solution.

---

While pondering the NE interface design, I had a thought.

I was wondering if the wires between nodes could be different to graphically communicate the nature the data flowing through them. I should preface this by saying that this is not a request, more a question of possibilities.

The image below shows 3 examples of point data: (1) a point, (2) multiple points & (3) ordered point sequence with a ranges of wire types to reflect the particular data type.



Similarly, the wires may vary for single numbers and numArrays, as well as to denote single objects and collections of objects.

Again, I'm not asking for this to be done, but rather wanting to know your thoughts on the future development of NE; whether this was even a possibility.

Perhaps even more useful for debugging node circuits might be a wire type that indicates that indeed no data is flowing through a wire.

UPDATED:

Another suggestion of UI enhancement might be to include set of dots at top right corner of node to indicate that it is a multi-mode node. It is a well established interface convention that requires no explanation. Also there may be some value in grouping the multi-mode nodes under a single heading: "General".



Of course it would appropriate for some multi-mode nodes to reside within other groupings. Several of the "Points" nodes could be folded into the "Transform" nodes, e.g."Move" "Rotate" & "Scale" node could all have modes for "Objects" as well as "Points".

The ability for a single node to operate on a number of different data type is one area where NE is superior to GH (Grasshopper)


Anyway, I am so appreciative that you are working again on NE,
& will be onboard with any direction you choose to take it.
James
https://www.instagram.com/nodeology/

Hi, everybody.
New nodes: Box, Box Center, Box3pts.

Hello Karsten,

Hope you are well.

I have been trying over and over to create a recursive pattern with your loop nodes (loopStart & loopEnd), but I can't get my head around how to set it up.
I have search the forum for an example of looping, to no avail.

I would greatly appreciate, when you have a free moment, if you could post a super simple example of the nodes in use, so that I may use as reference, for building something more complex.

Thank you,
All the best,
James
https://www.instagram.com/nodeology/

Looking at hoopsnake may help. (?)

Google search of "hoopsnake examples"

Laying bricks example pdf:
https://www.researchgate.net/publication/332834996_Loops_in_Grasshopper

https://www.youtube.com/watch?v=gpv5prTmcjo

- Brian

A processed component gets feed back into the "start" of the node program, with some termination method...

(cannot say that I understand it. It would be nice to identify the inputs and outputs of Karsten's program, and compare with the hoopsnake inputs and outputs...(or the other two methods).

Hello James,

busy job, mother is gone - weather is good, beer is cold and the liver grows with its tasks - that's life.

Nevertheless - Loop.
The Loop implementation is very basic and limited to one loop, because there is only one array for storing the feedback data. You can find the declaration in basicFunctions.js in the first lines for numbers points and objects.
With this arrays is the feedback realized so you don't have to wire back something in the canvas - by the way, it's also not possible like in GH.
How it works:
The LoopStart node takes the initial data to the initial connection- a numarray, points or objects - you can set it with the RMB. At the Trigger input you have to put a cycled quartz node that kicks the process again and again. In the first cycle LoopStart takes the initial data and put it to the output. You have to take now this data, do someting with it and give them to the LoopEnd. Loop End stores them in the mentioned array. In the following cycles loopStart checks if it is a first cycle or not - if not it takes the data from the array. It is possible to RESET the node by RMB. This would run now forever - so we need also a termination condition that stops the manipulation of your looped data. So you have evaluate something from your data - compare someting or get the number of object ... and feed the result in the Run input of the LoopEnd node. If you put in a 1 here, the data will be put back to the LoopStart otherwise not and the manipulation stops or better the manipulation cycle takes allway the same data.


I've took my old post to explain it on this example:
http://moi3d.com/forum/index.php?webtag=MOI&msg=7777.1382
Try GetInTouch.nod.
Here is the start object a small cone. LoopStart takes it and put it to the out. Then the cone is moved a little bit. With a intersection node I check if the objects create a clash. This is my termination criteria. So no Intersection - no Objects. I take the Length of the objectlist and check if it is 0, If yes the process starts again with the new position of the cone. If a clash is detected the process stops and with a tolerance of the movement I brought the cone in touch with the sphere.

I Hope you can do something with it - allways a pleasure to see your results!

Have a nice day
Karsten