MoI discussion forum
MoI discussion forum

Full Version: Nodebundle for playing with nodes

Show messages:  1-18  …  1259-1278  1279-1298  1299-1318  1319-1338  1339-1358  1359-1378  1379-1398  …  1859

Thread Split: Some posts in this thread have been moved here

From: James (JFH)
18 Dec 2018   [#1319] In reply to [#1318]
Hi Al,

Did you try baking out model (clicking "Apply" button on NE Nav Bar)
from your NE setup? It also, cannot be shelled with manual "Shell" tool.
The model as it is constructed, is beyond the limits of Moi's geometry
tolerances for shell function to operate as expected.

It looks cool, though to get it to shell will require alternative approach.
(perhaps slicing into stepped curves for lofting prior to shell operation)
Good Luck!

Hi Karsten,

It would be great if you could have a look at shell node.

It generally works in "Normal" mode, but I could not get "Centerline" &
"flip" options to work, so I abandoned multi-mode, but it would be good
to have the options.

I've attached construct2.js with latest version

Have a nice day
James
From: Karsten (KMRQUS)
23 Dec 2018   [#1320] In reply to [#1318]
Hello Al, Hello James,

please test the following code for the shell command:

code:
    // Shell
function Shell()
{
	this.addInput("Surfaces","objectlist");
    this.addInput("Thickness","numarray");
    
	this.addOutput("Out","objectlist");
    
    this.properties = { mode:["Long","Long","Short"], thickness:[1], direction:["Normal","Normal","Flip","Centerline"] };
    
}

Shell.title = "Shell";
Shell.desc = "Shell";

Shell.prototype.onExecute = function()
{
    var surfaces = this.getInputData(0, moi.geometryDatabase.createObjectList());
    
	var data = this.processInOut(this.properties.mode[0], this.multiProcess, null, this.properties.thickness);

	this.properties.thickness = data.inputs[1];
	this.setOutputData(0, data.outputs[0]);
}

Shell.prototype.multiProcess = function(s, t) 
{	
	return [factory('shell', s, t, this.properties.direction[0])];
}

LiteGraph.registerNodeType("Construct2/Shell", Shell);


@James: Please test the code first, correct the construct2.js file and post/replace it. The problem was, that you had a look in the sometimes outdated API-Documentation - it's always a good idea to look also in Michaels code under the command folder.

A nice day to all
Karsten
From: bemfarmer
23 Dec 2018   [#1321]
Documentation:
ArrayExt menu:
"idxSelect" (an on/off switch, or data selector).
This node has a data input and a data output of matching datatype. Said datatype is determined by RMB clicking on the node, and then clicking either "Numbers" for numarray datatype, or "Points" for pointarray datatype (default), or Objects for objectlist datatype. The node also has a controlling numarray input called idx (index). If the value of idx rounds up or down to 0.0 (i.e. -0.5 <= idx < 0.5), then the data input is connected to the data output. (The on-of switch is on.) If idx is 1 (actually if idx <= -0.5, or 0.5 <= idx, then the data input is NOT connected to the data output. (The switch is off).
By varying the value of idx, portions of the data stream wired to the input can be passed on (selected), or blocked.
A rudimentary circle .nod was used to figure out the function.

- Brian

(I made a few minor changes to the nodeeditor Wiki, which is very out of date and incomplete.)
Current directory of extension nodes is difficult to locate...
Nodeeditor is over 3 years old.

I spent considerable time re-reading the parametric design thread, and nodeeditor thread, to try to learn more of how each node works,
and copied relevant portions to a text file, to distill out some documentation
From: Karsten (KMRQUS)
23 Dec 2018   [#1322] In reply to [#1321]
Hello Brian,

that's really good news! Every help is welcome and you are completely right - It's time for an update!

In the past, it was sometimes frustrating and demotivating to be exposed to certain criticism about filing locations, documentation and organization. This criticism is justified and everything could be better - but my time, skills and motivation is limited and I never promised anything. On the other hand, I had to ask myself the question: Who actually uses the thing? And is it even necessary to write a documentation if there are only 5 people who anyway have a better understanding of the possibilities than me? Nevertheless it makes me happy to read about your activities. Let's keep the elephant alive - only one line of code or documentation is better than any discussion about it.

Now I have to dig to my passwort for the wiki.

Some peaceful days to all
Karsten
From: bemfarmer
23 Dec 2018   [#1323] In reply to [#1322]
A quick email search located my wiki password. It is well to avoid letting chrome save it, as otherwise the MoI forum password may be overwritten.

Yes, project time is limited. I have a little geometry project in mind, call it a little algorithm, to be done with the node package, but was very unsure of which nodes to use, and how to combine them properly, to get the desired results. Grasping that the three data types are all "arrays"/"lists" of some type, although each
is an array of different types of things, and that the array data "streams" or "flows" along the "wires"/ "tubes"/ "pipes," is helpful. The effective length of all of the wires is essentially zero, and data flow along them is nearly instantaneous. Also it seems like the same English word can be used to describe many different things, so it is harder to describe how everything works. It must be very hard for those whose native language is not English (or French:-). Several different things are called programs. It my be helpful to have a dictionary section defining what words and abbreviations mean. It is very helpful to have little demo node packages, to see how a node works, and LOTS of pictures. Most people have no idea how to program a nodeeditor somenode.js javascript program, myself partly included. Using these graphical nodes is a little easier.
- Brian
From: James (JFH)
23 Dec 2018   [#1324] In reply to [#1320]
Thanks Karsten,

Unfortunately*, I’m away for a month, so am unable to test (no computer)
I’m sure it works perfectly, your coding is always spot on!
I’ll repost the file the moment I return in end of January.

Merry Christmas to you & everyone here,
Speak in the new year
James

* perhap “Unfortunately‘ is not the word for describing a holiday.
From: mkdm
24 Dec 2018   [#1325] In reply to [#1324]
Hello James!

...but "no computer" is for sure a valid word for describing a holiday :) :)

Merry Christmas and best wishes to everyone :)
From: James (JFH)
24 Dec 2018   [#1326] In reply to [#1325]
Marco, that made me laugh!
Have a wonderful Christmas
& we’ll speak in the new year.
James
https://www.instagram.com/nodeology/
From: bemfarmer
25 Dec 2018   [#1327]
James' B-HiveGrid Macro prompted investigation of the Polygon node.
- Brian

Attachments:
PolygonAndHexGridNotes.pdf


From: bemfarmer
29 Dec 2018   [#1328] In reply to [#1327]
James has already done 2 versions of Hex Grids macros, which I still do not fully understand.
After a lot of study, here is my version, HexFlatGridAlpha01.nod, which contains the HexFlatGridMacroAlpha01.
The mini Hex nod may be saved in your nod library, and the Macro may be Exported to the nodeeditor macro folder.
I still need to write up my documentation. It was hard to wire up the "math formulas," and the macro is a bit of a wiring "birdnest."
Separate MathPts arrays for the non-indented and indented columns, as the array node did not seem to be amenable to doing them together.
The behavior of the U range, prevented the display of only one column, as maxRange for a single column incremented itself.
Still need to Extract X and Y values.

It took awhile to realize that the unum and vnum are total copies, not incremental values.


After creation, the grid may be MoI Mirrored to the pointy vertices up orientation, with rows and columns swapped.

Perhaps some alteration to the behavior, in nodeeditor, of the Esc button could be done. When 2 or more nodeeditor windows are open,
pressing Esc deletes the currently selected window, and the work done is gone. If only one window is open, (or focus is on the initial window?),
after Esc is pressed, the window reappears by reloading with nodeeditor hotkey, but other windows are gone.
(A habit of pressing Esc button at times, erased some windows, but only a little bit of work was lost...)

(After upgrading office computer from w7 to windows 10, Quickbooks 2018 refused to open, until uninstalled and reinstalled. (MoI 4 beta worked fine.)
Also, for MS Office 2016, (and also Office 365 monthly fee version), the Excel, Word, Publisher, Access, and PowerPoint programs refused to open any files,
and crashed. After some talented Microsoft techs from the Philippines spent 2 or 3 hours+ remote controlling the computer, the problem is
not resolved. Next week is "Level 3" :-) ) [Everything worked fine on home computer.]
>>>Update, took office computer home to fast internet, reinstalled Windows10, and everything works.
Do not install/upgrade to W10 on a slow telephone line internet.

- Brian

All node programs should have a Title box on the node window...to aid memory of which nodes were just open... (Using an extra Output box works OK)

Attachments:
HexFlatGridAlpha03.zip


From: Michael Gibson
29 Dec 2018   [#1329] In reply to [#1328]
Hi Brian, for the escape key handling, one possibility could be to put in an onunload="" handler which can go on the <body> element, and save work there. There's an example of that in the Options.htm dialog.

Also in v4 it is possible for a dialog to do custom handling of keyboard events and it is possible to override escape key handling. There's an example of dialog keyboard event handling in ShortcutKeyDialog.htm .

Putting in a function like this should prevent the default escape key processing which closes dialogs:
code:
			function OnKeyDownEvent( e )
			{
				if ( e.isEscapeKey )
					e.handled = true;
			}


- Michael
From: bemfarmer
29 Dec 2018   [#1330] In reply to [#1329]
Thank you Michael.

I've recently noticed another "strange" behavior in MoI4Beta, or nodeeditor.
When a nodeeditor window is open, and its upper left section, about 2 inches square, more or less, is overlaying the origin of the MoI screen,
using the mouse scroll wheel in the nodeeditor window, causes the MoI grid to zoom in and out.
(The upper left area of the nodeeditor window does not have to be over the origin.)


- Brian

p.s. This does not seem to be occuring in MoI3 with the same nodeeditor version 1, rc3.

Nodes activity in this area has the node flying way way off to the Northwest of the node screen...
They can be moved back into viewing range...

EDIT: The above behavior did not occur the next day, with a reboot. But later in the day, the "zooming" is back.
From: James (JFH)
30 Dec 2018   [#1331] In reply to [#1328]
Hi Brian,

I’m sorry if my Hex Grid macros were a source of frustration for you. You’re right that there several incompatible versions. It was more a cobbled-together contraption to perform a given need than a definitive macro for broadcast. So thank you for your work in producing a universal macro for hexagonal grids.

I am, right now, on an island: “Phi Phi” off Thailand, with no means of testing / playing with it, but thank you for your hard work; it is much appreciated. I look forward to seeing your documentation.

Warm regards
James
https://www.instagram.com/nodeology/
From: bemfarmer
30 Dec 2018   [#1332] In reply to [#1331]
Hi James,
Your many .nod files are very interesting and educational. I've used your HexGrid
information a lot, and the equations that I figured out will be the same, or similar
to many of yours.
For myself, there is still a lot to learn about the Nodes, in order to be able to use them,
so in this winter "reduced workload" period, I'll try to do some documentation about
using some of the Nodes.
- Brian
From: Michael Gibson
31 Dec 2018   [#1333] In reply to [#1330]
Hi Brian,

re:
> I've recently noticed another "strange" behavior in MoI4Beta, or nodeeditor.
> When a nodeeditor window is open, and its upper left section, about 2 inches square,
> more or less, is overlaying the origin of the MoI screen,
> using the mouse scroll wheel in the nodeeditor window, causes the MoI grid to zoom in and out.

Thanks for reporting this - I was able to reproduce this over here and it should be fixed for the next v4 beta.

- Michael
From: bemfarmer
19 Jan 2019   [#1334]
There seems to be some kind of bug with mPath_Array.
After running the script, without Apply, the CurvesU are selectable and deletable by MoI, the points are not selectable nor deletable by MoI, until Apply is clicked.

After clicking Apply and deleting everything in MoI, and returning focus to the nodeeditor canvas, Run does not produce any result, until an input wire, or output wire is detached and re-attached, or knob is "rotated." Also detaching and reattaching the gold wire from ConvertPts, point mode, causes the points to re-appear.
Detaching and reattaching the gold wire from convertPts, CurvesUmode, causes the lines to re-appear.

Also, highlighting of the CurvesU lines will reappear inappropriately.

- Brian

Attachments:
testSplitPtsProblem.zip


From: Karsten (KMRQUS)
19 Jan 2019   [#1335] In reply to [#1334]
Hello Brian,

thanks for testing! I had a look to your example, but mPath-Array gives no Points or something else to the database. mPath-Array uses database elements, but only temporary. So it seems to be a diffenence of the handling in the convertPts noder in the output-node. I my opinion only a small problem, deleting object while running NE isn't a good idea. Maybe it's a bug, maybe it's a problem to implement a NE with the Moi-API. It isn't made for. Nevertheless I will have a look to the code the next days.

Have a nice day
Karsten

p.s.: Try changing along and across in the mPath-Array node - it gives you an impression how bundlePts work:-)
From: Karsten (KMRQUS)
19 Jan 2019   [#1336] In reply to [#1334]
By the way - It was the most difficult node in the extensions I made from scratch. You have to differentiate between open and closed curves, evaluate a tangent to the start points (no API function in V3), adjust a orientation of a frame with it. All points/frames on the curve are depending on the mode - orientated to the curve (used arraycruve). It takes not only a single value for the div - you can also put a numarray with monotonic increasing values to the input - so you get different distances for the points on the curve. Here I had to use the strategy to place them from both sides for performance issues. PLEASE - don't find a bug:-|

p.s.: If you want to see the frames in an pointarray, you can use showFrame. Also useful to understand the working of the Euler-angles.

Attachments:
sf.nod


From: bemfarmer
19 Jan 2019   [#1337] In reply to [#1336]
Thank you Karsten,
You are very skilled and informed.

- Brian

I'll study more, as time allows. House remodeling is calling...
From: James (JFH)
28 Jan 2019   [#1338]
Hi All,

Here's a rather trivial example of Max's improved Remapper node being used to define tooth profiles of a cog/sprocket.

Requires Max's latest interface.js found here:
http://moi.maxsm.net/files/nodeeditor/interface.js

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

Image Attachments:
cogParametric.gif 


Show messages:  1-18  …  1259-1278  1279-1298  1299-1318  1319-1338  1339-1358  1359-1378  1379-1398  …  1859