Full Version: Nodebundle for playing with nodes

Show messages:  1-4  …  585-604  605-624  625-644  645-664  665-684  685-704  705-724  …  1845-1859

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

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

---

Hi James!

@You : "...Did you apply subD & shell prior to export to Affinity?..."

Oh yeah James!

It took a consistent amount of time to compute on my i7-7700K and I almost get Moi blown up reaching up to 3.5 GB of used memory !!!

:) LOL !

Ciao!

---

Hi Friends ,
this is an exploration of the various surfaces
Topologically related to that of the Taurus-
I think the Height Torus and some variations are
very interesting
how many interested in the subject find the file available
at this link;
http://www.mediafire.com/file/mbvxj8k8qh688dv/Heigt_Torus_Variation.rar
Good in-depth
Have a nice day to all
best
alberto

---

Ciao Alberto.

What a wanderful node!!

You rock!!!

I would really like to have your math skill :)

But...unfortunately this wasn't my area of expertise... :(

Thanks!

ASAP I will make some CG elaboration with your node...

Ciao.

---

Hello,

would someone post Al's last nodefile - Mediafire isn't working for me at the Moment.

Thanks in advance!
Karsten

---

Show messages:  1-4  …  585-604  605-624  625-644  645-664  665-684  685-704  705-724  …  1845-1859