Rendering Using ScreamerNet
You’re almost there, but first let’s run through a quick checklist:
• Master Computer
• Created new folders in main LightWave folder: config_lightwave, config_screamernet, screamernet_command, screamernet_save
• Copied existing config files to new config_lightwave and config_screamernet folders
• Set main LightWave folder to share across network using the name screamernet
• Created two shortcuts to LightWave Layout
• Pointed one shortcut to the config files in the folder config_lightwave, the other shortcut to config_screamernet
• Ran LightWave Layout using the config_screamernet config files
• Set the command directory to the folder screamernet_command in the shared network folder
• Set the content directory to the shared network folder screamernet
• Rescanned the plug-in list from the shared network folder screamernet location
• Render Nodes
• Created folder called LightWave on the main hard drive
• Copied programs folder from LightWave folder on the main computer to the LightWave folder on the render node
• Set up render batch file using config_screamernet as config folder, shared network folder as content directory, and each with unique job/ack numbers
• Scene Files
• Set the save folder to screamernet_save in the shared network folder OK? Let’s go!
If you can remember that far back, I mentioned that ScreamerNet had two "parts" to it; the first is the controller part that is the Network Rendering panel in LightWave, while the second part is the LWSN.exe program sitting on each node.
When a node is activated, it looks for its first job file. However, there won’t be any there until you initialize ScreamerNet in the Network Rendering panel, but it’s pointless initializing it until you’ve activated all the nodes!
When you run ScreamerNet, a node does two things: It looks for job files and sticks its hand in the air, saying "I’m here, I’m over here!" Well, not quite, but it’s waiting to be found by the controller part of ScreamerNet. This is where some confusion lies with
ScreamerNet. Nodes complain they can’t find job files when they’re first run. This is perfectly normal. Bearing this in mind, double-click each render batch file to activate it. You’ll see output like that shown in Figure 15.48.
Figure 15.48 The current directory is identified.
The first thing the node should tell you is where it’s looking for the content files. If this is wrong or if it comes up with an error, close it down and check the script for errors in the pathnames.
The next thing you should see is the node complaining that it can’t open a job file (see Figure 15.49). This is perfectly normal because there isn’t one to open, but the important thing to note is that the node is running. If the render nodes still repeat the line "Can’t open job file" after you have initialized ScreamerNet, then they can’t find the command folder. Close them down and check the path in the script to the command folder. Make sure it’s visible on the network.
Figure 15.49 The node complains that it can’t open a job file.
Returning to the master machine, run the version of LightWave that uses the configuration files in config_screamernet and bring up the Network Rendering panel (see Figure 15.50).
Figure 15.50 LightWave’s Network Rendering panel.
The box called Maximum CPU Number requires you to enter the number of the highest-numbered node you have set up on your network. Here, there are 8 nodes, numbered 1 through 8, but you should put in the highest number of nodes you might have, such as 3. Nodes can be numbered from 1 to 1000; they don’t even have to be in sequence. You could have nodes 1,7, and 68 running, but if you do this, you would have to put 68 as your maximum CPU number, not 3 as you might think.
Now click the Screamer Init button. ScreamerNet checks for nodes that are sitting there complaining about job files! If successful, you are told how many CPUs (or render nodes) it has found. If the number isn’t correct, then check the job/ack numbering in the render script files and try again. If no CPUs are found, check that the nodes and Network Rendering panel are both looking for the same command folder, which should be visible on the network. Also, check that all machines have access rights to read/write to that folder.
If everything has gone well, the nodes should now be happily repeating, as in Figure 15.51.
Figure 15.51 Here is what the LWSN.exe output looks like if all goes well.
This means they have successfully found a job file with a command inside saying "wait there and do nothing!"
All that’s left to do now is to fill the Network Rendering panel with scenes, click Render, and watch it fly! So click the Add Scene to List button and browse to the projects you want to render. After you’ve added them all, you can click the button you have been waiting to click for a while now—Screamer Render (see Figure 15.52)!
Figure 15.52 When rendering, LightWave’s Network Rendering panel displays the current status.
The panel tells you what’s going on as it renders, such as which node is rendering which frame and how far through the rendering it is.
When all the frames have rendered, the render nodes sit there repeating the "LightWave command: wait" line. At this point, you can click the Screamer Shutdown button. This closes all the node windows. You should now have lots of frames in the save folder you specified earlier, ready for building into an animation.
Batch Rendering on One Machine
As mentioned in the early pages of this tutorial, ScreamerNet is also useful for batch rendering on one machine. You may find this to be more valuable than networking multiple computers. This is for users who don’t have a network but who need to render multiple scenes. This is extremely helpful for, say, rendering multiple camera angles or rendering multiple scenes over a long weekend. Maximize that time!
The good news is the process is no different from rendering with 1,000 computers. There is no bad news!
The overview of the folder structure for a batch render would look like that shown in Figure 15.53.
Figure 15.53 For batch rendering on a single machine, the node setup should look like this.
This setup assumes that all your content files are located in the main LightWave folder, that you copied all your config files to the new folder config_lightwave, and that you set the LightWave shortcut to point to that folder.
The only difference between batch rendering on one machine and network rendering is that all the pathnames to the config, content, and command folders can be local. You don’t need to rescan your plug-ins, either, because they are already set up for normal LightWave use.
Setting Up Batch Rendering on One Machine
Before attempting this, it is probably a good idea to read all the previous material in this topic (if you haven’t already) so that you are familiar with the terminology and concepts. We’re mentioning this just in case you’ve nipped straight to this section!
When batch rendering on a single machine, be sure that each scene file knows where the objects are located and that the objects know where the texture maps are located. This is one area where a proper content directory is crucial. Another important issue is to set up so that your scenes will save files. Do this from the Render Options panel and then save the scene.When ScreamerNet calls up the scene to render, it will know where to save the rendered images.
If you haven’t already created the folders screamer_command and screamer_save, do so now. Then create a batch file (node1) with the following text (replacing c:\lightwave\pro-grams\ with the path to your LightWave installation):
Load the scene files you want to render, set the Save RGB path to screamer_save (assuming you want to save them there), and then save the scene.
Now go through the process described in the section "Rendering Using ScreamerNet," which is essentially starting the render batch file. Then, in the Network Rendering panel in LightWave Layout, set the Maximum CPU Number to 1, click the Screamer Init button, add the scenes for rendering, and click the Screamer Render button.
Setting Up Multiprocessor Machines
If you have multiprocessor machines available on your network or if you want to batch-render on one multiprocessor machine, the process is the same and very simple!
All you have to do is treat each processor as a separate render node. We know that each render node has a batch script file that is run to identify that it is render node "X." So if a machine has more than one processor, it simply has more than one batch script but with different job/ack numbers. An overview of the setup for a batch render on a multiprocessor machine would look like what is shown in Figure 15.54.
Figure 15.54 A batch render for dual processors would look something like this.
Figure 15.55 shows what the setup for a network render involving multiprocessor machines would look like.
Figure 15.55 A setup for dual processors on a network would look something like this.
Troubleshooting and Limitations
Hopefully everything is running smoothly (if not, reread sections that don’t click until they do; it’s the only way!), but problems can occur, usually because something is set up incorrectly. Some of the main problems that might arise are listed in this section, along with possible remedies.
Plug-in Problems and Limitations
The biggest limitation of ScreamerNet is that of plug-ins that are not written to take advantage of it. To date, there is no definitive list of all the ones that do and don’t work. If in doubt, read the documentation that came with the plug-in; it should say whether it has problems. If it doesn’t say, but the plug-in still does not seem to be working, rescan your plug-ins to update the LWEXT9.cfg file. If it still doesn’t work, then chances are it’s not compatible with ScreamerNet.
If your scene uses procedural textures (fractal noise and so on), you might experience differences in the pattern if you render on machines with different processors. Mixing old and new processors or different brands, such as AMD and Intel, could lead to problems. This is really only a problem with animations because textures can suddenly change from frame to frame. If in doubt, run a test or use only computers with the same processor type.
Another known problem with ScreamerNet (corrected as of version 7.5c of LightWave) is its dislike for scenes that have had Spreadsheet used on them. Plug-ins like Spreadsheet save data to the scene file, which causes ScreamerNet to hang. The only way around this is to remove the entry in the scene file made by Spreadsheet.
Scene files are just text files; if you force-load a scene file into a plain text editor, you can read it!
Near the top, you will find an entry that says: Plugin MasterHandler 1 .SpreadsheetStandardBanks followed by: EndPlugin
There will be another entry right after that entry that starts with: Plugin MasterHandler 2 SpreadsheetSceneManager If you scroll down, there will be another: EndPlugin Highlight all the text between the first Plugin MasterHandler and the last EndPlugin, delete it, and then save the file. It should now render without problems.
Other Common Problems
This section covers other problems that you might run into and offers solutions for each. Problem:
"My nodes can’t find the job files." Possible solution:
The nodes can’t find the job files because they can’t see the command folder. The command folder holds the job files, so open up the batch file and check the script lines that end in "job" and "ack." Make sure that the pathname before these words points to your command folder. Also, check that all the render node computers have access to read and write to the folder.
"My nodes seem fine, but when I press Screamer Init, it can’t find any CPUs." Possible solution:
Again this is a command folder problem; check that the Network Rendering panel has the same command directory path set that the nodes are pointing to. Also, check that the master computer has access to read and write to the folder.
"Rendering seems to be working, but no files are saved." Possible solution:
First, make sure your scene file is saving RGB files and not an animation (MOV, AVI, and so on) in the Output tab of the Render Options panel. ScreamerNet can only save RGB image sequences.
Next, check that your plug-ins file (LWEXT9.cfg) is up-to-date by rescanning your plug-ins using the pathname all the nodes use to find them on the network.
Finally, check that the render batch files are looking in the correct place for the config files and that they can access the folder on the network.
"Rendering seems to work OK, but all my saved files are in FLX format."
There are two possible reasons. The first is that ScreamerNet can’t find the plug-in to save in the format you’ve specified, so check that your plug-ins file (LWEXT9.cfg) is up-to-date by rescanning your plug-ins using the pathname all the nodes use to find them on the network. Also, check that the render batch files are looking in the correct place for the config files and that they can access the folder on the network.
The second reason is that the render node that saved the file ran out of memory to load the saver plug-in, so ScreamerNet used the last-resort, built-in FLX saver.
To convert them, you can use LightWave as a converter; load the FLX images into LightWave using the Images panel, highlight the image in question, and double-click the preview to open it up in the image view. Now you can save in the format you need.
"My particles aren’t working."
ScreamerNet can have problems with particle FX. The best way to address this is to save the particle FX calculation to disk (as a PFX file) in the folder with the scene file.
"Dynamics aren’t working." Possible solution:
ScreamerNet might have problems with certain dynamics. The best way to address this is to save the dynamics calculation to disk from the File tab within the Dynamics tab under the Object Properties folder. Save this in the folder with the scene file.
The Next Step
As you’ve seen, LightWave has plenty of rendering power. These examples can help you maximize your use of your computer and network, as well as your time. There’s not much more to it, other than using moving images rather than stills. Use programs like NewTek’s VT3, Eyeon’s Digital Fusion, or Adobe’s After Effects, even Apple’s Motion for compositing final rendered images.