OPTIX Render Bot

Development started on renderBot after a suggestion was brought up by our Senior Render Artist and personal friend, Amin Bakht. We take advantage of our render nodes located on the renderfarm religiously, and when times are tough, we would need to expand our processing power to individual workstations. This turned out to help us enormously, so we looked in to the best way to take advantage of our workstations every time they are not in use. This translates to us using the maximum processing output that our department can produce at all times. Asking the artists to turn on their backburner servers before they leave their workstations was much more difficult than it sounded. As you can imagine, this is the last thing on their mind when they pack up and take off. Additionally, some artists may leave their workstations for an extended period of time during working hours. To sum it all up, whenever a workstation is not in use, it should be available to take on jobs distributed by the server, and developing a tool to do this well help us accomplish just that.

Function Details

There are a few attributes that I needed to implement in this application to make it do what we want it to do. It needs to run on system startup, as a background process that can be terminated, for whatever reason, through the notification area in the taskbar. It also needs to read a setup file that holds two things: the path to the server application and the given idle time. This file should be accessible from multiple renderBots so that if it is changed, all workstations running the renderBot will update their settings accordingly. So heres the breakdown:


Read File / String Conversion


I started with the basic function of pulling information from a file and using that information correctly.

The lines read will be automatically placed in a String, which isnt a problem considering the fact that a filepath is essentially a string, because of any spaces that could be included in folder names, but idle time will need to be numeric data that needs to be calculated and used for logic statements


    Local $localSetupFile = FileOpen("OPTIX_rB_localSetup.ini", 0)
    ; Check if file opened for reading OK
    If $localSetupFile = -1 Then
    	MsgBox(16, "OPTIX renderBot v1", "Problems with opening the local file.")
    ; Reads 2 lines and places them in different variables accordingly
    Local $localSetupLine = FileReadLine($localSetupFile)
    Local $localSetupPath = $localSetupLine
    Local $localSetupLine = FileReadLine($localSetupFile)
    Local $localSetupIdle = $localSetupLine
    ; Temporarily calculates idle time to verify if it is a number
    Local $idleTime = Number($localSetupIdle)
    Local $calculated = $idleTime + 5
    ; Returns information to screen
    MsgBox(64, "OPTIX renderBot v1", "Global File Location: " & $localSetupPath & @CRLF & "Idle Time Duration: " & $idleTime & @CRLF &
    "Idle is Number because: 5 + " & $idleTime & " = " & $calculated)
    ; closes file

Idle Time / Write File

Writing a file is as easy as opening and reading from the file. We just need to declare different flags when opening the file and, depending on what you want to do, clear the file and re-write the parts with updated information. Now, there really isnt any reason to write to a file because of the simplicity of this program, but it does add a luxury to the whole mix. Since this program will be applied to multiple workstations, and they are all connected to a single .ini file somewhere on the network, whenever a change needs to be made a person would have to find that .ini file, open it in a text editor, change the variables (making sure its formatted correctly) and finally close and save the file. This could get tedious and also narrows the changes to someone who knows how this program works. So if I were to implement some sort of edit button in the taskbar (where the logo is) that is linked to the global file using the local path given, the user of any specific machine has the option to adjust the idle time / server path, which will ultimately change all renderBots across all workstations (since it will be configuring the global .ini file). This could be extremely handy when streamlining any changes across all machines.

Finally, the last mechanism is to get a working idle time checker. This feature scared me the most, because essentially, we are dealing with workstations, and workstations need to be processing at its maximum. We dont want a background application to be using much of its system resources just to check if the keyboard/mouse is idle. So I’ve used many different attempts to filter out the fastest, most cleanest way to check for system idle, without compromising the features needed in the application. (Everything from processing mouse-movements to pixel region comparison on the screen!)

GUI and Features

After formatting all of the code and removing any redundant lines to clean up the app a little, I got to wrap it all up in to a little GUI so that it is much easier to check, change, and test all of the features. I wanted to be able to change the Global Path, Server Path, and the Idle time on the fly, and to check them immediately after on all machines to make sure they have all been updated with the same information. I also needed an information button to show what the settings are currently at, so anyone can quickly reference these things without having to browse and find the configuration files.