Steven Pigeon wrote:
> I think to minimize computation, tiles would be preferable.
> I think of radiosity and photons which are not local at all in
> nature: they use large parts of the scene.
> 
> 
> For example, having a bunch of render-slaves computers, one
> could be master and dispatch tasks as the CPUs become
> available: once a CPU is done with is tile, it requests another
> region of the picture (without flushing its own data, that'd be
> a shame to start from scratch with photons and radiosity.) The
> master collects tiles and builds the final picture.
> 

 > I would much rather see that master/slave thing implemented
 > in POV than using a script-based dispatcher.
 >
 > Best,
 >
 >     S.


	Wow, what timing :) I've been working feverishly over the past two 
weeks on MegapovXRS, which is similar to what you describe.

	I've essentially retrofitted MegaPOV 1.0 with an XML-RPC server. This 
provides a multiplatform way for a remote client (the master) to send 
work requests via the internet or a LAN using http/(and possibly https). 
Ideally, the authors of SMPOV, POV-Anywhere, Rendview and others could 
add a module that supports rendering with a MegapovXRS slave.

	The way it works is the master opens a new session, delivering 
"command-line" arguments over RPC. Then, the MegapovXRS slave parses the 
scene, shoots any photons and then waits for tile requests. When tiles 
come in they are rendered *without* having to parse or shoot photons 
again. This should provide a substantial boost (compared to a pure 
script based approach) when it comes to network rendering scenes with 
long parse times.

	I have a highly functional beta here and I'm working as we speak on 
preparing it for release to my beloved POV-Ray community for review.

Best Regards,
George Pantazopoulos
http://www.gammaburst.net

Post a reply to this message