PDA

View Full Version : Seperate Render Thread / easier Network Rendering



sire
08-12-2003, 07:03 AM
It often bothered me that I could not continue working in Layout while a render is going on.

A long time ago, when I started doing 3D, I worked with a package called Reflections on good old Amiga. The renderer was a seperate executable there, so it could run in the background (which was a fine way to show off the great multitasking capabilities of AmigaOS btw... :)).

I suggest assigning to shift- or ctrl-F9/F10 an action which delivers a render job to the network rendering manager (StealthNet would obviously fit in, if there is any intent of picking up development) instead of locking Layout. This would mean each time the user hits one of these keys, temporary and indexed (e. g. with a timestamp appended to the base file name) versions of the scene and its objects are saved to a dedicated directory, and a render job is added to the queue in an adapted StealthNet.

The moment each job is finished it should automatically send the result to Layouts ImageViewer window, if so specified. Maybe the network render module should be able to open its own ImageViewer (FP) to avoid too much communication handling between the render module and Layout (like with the Hub ... *shiver*). This way Layout wouldn't have to care about the rendering once the job is sent to the renderer.

If setup appropriately, test renders even wouldn't bog down the machine running Layout, because the render job automatically is delivered to the render network (which could simply be one second dedicated render machine). But of course this wouldn't be mandatory, as the machine carrying out the render could be the same one as well. Depends on StealthNet's configuration.

stib
08-13-2003, 02:21 AM
yeah and you you could even farm off separate parts of the frame to separate nodes, so that you could render single test frames rilly quick with your entire render network.

You could implement this with LWSN and LScript I think.. (having merely glanced at the LScript documentation I now feel completely qualified to make such sweeping claims)