View Full Version : I'm crazy... i want to write my own Rendermanager App!

08-28-2003, 12:04 AM
I've recently started using lightwave 7.5 and have been doing some network rendering etc. I was trialing tequilascream which was pretty good and a lot more useable than the default screamernet II inside of lightwave.

I'm very tempted to buy the tequilascream app however call me crazy but i've kind of got a hankering to write my own. Now as far as i can tell (i havent really looked very hard yet) the distributed rendering works off the job and ack files and these get written to tell each render node which frame of the job they are responsible for. On each node you need to essentially run an app that fires up a cmd line with the paths and flags, plus identify its CPU number / job number. And on the manager you need to create an app that creates the job and ack files for the nodes to find, checks for completed frames and dishes out new job and ack files.

Now is there any development info about how it all works etc or do i need to be on some development program and have the SDK (if there is one) to be allowed to do this sort of thing.

Other than that anyone got any useful tips or info?


08-28-2003, 05:04 AM
Nope, you don't need the SDK and you don't need to be in a development program :)

You do need to know how your transport protcol is going to work (TCP/UDP/IPX/etc....)

I have written two controllers for LW. Not fun, but it is easy. I would use one of the free ones, Spider (very good) or Lightnet (open source now I believe) unless you absolutely A) Have a need to code, or B) have a specific setup and reason to make one.

08-29-2003, 03:19 AM
He he, there's really nothing to it, and I understand exactly how you feel. I'm working on my own Stealthnet replacement myself, my problem is since I'm not a "serious" programmer, and I only work on it when I'm "in the mood" my progress is very slow. ( plus I've gotten too lazy to code it in anything but VB too :/ )

I didn't worry about having each Snet node assigned a different CPU id by letting my render manager take care of all that. Each node is set as CPU1, and whenever it finishes frames the rendermanager running on that node collected the file and sent it it'sself to the hub node (via TCP/IP) . The idea behind this was so you could setup a network with multiple hubs and nodes off of those hubs, so you could get TCP/IP traffic tunneled thru a firewall by just having the two hubs connected and then each node connected to each hub would talk only to "its" hub. Tasks get assigned to the master hub and they filter down thru the rest of the network. Frames are finished and they filter back up to the master.

I really should do some more work on it, that would be fun. Right now I'm working on the part that packages up just the assets needed to do the assigned scene to send them to the master hub.

08-31-2003, 11:24 PM
cheers guys,

I'll start lookig into soon. I might check out some of the other free ones first though.


09-01-2003, 04:59 AM
I believe it was LightNet that let's you download the source code...

09-02-2003, 11:50 PM
I have problem with LScript.
I want to write script that renders multiple cameras.
Can you solve this problem?
Here is my thread



09-03-2003, 12:01 AM
sorry Troya, i'm fairly new to lightwave and havent touched on L-Script yet.

Back on the rendermanager front i've had a brief look so far. I was trying to figure out exaclt what gets written to the Job file and the Ack file. It changes so quickly i cant get at it. Does anyone know of a way to log the changes that happen in a tedxt fiel as they happen. Or does anyone know the details of what exactly gets written and in what order.....?

I'm just trying to get it straight how the commuiation between the nodes and the manager happens.


09-03-2003, 12:56 AM
I wrote a rendermanager myself (Amleto -> http://www.rayserver.com). If you do not plan to use file sharing then you can simply avoid to write the control file and start lwsn just to render needed frames (with the command line arguments). I used an http like protocol for the client/server communication.

If you need some help, let me know.

Alain Bertrand

09-03-2003, 01:22 AM
Cheers Garg,

I was still planning on using the shared drive system which i'm actually quite comfortable with. I was kindo fo planning in coding it up in python script as i cant code C++ and am actually more of a code hack than anything. From the outside it seems that everythign is controlled via writing text commands to the job and ack files? Or does the screamernet II app manager within Lightwave actually talk to the nodes?

If it does do it via the job and ack files i want to find a way to tell what the text commands and paths are then create my little app that at its basic level writes these and gets the render going. Then from there i'd like to make it a bit more of a dedicated manager... tracking the completed frames etc.


09-03-2003, 01:58 AM
screamernet II is wrinting things to files. The problem with this approach is that for example you cannot change the content directory once you have setted up your nodes. This is a bit painfull. Either you setup your own files and then start LWSN as a command line or you need to follow what LWSN will be able to understand.

How will you handle adding/removing nodes ?


09-03-2003, 02:19 AM
well i had thought that if the -D flag is left undefined it would use the content directory defined in the scene that was being loaded. Otherwise i havent explored the idea that far. How do you think some of the other render managers that use file sharing get around this?

As for adding removing the nodes. I was anticipating that if its all handled via the job and ack files that each nodes setup app would have to have a unique ID number put into it (if i thought about getting fancy and figured out some network stuff ideally the manager would just dish out ID's to each node when it starts up and hopefully detect nodes waiting to go). From there i'd assumed that the manager would manage and write the job files for each node that was found / added. If you removed one it would stop writing jobs to that node and probably sit idle. If a new one was added i'd get the manager to start writing job files for that one too..... I havent properly considered it yet... the first step i wanted to do was essentially mimick exactly what screamernet ii does just independant of lightwave... figure out what was going of from there and try to build on it till i had something i'm happy with.


09-03-2003, 03:52 AM
I do not know how other render manager handle the problem of the content directory. Maybe with additional commands handled by their clients. I think most of those render manager use their own client and then call LWSN. You should do the same as this will enable you to workarround the content directory and the problem of handling new nodes or removing dead ones (BTW you will need some sort of keepalive signal to be sure the client is still here).

I think python is a good choice for a prototype and if you do not want to sell it.