lightcache calculation and DR

[plastic_]

hi,

i'd like to wish for a distributed lightcache calculation with DR.

right know, as far as i see, each computer calculates it's own lightcache, which seems inefficient to me.

maybe it would be possible to merge each computers lightcaches to a single one, for a cleaner solution, instead of discarding them?

[Clifton Santiago]

AFAIK you cannot distribute the LC. Like you said each machine calcs its own LC, which is unnecessary because you only need one. I think Vlado mentioned a future option where you specify which node (i.e. the fastest) calcs the LC, and then all nodes use that.

As for distributing the LC, I think there are technical problems. Vlado would know.

[plastic_]

i understand, but the LC is already multithreaded:

Number of passes - the light cache is computed in several passes, which are then combined into the final light cache. Each pass is rendered in a separate thread independently of the other passes.

otherwise it would only use 1 core when calculating.

so as far as i understand, each core renders its own LC and at the end they are merged together.
it's the same as merging multiple PPT images together, to reduce noise.

i think it would be cool, when using DR, that all calculated lightcaches are merged together, instead of using only the fastest computers solution.

of course there would be the ugly side effect that all computers would have to wait for all lightcaches to be finished, before proceeding to the next task. with fixed subdivs.
but what if the fastest computer sends out a message "i'm done", and the all others stop at their current subdivs (as with PPT, where you can actually cancel the render when you feel it's done).

or, to avoid the randomness, what if you set in the render dialog: i want 30 passes of LC at 1000 subdivs, and let DR distribute them.

[^Lele^]

http://www.chaosgroup.com/forums/vbu...ewpost&t=41318

From the way this works, your wish seems to be nearer to fulfillment than ever

[jujubee]

Damnit - you beat me lele...