Full Version: Nodebundle for playing with nodes

Show messages:  1-20  …  581-600  601-620  621-640  641-660  661-680  681-700  701-720  …  1841-1859

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

Thanks Marco and Michael.

My i7 is a humble 3770 @ 3.40 GHz.

Good enough for a while yet.

Mike.

---

Hi Mike,

<<I'm a bit obsessed with Moebius strips so I shall enjoy studying this simpler nod.>>

I have uploaded simpler mobius2.nod file tp previous post:
http://moi3d.com/forum/index.php?webtag=MOI&msg=7777.637

If the profile shape is even sided & the number of twists is odd (or vice versa )
the resultant form will be single-sided solid. Which is to say it could be
unrolled into a continuous looped strip.

I encourage you to indulge your obsession,
James

---

Hi Michael.

Thanks for confirming my words.

@You : "...Other areas like a node calculation will run on a single core. It takes special work to use multiple cores, it involves breaking things down into individual isolated task units which can then be scheduled across threads. That's very different than "normal" code..."

It' true, and unfortunately this is still one of the main "Achilles heel" of almost all 3D cad/nurbs modeler.
I mean, the lacks of multicore capabilities for almost all their features.

And this is really a big "hole" because actually if you really want to speed up things in one of these software, including Moi or Rhino,
maybe the one and only way to go is to buy a very expensive CPU with a high IPC and fast and big internal cache.

And actually, for what I know, only very expensive CPU like the XEON line have this characteristics.

All other CPU, including new AMD Threadripper or even all i9 from Intel, although they can run at a higher clock speed,
they cannot reach the IPC value and the overall computing power of a XEON.

So, unfortunately, today the main bottle neck is not the hardware but the SOFTWARE. Almost ALL software!

The main problem is that is really very expensive, especially for a little company or a one person company, to afford the investment that
is necessary to build and maintain the development of a multi core application.

So, actually most of the money we spend to buy new CPU with lots of cores is almost totally wasteful.

Fortunately all these consideration doesn't apply to GPU computing, but here, again, the "Achilles heel" is that only a little portion of calculation
can be demanded to GPU. Only specific types of tasks.

Maybe in the next years we will see a new generation of code compiler that will provide a much robust and wider range of multi core capabilities :)


Have a nice day Michael.

Ciao!

---

Hi Marco, just to clarify - as I mentioned above MoI does make use of multiple CPU cores for the viewport display and for mesh format export. The display is something that is in constant use and so I'm not sure why you'd consider that to be totally wasteful... ?

But because it's difficult to implement it makes the most sense for me to focus multi core use on a few key areas that deliver a high amount of value, such as the display. The next focus area for it will probably be for generating display meshes which will then help speed up file loading for example. It's another area that gets heavy use across many different commands and use cases and so any benefit there is of high value.

Also another thing that has been a limiting factor is doing things on multiple cores can consume more memory since some operations may need to make fairly large allocations and having multiple large allocations simultaneously "in flight" could more easily exhaust 32-bit address space. With the 64-bit version I shouldn't have to worry about that as much.

- Michael

---

Hi Michael.

Thanks a lot for clarifying.

@You : "...the display is something that is in constant use and so I'm not sure why you'd consider that to be totally wasteful... ?..."

Well, I said "totally wasteful" because I have considered the actual situation of CAD software in general. Not only about Moi.
At least the CAD software that are in the "consumer" market, not the "high-end".

I explain.

Ok, it's good to know that Moi deals with displaying meshes in a "multicore" fashion. Perfect!!

But, I was referring also to ALL other kind of operations. All other CPU bound operations.

For example, running each command, running each node in NE, doing any CPU bound calculation.

I'm not referring here to the part of the code that is dedicated to display and render the meshes, but to the part of the code where the calculation are carried out.

When a "Loft" or a "Network" or a "Fillet" command for example, or anything else, takes 30 secs on a given multicore CPU,
if the 90% of the time is relative to the mathematical calculation and are CPU bound, and only 10% relates to final render of the resulting mesh,
then it means that even if you have a multicore CPU, the 90% of the time is spent on a single core and only 10% can leverage on the multi core.

This is what I wanted to say when I said "totally wasteful".

I don't think I'm wrong if I think so.

Anyway, this is totally not referred specifically to Moi, but ALL software in general, so I didn't want to be critical with regard to Moi or your developing job :)

I hope I made myself clear.

Ciao!

Marco (mkdm)

---

Thanks, James.

I'd already started to dig down in your original mobius.nod so this will help.

My late mother started me on this obsession by carving this in wood: https://www.thingiverse.com/thing:2239083

Not bad for someone who took up carving at 70!

Mike.

---

Hi Marco, so the problem is that as I wrote earlier it's far more difficult to write multi-core code than single core code. Along with that difficulty comes many many many more chances for bugs. And not just regular bugs, multi-threading bugs are particularly bad since they are related to timing conditions and can be very difficult to reproduce.

So you might not be aware of the "bundle deal" that you're asking for - along with full time use of multiple cores for every single kind of operation there would also come an overall general lack of stability.

Some algorithms also inherently use a sequential chain of dependent operations and are just not feasible to break up into separate isolated task units which have no intertwined connections.

So there are some good reasons why all software doesn't just automatically use all cores for every operation that it's trying to do. Some things like ray tracing for example tend to lend themselves more naturally to it though because they happen to have more isolation.

- Michael

---

Hi Michael.

@You : "...Hi Marco, so the problem is that as I wrote earlier it's far more difficult to write multi-core code than single core code..."

Ok. I really didn't want to start a "philosophical" debate on "why" multi core operation are really a hard thing to treat in the computer science in general.

Anyway, clearly, I agree with you and with your clarification although I already knew these things.

Thanks anyway.
It's always a pleasure for me to talk to you about software developing :)

It's true (unfortunately) that the intrinsic structure of many operation is not easily compatible with a multi core environment and it's really hard to brake their "atomic" structure.

Fortunately there are some kind of operations that, even in a "consumer" software, can be easily crunched by the modern GPU in a "super multi core" fashioned way.

Just to close this interesting topic with a "developing" curiosity...

I don't know if you already know this, but some times ago the guys at "Solid Iris", (the author of TheaRender now aquired by Altair)
were able to create a very efficient UNBIASED render algorithm that runs superfast on both CPU and GPU simultaneously.
This is one of the very rare cases where you can buy a software that will use ALL the computing power of your PC and in this case
for example really worth to buy a superfast multicore CPU and a powerful GPU and you will not waste not even a "penny" :)

I have TheaRender and it's a pleasure to see how it crunches data simultaneously with my i7-7700K and the Gtx 1080 Ti at the maximum speed.

Just a final side note....some times ago I was studying a really interesting programming language called "Erlang", a language that is especially designed
for developing scalable systems. Anyway I think it's not very suitable for developing "desktop" CG software. The unique software that I know that uses Erlang is Wings3D.

Have a nice day and thanks a lot for giving me the chance to talk about these things.

Ciao!

Marco (mkdm)

---

Hi All,

It seems that I was mistaken about the reason for long generation time for my last .nod file.

As it turns out the culprit was excessive number of boolean operations.
By instead using mLoft2 node it was possible to dramatically reduce waiting time.
This substantially more complex form draws to screen in just a few seconds.



James

Attachments:
OM#2.nod

Image Attachments:
OM#2.jpg 

---

James,

Respect!
Greate Job!

Karsten

---

This structure has it's mesh truly intersected ? (no edges ("tubes") intersected)

---

Karsten,

It hardly needs to be said, but it was your mLoft2 node that resolved it.

Are you working on anything...node-wise?

I don't want to sound like I'm never satisfied, but I was hoping for
a couple of new nodes after to you posted the following:

<<Yep! It seems that we are missing a Network node;-)
And rebuild curve would also help for a complete toolchain!>>

And of course you work on form-finding is beyond my wildest dreams
<<these are the things that drive me>>

So back to you: Respect!
:) James

---

Pilou,

Can you please rephrase; I don't understand your question.

:) James

---

Hello James,

At the Moment I don't work on nodes. I've already written a Network node, but it's very unstable caused by the orientation of the Input curves. I didn't figured out how the Standard function solves this Problem. It's the same Problem like the radius factory.
For the form finding I figured out the stability Problem, but it will take some time to solve it. The code is quick and dirty and the biggest issue was the meshing. Maybe I have to rewrite alot of things in it. I'm not a Software developer and in the past sometimes I used C/C++ for short programms. With this Background JavaScript is sometimes a mystery for me.

Have a nice day
Karsten

p.s.:And I have still some private Problems.

---

As you can see there is no intersection of the material itself! :)

here with 2 grides surfaces intersection but that will be the same with volumes!

Image by JPP (from the "Topo the World" (Topolgicon) :
a very interesting Scientific comics free books in some subjects of Sciences (Maths Geometry etc...!!! (40 books PDF !!! --- 36 languages )

http://www.savoir-sans-frontieres.com/JPP/telechargeables/free_downloads_transit.htm

---

Hi Pilou,

<<This structure has it's mesh truly intersected ?>>

The grids do not intersect, it is just a pattern mapped to surface of the solid.
If you run the .nod file, you'll see that any appearance of intersection is an
optical illusion in portraying 3d model in 2d image.

Does this make sense?
James

---

Yes perfectly! :)

---

Hi James!

Thanks a lot for this amazing node !!

Had some fun with it...

(the 3dm file is pretty big...almost 80MB)

The picture is from a Moi screen export at 3x the original screen size and retouched in Affinity Photo, then scaled down.





Ciao!

Marco (mkdm)

---

WOW! Marco,

Your graphic is beautiful!
Did you apply subD & shell prior to export to Affinity?

Thanks for sharing
ciao
James

---

Hi Pilou,

Thank you for the link:
http://www.savoir-sans-frontieres.com/JPP/telechargeables/free_downloads_transit.htm

At first I did not pay the website any regard, because the layout/design is so appalling.
However I did return to it & am glad I did.

It is a wonderful resource, and right up my alley.
My favourite topics delivered for easy consumption (comic form) for the lazy geek.

Thanks again
James

---

Show messages:  1-20  …  581-600  601-620  621-640  641-660  661-680  681-700  701-720  …  1841-1859