[Bf-committers] Sunday meeting minutes, 25th feb 2007

Toni Alatalo antont at kyperjokki.fi
Tue Feb 27 08:39:14 CET 2007


Timothy Baldridge kirjoitti:
>>> the parallelization of certain tasks|modules (either trough pthread or
> I agree with this idea. However there is a issue here. Simply going

+1 for background / parallel operation support from me too - I tend to 
often have multiple Blenders open, like yesterday when was running big 
exports (to ogre), while tweaking some other models too. although for 
such cases it is not much of a problem to do it like that, by just 
having multiple separate Blenders, which has benefits too (they can't 
interfere with each other, crashing being the worst case..). but 
managing it somehow nicely from inside Blender would be cool - a simply 
crude solution would be even by launching 'sub-blenders' to their own 
processes (hm that would be actually fun to test with a little script 
:), but for many of the cases mentioned (at least physics sims?) i guess 
having memory sharing threads are needed too.

> functions are extremely fast. This means that the whole .blend file
> could be created, and streamed across the network to the other
> clients. Basically we already have a built-in serializer/pickler!

yah that is cool indeed. at least if the big data (textures, in some 
cases i guess geometry too) is already synchronized / accessible for the 
computers, scene & node etc. configs go quickly with blends.

> I've done some work with this in the past, and am in the process of
> developing a full PVM style Clustering module in pure python. If
> anyone is willing to work on me with this, I'd be willing to dive into
> writing up a few design docs in the concept and possibly contributing
> a bit of code. I don't have loads of time, but then again, no one
> does.  :-)

You might benefit from looking at the work done in and around the next 
gen. IPython project, as they are targeting parallel / cluster / remote 
operations, and have it already running and in use. I think they also 
have quite a lot of time to develop it, 'cause they are using it in 
their jobs (mostly some sort of scientific simulations). 
http://ipython.scipy.org/moin/Parallel_Computing "Interactive Parallel 
Computing"

Although Blender is not Python, the approach there might be relevant for 
Blender itself too, because it targets utilizing parallel / remote 
computations for *interactive* use, not (only) for long-running 
noninteractive tasks like I guess many farm things etc.

> Timothy

~Toni



More information about the Bf-committers mailing list