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

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

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

Hello Barry,

of corse, you can. Start and end value can be calculated independent from each other. Then you have to concate them together as input for the points node.
Concate2 node can take numarray, pointarray and objects as input (RMB).

Have a nice day
Karsten

Hi James,
thanks can't tell you how long I've messed about trying different permutations.
Not sure if my memory is correct but did Karsten do a spreadsheet with node definitions on it ?
Cheers
Barry

Hi Barry

Spreadsheet can be found here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=7777.200

James