[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