View Full Version : ScreamerNet OSX Controller version 3.2.3 Released

03-21-2003, 11:33 AM
We are pleased to announce the release of the ScreamerNet Controller for OS X Version 3.2.3! This version corrects a few minor nuances as well as introduces a few new features. The new features include the ability to have spaces in your save path names (version 3.2.2 eliminated this capability) as well as the ability to change the output file format when you load a scene. The new version may be downloaded at:


For those who are not familiar with the ScreamerNet Controller, it is a front-end controller for Lightwave's LWSN. It controls both PC and Mac nodes, allowing dynamic introduction and removal of nodes and scenes without having to abort the current render. The free Lite version will control one node, which is ideal to have running in the background while you are working in LightWave in the foreground. Some other key features include:

* 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.

* Name your nodes (instead of 1, 2, 3, etc...)

* Add, remove, reorder scenes without stopping the current render.

* Edit your scene information when loading - revise the start/end/step info, as well as the file saving location and output file type.

* Mix frame render order - skip every nth frame until the render is complete, to give yourself a view of the entire scene before it is completely done.

* Saves the scene queue - if the ScreamerNet Controller crashes or you have to shut it down, the scene queue is saved and will pick up where it was left off.

* Detect rendered frames - For each scene, the ScreamerNet Controller checks to see if there are any frames already rendered. If it finds any, you are given the option whether or not to re-render them. This is ideal if you have a small scattering of bad renders, simply throw them out and re-render the scene. Only the missing frames will be rendered.

* Automatic Render Verification - The controller checks each frame as it was rendered, and verifies that it was saved to the disk. If it wasn't, it will re-initialize the node and try again.

* Log file output - You can write a log file for each frame, detailing each frame, what computer rendered it, and how long it took. This comma-delimited log file can be loaded into a spreadsheet or other third-party render log analysis tools.

* Temporarily disable scenes - If you have a big render going on, but only want it to render at night, you can turn it off while you send smaller scenes to the nodes during the day. When you turn it back on, it will pick up right where it left off.

* See each CPU's speed - The relative speed of each CPU is tracked after every frame.

* 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.

Also included is a tutorial on how to set up your OSX render farm either by mounting the entire host drive, logging in as a guest, or using a PC.

03-21-2003, 12:37 PM
thanks for the update Jon!
also, have you seen reports of increased SNCspeed underX.2?
the reason i ask... i had a dual 800 with a drive failure this week(Xvol)
replaced the drive and moved forward to X.2.3 fromX.1.5.
and put the "farm" back into action last night, and before retiring for the evening checked on progress to find that the DP800(X.2.3) is now "outrendering"a DP1000 host(X.1.5) by 15 to 20%?
not a complaint....just curious:D

03-21-2003, 12:52 PM
I've not done any testing to see whether or not that is the case, although it doesn't suprise me as Jaguar definitely has increased the speed of other applications (even just the user response) - no formal testing, though :cool: