Full Version: Nodebundle for playing with nodes

Show messages:  1-4  …  645-664  665-684  685-704  705-724  725-744  745-764  765-784  …  1845-1859

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

Hi Barry,

<<By starting with a solid its possible to scale it in the w direction by just adding the scale node.>>

Alternatively apply extrude node to tile prior to inputing. However, either way there is an issue with the W dimension/Extrude not being normal to the surface across the totality of a compound surface.

The only way to achieve this at the moment with NE as is, is with offset node to base surface to mFlow 2 layers of tiles, then loft between them. (see below)



Ideally, the goal would be some form of panelling tools like Rhino's or Dynamo's.
If Michael does implement "cage editing" then NE could do the rest: populating inner and outer point meshes. That would be a dream come true!

Hi Alberto,

<<rather than following the Method driven by Karsten, they could coexist inside of the same Folder both old tools and new ones , perhaps renaming Js new files->>

If I understand you correctly, I think this may be a little unwieldily.

Given that there is just a handful of us, I think it would be better if we all just bite the bullet, & all be using the most updated version. After-all,Moi V4 is just around the corner, and so NE v1 will soon follow, which will invariably include change that will not be compatible with earlier .nod files.

Any past work that offers utility will, no doubt, be resurrected
James

Image Attachments:
surface&TileOffset.nod.png 

---

Hi All
I want to share with you
another exploration regarding Height Torus, (umbilic)
this time,
the file is heavy enough, it takes a while
for display to screen-
how many interested people find the file on this link :
http://www.mediafire.com/file/bd9lihbbtda4tjd/Height_Torus-Umbilic_-V2.rar
Have a nice day
alberto

---

Hi Karsten and James
<<@Al: I don't think that's a good idea to have both menu structures in one. Maybe you can have two complete versions of V0.97 with different extensions. But the better way would to convert the node files to the new menu structure. It isn't difficult. Maybe you van use an editor - it is also interesting to see the file structure. And faster as doing it with the nodeeditor native>>I WILL TRY
MANY THANKS
alberto

---

Hi Marco, well one difference is that Grasshopper is implemented in a more optimized language, C# I think.

Most of the Node Editor is not implemented by MoI's API at all, its entire base implementation is itself in JavaScript.

The main purpose of JavaScript in MoI's built in functions is to use it more as a high level glue code, not really for implementing more heavy duty calculations entirely in script. The primary API change to increase MoI's performance for a heavy duty plugin like this would be to have a C++ API so the entire plug-in could be written in C++ rather than having tons and tons of script code. There is a lot of work involved in doing that though, I'm not focused on implementing and supporting a C++ API currently. Really even the script API is not a big focus, I'm still in the process of primarily working on things for the bigger pool of regular users and not really on developers yet.

But in order to improve performance I'll need a lot more specific information than just such a general description, I'd need to have an actual running example that I could test with over here, that would then enable me to profile it and see where most of the time is going. You seem to be making an assumption that all the time is being taken in MoI API calls but unless you have done detailed profiling it is not proper to make that assumption.

- Michael

---

Hello Michael.

Well, first of all I want to thank you for giving me such a detailed reply. Much appreciated!

And this gives me the chance to argue with you about what you have written.

@You : "...one difference is that Grasshopper is implemented in a more optimized language, C# I think..."

I think too that this is exactly the main and unique big difference between current Moi's Api and Grasshopper.
For what I now Grasshopper was written in C#. C# can offer great performance.

@You : "...The main purpose of JavaScript in MoI's built in functions is to use it more as a high level glue code, not really for implementing more heavy duty calculations entirely in script...here is a lot of work involved in doing that though, I'm not focused on implementing and supporting a C++ API currently. Really even the script API is not a big focus..."

I already knew this things but thanks for reminding me :)
It's always been clear that Moi's is focused primarily on "realtime" quick and easy modelling workflow and not on "developing" or "scripting" side.
But remember that I'm always thinking as a software developer,
and while I respect your choice about the main focus of Moi, at the same time it's a pity that Moi can't offer a more sophisticated programming interface.


@You : "...But in order to improve performance I'll need a lot more specific information than just such a general description, I'd need to have an actual running example..."

Ok. I understand. I will try as soon as possible to give you more precise information and/or a use cases.

@You : "...You seem to be making an assumption that all the time is being taken in MoI API calls but unless you have done detailed profiling it is not proper to make that assumption..."

Maybe you're right, maybe not.
Sometimes it's really hard to understand where is the bottleneck because, for example, when a filleting operation takes many seconds
or a loft or a network, it's really hard to attribute these delays to a "bad coding" of a script.


But, as you said, Moi is absolutely perfect for lightweight and realtime operation, not for heavy duty calculation.
Ok. This is perfectly acceptable.
No problem.
This was your developing choice at the time of the first creation of Moi and it was undoubtedly a winner choice :)

Thanks for sharing.

Ciao!

Marco (mkdm)

---

Hi Alberto,

<<another exploration regarding Height Torus, (umbilic)>>

Amazing, as always!
Have you adopted the new node extension menu?
I managed to substitute nodes (ptExt & mLoft2) to get this .nod file to work,
but try as I may, I could not get your previous example to run.

I hope with the release of v1, we will all be on the same page,
and we will wake up from this compatibility nightmare.

Again, great work
James

---

Hi Michael,
>> I'd need to have an actual running example that I could test with over here, that would then enable me to profile it and see where most of the time is going.
It will be great if you implement object instances in new version of MoI. At the moment we need to run Clone factory for each object instance. Unfortunately this method is not fast enough.


P.S. Double click on background to show execution times of nodes.

---

Hi Max.

Thanks a lot for this example!

Cloning it's just one of the things that I had in mind :)

If I remember correctly right from the very first days of V4 announcement these were the "cornerstones" we ever agreed on :
1) 64Bit
2) Instancing
3) Grouping

I'm confident that during the V4 beta period Michael will give us 2 and 3 also :)

Ciao!

---

Hi Marco,

> But remember that I'm always thinking as a software developer,
> and while I respect your choice about the main focus of Moi, at the same
> time it's a pity that Moi can't offer a more sophisticated programming interface.

At some point I'd like to focus more on that. But unfortunately there's a lot of work involved especially detailed and time consuming support work for focusing on that area. One of my biggest limits in being a single person company is how much support is required by what I'm trying to do.

I should be able to make some progress though.

- Michael

---

Thanks Michael for sharing.

@You : "...being a single person company...I should be able to make some progress though..."

I'm confident that you're doing your best :)

Thanks a lot for your support and best wishes for all your things!

Ciao.

---

Hi Max, yes instancing should help with making larger numbers of copied objects.

There is a kind of lightweight instancing built into the Transform factories currently, but it will only kick in if the factory is generating more than 1000 curves or more than 50 (setting from ProxyGenerationNumFactories in moi.ini) faces total. Also it's built around the regular transform commands where there's only one factory generating stuff and so when the command finishes it wipes out all proxies and not just the ones it made.

But I think it would not be difficult for me to refine this mechanism a little bit to give you a way to do a type of "preview mode" where you'd be able to generate a display of a lot of object copies more quickly.

That would be able to happen pretty soon, the full instancing is a bigger chunk of work.

- Michael

---

Hi James
from now on, I worked using updated Karsten's NE,
but I still have many files to share with you, all made with previous versions of the latest update ....
so the advice I give you is to create a double folder, one with them
Old Extension and One with NE ...
in this way, you can open it from time to time, compatible Elephant
with everything....
Thank you for appreciation
Have a nice day
alberto

---

Hello Al,

good news! Please tell me: Are there problems to convert the files?

Thank's in advance
and have a nice day
Karsten

---

Hi Karsten (and others),

Attached is a file with macro that converts a Brep to Edges & points.



I have tried modifying your "Extract" node by making line 212 & 217-220 into comments so that it only outputs edge curves. It works perfectly however is no use for the sharing of .nod files, & hence convert.nod attached.

I wonder though, if it would be difficult to add an "Edges Only" option to your node. Perhaps, if this could be included, it might be an opportune time for a name change (to let's say "Derive"), so as to remove the redundancy of 2 nodes of the same name & not be confused with Max's Basic/Extract.

Anyway, this was just a thought

Have a great weekend
James

EDITED:
Better still, might be for Max to fold this functionality into a Brep option in his "Exract" node

Image Attachments:
convert.png 

---

Hello James,

what a surprise. I didn't planed to use the node in this way. It is pure coincidence, because no names are stored in the node and no names are given to the input. Typically it should be used in combination with the brepNameSubObj. So the node stores pre-selected names and filters it while running. I think there are different possible ways to solve it. You have already shown a way. Nevertheless it would be great when Max would integrate it in the next release of his extract node.
Brep - option on RMB and a filter/switch for edges and faces.

Have a nice day
Karsten

p.s.: Geometrical world trip: Welcome to Bruxelles:-)

---

Hi Karsten

Thank you for getting back to me.

Can you tell me is Objects2/separateObj effectively identical to Objects2/Extract if it had a "Faces only" option?


Geometrical world trip: Welcome to Bruxelles:-) ??????
James

---

Hello James,

The seperate node is identical with the separate command in moi - same factory. It smashes objects. Joined curves in segments, solids and joined surfaces in single faces.

Bruxelles: https://en.wikipedia.org/wiki/Atomium

Have a nice day
Karsten

---

Karsten

RE:Atomium...Ahh now I get you

RE: SeparateObj
Cheers, thanks for info
James

---

Hi,
how can I enter an adjustable range ( from calcs using maths nodes ) into the points node other than with the range slider.
Cheers
Barry

Image Attachments:
Grid Array.png 

---

Hi Barry,

<<enter an adjustable range.... other than with the range slider>>

Use objects2/concat2 node, with RMB option Numbers



Let me know if you need further clarification

James

Image Attachments:
concat2.png 

---

Show messages:  1-4  …  645-664  665-684  685-704  705-724  725-744  745-764  765-784  …  1845-1859