I may well be wrong but I think the overhead for that would be immense - and 
there's no guarantee the workload would be close to even so you might end up 
with one processor idling, waiting for the other one - at least at the 
moment it can "just get on with it".

I know getting radiosity to work on SMP was a pain - not sure what impact 
(if any) your processing method would have on radiosity but I suspect it 
would pretty much put you back in the same boat - for that one pixel, it 
would need to know where (possibly) any object is. (Please take this as 
speculation not fact)

That said, there may well be a better way - I just don't think this is it. 
(But keep thinking!)

Regards,
Simon

"John VanSickle" <evi### [at] hotmailcom> wrote in message 
news:4671e326@news.povray.org...
> First, pardon me if the idea presented below has already been done to 
> death.
>
> From what I've seen, current methods for distributing a render involve 
> dicing up the scene and having the separate processors render different 
> parts of the scene, but with each processor using the same render 
> database.
>
> I had the half-baked idea of dividing up the render task a different way, 
> and that is to split up the rendered scene among the separate processors. 
> One processor decides which rays get traced, and it sends a 
> ray-intersection request to each of the processsors.  Each one does the 
> tests against a smaller set of the data, and reports the results to the 
> controlling processor.  This controller then interprets the results as 
> need be.
>
> Pros:
>   * Scenes can now be larger without stressing memory limits.
>   * Ray-intersection tests take less time.
>
> Cons:
>   * Communication time between processors may present an unacceptable 
> bottleneck.
>
> Regards,
> John

Post a reply to this message