Wings 3D Development Forum

Full Version: Mulit threading Wings3d?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
1. I just did a Voronoi mesh on a cube,
2. Applied Voronoi: Polyhedra via TetGen
3. Set Volume Constraint (a) 0.0001 ....(went and had a beer Smile )

WoW! that made my computers 4 core processors work!
But only Core1, was busy, Cores 2,3,&4 were sitting back sipping gin! Is there any way to get all processor sharing the math in Wings3D?

TIA!
Wow.

One of the advantages of Erlang is supposed to be that everything can be parallelized almost automatically. I wonder why Wings doesn't take advantage of that.
Because when it mainly was written in 2000-2004 not many home machines was multicore,
to rewrite the core to be parallel would be fun but a lot of work.

Erlang is not a parallel language it is a concurrent language, but a "thread" per object would be
a good approximation.

The voronoi stuff I don't know anything about, so I can't say how easy it is to split that work.

Writing parallel/concurrent algorithms is always hard in any language, it's just easier in erlang.
This should be move to ManifoldLab section or addressed to me in P.M. or something.
(04-08-2013, 04:41 PM)ggaliens Wrote: [ -> ]This should be move to ManifoldLab section or addressed to me in P.M. or something.
There's a lot of Heavy Lifting being done in ManifoldLab - and if that needs speeding up it's worth one or more (forum) threads in its own right. Have fun, gg!

But it's still a valid - separate - question about whether there NEEDS to be support for multithreading in Wings core. As a design aim, perhaps.
Of course, I'm sure that Wings on Erlang is inherently thread-safe and thread-aware!!

If plugins like ManifoldLab need to be multithreaded, say, is Wings "thread supportive"? By which I mean, are there bottlenecks in the Wings base that would make such multithreading (that gg will no doubt quickly knock together... ) less effective?

A significant part of the normal workflow is linear, there are many short commands (e.g. navigating the menu, setting preferences) with the occasional biggie that make the system go away and think hard. So a blanket approach to multithread every module would probably be a waste of effort - however much fun it was.
There are probably a few key areas that could/should be addressed (although I don't know what they are).

Any idea how much work that would be, dgud?
Has this been looked at before?

tery