ScreamerNet Controller Version 3.1 Features:

• OS X Universal Binary - The best Screamernet controller for OS X!
• Work in Lightwave while renders are running - The controller can be run in the background while you are working in Lightwave in the foreground. Use the free Lite version to batch render while you are working on other scenes. Or, using a licenced version, render across your whole network while you are working on other projects.
• Free Lite Version - The free Lite version allows you to control a single node. This is ideal for rendering in the background while you are working in Lightwave. When you are ready for a larger network, simply upgrade to a higher version.
• Mixed - platform rendering - The ScreamerNet Controller will control PowerPC Mac, Intel Mac, as well as PC nodes.
• Control Mac nodes without having to share your root drive - The controller automatically remaps the path for your remote Mac nodes so you only have to share your public folder.
• Adding and removing scenes - Dynamically add and remove scenes without stopping the current render. CPUs that are rendering a scene that is removed will finish the frame they are on and then go to the next scene in the queue. If you add a scene to the top of the list, rendering nodes will begin rendering the new scene as soon as they are done with the frame that they are on.
• Edit scene info - When you open a scene, you can revise the start/end/step as well as the file saving location.
• Mix frame render order - You don't have to render in order. Skip every nth frame until the render is complete to give yourself a view of the whole scene before it is completely done.
• Re-arrange scenes - Drag and drop the scenes to re-arrange the order in which they will render.
• Drag and drop scenes - Drag and drop scenes right from the desktop into the scene queue.
• Saves scene queue - The controller automatically saves the render queue after each rendered frame and on exit. The next time you start up the controller, it will ask if you want to restore the queue, and then pick up where it left off.
• Detect rendered frames - When a scene is loaded, either by opening it or loading it from the queue, the controller checks to see if any frames have been rendered since the most recent modification of the scene. If they have, you are presented with an option to only render missing frames. This is ideal when you have a handful of bad renders throughout a long sequence. Simply delete the bad frames, re-load the scene into the controller, and tell it to render only the missing frames.
• Automatic render verification - The controller checks each frame as it is rendered to make sure it was saved to the disk. If it wasn't, the controller will re-initialize the node and try again.
• Log file - The controller writes out a log file for each frame. This comma-delimited log file can be loaded into a spreadsheet or used with other third-party render log analysis tools.
• Turn scenes off - Have a big scene you only want to render while you are gone, but smaller scenes to render sooner? You can turn any scene off so that it won't send any frames to the CPUs. It still saves with the queue, and when you turn it back on it will pick up right where it left off.
• Name your CPUs - Give your CPUs names so you don't have to remember their numbers.
• See CPU speed - Check out how your render nodes stack up against each other. Each CPU displays a percentage of its speed based on the average of each CPU and each frame of the scene.
• Render time estimation - Uses historical data to estimate the completion time for each frame as well as the entire scene.
• Detect crashed CPUs - Determine, by a percentage of the expected render time, how long to wait on a CPU before assuming it has crashed. For example, if a CPU is expected to render a frame in 10 minutes, the controller can assume it has crashed if it hasn't completed the render in 200% of the expected time, or 20 minutes.
• Automatically shut down a CPU - Set a time that the CPU should be shut down by. If an incoming frame is expected to take more than the available time to render, the CPU will shut down. For example, if you have a CPU set to shut down at 8:30am, and at 8:10am the CPU receives a frame that is expected to render until 9:00am, the CPU will not render the frame, and instead will shut down.

Do you have a feature request that would make the ScreamerNet Controller more useful to you? Drop us a line and let us know. Our goal is to make the ScreamerNet Controller as functional and helpful for you as we can.