Muster Console is the graphical interface to the Dispatcher Service. Each operation on the render farm and on the queue is performed through it.

Launch the Console. This can be done from the Start menu in Windows, from the Application folder in OS X and from a command line in Linux. You should see something like this:

The first thing you need to do is to log in on the dispatcher service, so click on the first icon on the left side of the toolbar. A connection window will appear:

Insert your dispatcher service host name or IP address, put admin as username and leave the password field blank, then click on Connect.

If the connection is successfully, you’ll get the Console interface:

The Muster Console interface is made by four different view panels:

The Instances/hosts view: This is the upper view in the screenshot above. This is basically a list of your available and unavailable rendering instances and can be configured in Instance or Host view mode. Consider an host like a physical machine, while an instance is an entity inside Muster. One host is able to spawn multiple instances. In this way, you can have simultaneous batch renders running on the same host and use multi core and multi processors machines even the batch render doesn’t support it. In Instance view mode, each instance has its own entry in the list, while in host view mode, instances are grouped under their host node. Operations that are pertinent to a single instance can be done in Instance view mode, while operations that are pertinent to the host , like starting and stopping services, are permitted in host view mode only.

This is an image of a typical view in host mode:

While this is an image of a typical view in instance mode:

The colored dot at the left of each instance shows the actual status of the machine. When the machine is idle and ready to render, it is green. When it’s idle but paused, it’s yellow. When it’s rendering, it’s red. After your first installation, you should have at least one instance with a green dot. If it’s yellow, you may have configured the client to start paused. You’ll change its status later.

The instances/hosts views can be filtered using the combo controls at the top of the view itself. You can also customize the columns by right-clicking on the view headers. If you’re working on a custom workspace (see the workspaces section) , each change you make in the view, will be stored persistently and left untouched at the next Console startup! This allows you to build your very customized workspace with multiple views filtered in different ways! Before going further, we’ll check that the hosts we are going to use have the correct paths configured. Just switch to host view mode, right click on a node and select Configuration→Configure. Once you get the configuration window, move to the Engines section, locate the Maya sw template we are going to use for this test, and verify that it’s correctly pointing to the Render.exe file required to launch Maya batch renders. Also check that it points to the correct Maya version, the one that you used to produce the scene file and that’s enabled with a checkmark near the engine name. Click on Ok and your configuration will be stored persistently on the host.

As said before, this configuration will apply to any instance belonging to the host and does not require a restart of the service. Your changes will be available immediately.

The next view, the one shown in the central pane contains the dispatcher job queue and it’s called Queue view. Jobs can be organized inside folders so it’s possible to have collapsed or expanded nodes. The icon on the left of the node shows the status of the node itself and in case of a folder, the overall status of the childs.

This is a typical queue view:

After your first installation, this view will be empty. You will need to submit some jobs to populate it.

The bottom pane contains the dispatcher internal log. It’s a resume of the most important events happened on the Dispatcher service. This is a typical log view:

You should always take a look at the log during the rendering process. Every error reported from render clients or directly from the dispatcher will be logged here and is your primary error detection tool.

The last pane, the one on the right, is the submission view. From this window you can submit new jobs, inspect parameters related to jobs inside the queue, load and save presets. The Submission view is a dynamic property sheet. It will change contents depending on the currently selected render engine:

You can configure the submission panel to automatically load the jobs selected in a particular queue view. Just enable the Load selection from view option at the top of the submission dialog.

To explain its functionalities, we will submit our first job!

Before doing that, we have to check that the internal Dispatcher engine is running.

The Dispatcher engine is the abstract object made by its internal functionalities. By stopping the Dispatcher engine, you stop any kind of future activity on the Dispatcher. It won’t stop any render in progress but will prevent the submission of new ones. Stopping the Dispatcher may be useful in those situations where you need to configure something on the Dispatcher itself and you don’t want any activity until you complete the configuration.

You can immediately check the activity of the Dispatcher by looking at the lower right corner of the Console. If you see a blue moving bar, the Dispatcher is active. If not, just start it by pressing the F10 key, or selecting the Change Engine Status menu entry in the Management menu.

Now check that our instances are available for rendering. If some of them have a yellow ball, it means they are paused. Just select them, right click on one and select Resume. They should change to the idle status and show a green ball.

As a last step, we want to exactly check what’s outputted from the instances during their render, so right-click on the instance you’re going to use, and select Realtime Log Streaming → Enable and Open view. By selecting this menu item, Muster Console will open an output window that will dump the output from the processes spawned on the remote host:

We are ready to select our rendering engine from the submission view. In the general section, locate the Engine combo box, and select “Maya sw” as the render engine. This will tell Muster to render using the Maya software rendering.

Next, select the job file by clicking the button on the right of the Maya scene filename field, in the Maya Sw section of the submission panel (notice that this section has been dynamically built if you had a different render engine selected).

Pick up the file from the network, you should have something like \\MASTER\RENDERFARM\MUSTERTEST\SCENES\TEST.MB inside the field. Muster will detect automatically the project path and will set it to \\MASTER\RENDERFARM\MUSTERTEST

Set the starting frame to 1 and the ending frame to 10. Because we want to send the job to an high number of instances, set the packet size to 1.

The packet size value controls how many frames are assigned to a single instance for each render session (a chunk). Under production, a value of 4 is often a good compromise.

Click on submit and you should immediately see the job appear in the queue. If it has a yellow ball, just right click on it and select Resume.

Congratulations, you’ve sent your first render job. In a few minutes, you should get all your instances back to idle and the frames successfully rendered inside the images folder of your project.

During this example, you watched the output from the batch renders using the real time log feature. But what about checking the logs of completed packets ? No problem, just open the Workstation Logs menu item right clicking on your host and you’ll get the Log’s inspector:

The logs have the solution to your problem. Muster is not able to always understand what’s going on during a batch rendering process. The output from the batch render always contains enough hints to understand why a particular job is failing!

You can start playing with the various Muster parameters or move to the reference section of each module to gain a deeper knowledge of the software.

If something went wrong, we suggest you to check carefully each section of this chapter and verify your steps. If you still can’t get a valid result, check the Troubleshooting section at the end of this manual.