Hi James,
perfect works great thanks.
Will it be possible to select a object and tile it to the surface in one of your future nod
as you have shown in photo of your earlier post ?
Again many thanks
Barry

UPDATED: macro now includes faceted & smoothed surface options

---

Hi Barry,

<<Will it be possible to select a object and tile it to the surface
in one of your future nod>>

Good idea...please find attached.
James

Hi James,
superb and with the option of smooth or faceted excellent.
Looks even better with thickened tiles perhaps an extrude or shell function could be added.
So again many thanks.
Barry

Hi James
I need help......
your Macro Retopo does not work with your Isocuve tools
has the following ID-Construct2 / isocurve
my Isocuve has the following ID_test / isocurve
You may kindly send me your update
to insert it into the program-
Surely I missed some will last update of
Karsten
By the way fine work,compliments
Thanks in advance and
have a nice day
best
alberto

Hi All,

The pace the forum and this project moves at is amazing - this node is fantastic! Another old Rhino Plugin which would work much better under the finesse of a NODE master is the Array 3d Over Curve plugin. Here is a result. With plugin you can control an object with a control point to array over a curve path. With incremental Scale/Rotation/Spacing can be incremental or constant.

Here is result



Admirer of Fines Nodes but Luddite in Practice.

Hi Alberto,
I had similar issues where nodes have been relocated but if you just replace the
ISO nodes with iso nodes from test it should work.
Barry

Hello Alberto, James, AlexPolo, Karsteen, Barry (and the other N.E. smart guys)

I'm fascinated to see what you are doing with the NE!!!

You're doing wanderful things!!!

I think that actually the unique and real "Achilles heels" of the NE project is the limits and the poor performance of the current Moi's Api.

As soon as Michael will improve it I think we will see amazing stuff!

Thanks!

Ciao.

Marco (mkdm)

Hi Marco, what performance improvements are you looking for specifically?

Do you have a case with poor performance that you can post?

- Michael

Hi Alberto &, Barry

<<Surely I missed some will last update of Karsten>>

Have a read of Karsten's post:
http://moi3d.com/forum/index.php?webtag=MOI&msg=8628.1

Changing to new menu system breaks old .nod files,
but it is much more elegant and efficient.
And Karsten describes a method for updating with
minimum disruption (for windows users, at least)

I encourage you to update, if too, only so I can appreciate
your brilliant examples

James

Hi James,
I agree update to Karstens post is the best option but it should be noted that old/new nod files that contain nodes that have been relocated can easily be fixed by replacing from new/old location.
As I found when running old nod files and the iso node was in test and I was running latest Karsten extensions and it had been moved to construct2.
Hope this explains my reasoning.
Cheers
Barry

Hi James and Friends
Thank you all for the support...
Now the Retopo and Tile files work perfectly ..
I wanted to ask if, 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-
In this case there would be maximum compatibility between old and new
with the only Handicap to have more Tool Labels
What do you say ... can you do it?
In each case again thanks to everyone
for support
best
alberto

Hi James,
my request for extrude or shell is not needed.(I need to plug my brain in before asking)
By starting with a solid its possible to scale it in the w direction by just adding the scale node.
This will allow thickening of tiles that cannot be extruded ie: more organic shapes.
Again thanks
Barry

Hello Michael.

Please, don't consider my previous post as a sharp criticism of your job!

You did wanderful and amazing things with Moi!!!

I have said this many many times on this and other forums :)

But I think that I'm not saying nothing strange when I say that current Moi's Api performance are unsatisfactory.

For example they are absolutely not comparable to Grasshopper performance.

This is very evident when you run complex NE nodes or even a bunch of middle-complex nodes that are chained together and you have simply to grad a slider.
Often you have to wait secs or dozens of secs to see changes, also on fast computer like my desktop PC.

Same operations in Grasshopper are many times faster.

I repeat, I think I'm not saying nothing "fake".

I hope I made myself clear.

Thanks.

Marco (mkdm)

Hello Alex,

the path-rotate-scale stuff should be possible also. Have a look to the attached files. Caused by a little bug it is necessary to replace the basicfunctions.js in libs with the attached one.
@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.

Have a nice day
Karsten

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

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