Support Portal

Introduction:

Most Mistika products have a "Add to render queue" button in the render panel, which permits to submit a batch of Mistika render jobs ( .rnd files ) to external render managers, or to pass those files to user defined scripts.

Please note that using external render managers require additional applications and additional configuration and it is not necessary for simple cases. If what you want is to just render a batch of shots then you can simply load all of them and use this function in the render panel: 

- Mistika VR:  Activate the All Shots button in the render panel 

- Mistika Boutique: Activate Split By Segments 

In this way Mistika will render all of them one after the other, without the need of a external render manager.

But if you need more powerful  management for the render jobs, then the Add to render queue  button is the right tool to use, in combination with a external render manager. This is explained in this document.

Note: Mistika Workflows have its own batch render capabilities and also a more specialized integration with external render farms that are not covered in this document. In fact Mistika Workflows is one of the destination applications that you may want to send .rnd jobs from VR and Boutique for automated processing, while in other occasions Mistika Workflows will act as a client for external render managers. But to keep it simple this document only applies to Mistika  VR and Mistika  Boutique, you can find more about Mistika Workflows automation in the Mistika Workflows manual

Note: In this document everything that is said about Mistika Boutique also works for Mistika Ultima when it is used in "external render manager" mode. But please note that Mistika Ultima also has its own internal BatchManager tool that is not covered in this document.

Add to render queue - Main Purposes:

- To integrate with external batch manager tools and external render managers. These are specialized applications that permit to organise and process your render jobs in different ways. For example, render jobs can be added to render queues for posterior execution (for example during the night), change their priorities, stop / resume jobs as needed, automatic retry, manage error logs and alerts, etc.  They are also specially usefull in case of unstable systems or not very reliable, so that a failing job will not prevent to execute the others, and failed jobs can be retried later automatically.  

- To use a external render manager to render a single enumerated sequence (.dpx, .tiff, .jpg, etc)  in parallel in multiple computers  (with each node rendering different frames of the same clip)

- To use a external render manager to render a different movie file (.mov, .mp4, .mxf .avi. ..) on each render node.  Most "Movie" files can not be rendered by parts like enumerated sequences, but movie files can still be distributed by ordering one movie file to each render node.

- In dual GPU systems, it can be used to render jobs in one GPU (by launching a render manager on it) while you continue using the other GPU for Mistika.

- To trigger user scripts to automate production workflows, while passing them the Mistika render scripts ( .rnd files ). For example to send .rnd files to Mistika Workflows product (which can render Mistika jobs and then perform other automated tasks with the rendered files)

Configuration in the Mistika side:

Mistika Workflows

Workflows has its own dedicated document for Deadline integration:

https://support.sgo.es/a/solutions/articles/1000323005

The rest of this document only applies to the other Mistika products, not to Mistika Workflows.

Mistika VR

The Render -> Add to render queue button works both in Current shot and All shots modes. In the second case, a whole batch of Mistika render jobs ( .rnd files) is created first,  and then a set of command lines are executed for each of the .rnd files in that batch.  

Mistika Boutique / Mistika Ultima

Depending on the Render->Split By Segments options the Render->Add to render queue button will create one .rnd per shot or just one .rnd for the whole selection , and then a set of command lines are executed for each of the .rnd files.  

Those command lines are stored in a configuration file,  SGO AppData/ProductName/runBatch.cfg, which is easily configured with this menu:

Mistika VR: File->Options->BatchManager->Configure menu 

Mistika Boutique: Render->Add to render queue->Settings Wheel   

The configuration menu provides a graphic interface to automate render jobs submission to most common render managers and other automation tools. Currently it provides examples to submit render jobs to Mistika Workflows,  Mistika BatchManager, Uberware Smedge, and ThinkBox Deadline.  (so that you don't need to create any command line to integrate with those ones)

A first example is to send the rnd jobs to Mistika Workflows, for which a trivial method is to simply use a Watcher Folder in Mistika Workflows to monitor new render jobs or the new media files that they produce, and then apply other actions to them (render, create multiple versions, deliver to client servers on internet , etc). The option to send the rnd jobs to a Workflows Watcher folder is already offered in the configuration menu explained above.

For more advanced usage or to integrate with other applications not mentioned in this document,  the user can put all the command lines that he wants to be executed for each new .rnd in the runBatch.cfg file

Supported Batch Managers & Render Managers:

In general both terms (Batch Manager & Render Manager) are used indistinctively, although we could differentiate by the purpose:

A "Batch Manager" is an application that provides batch processing management for different jobs submitted by other applications. 

A "Render Manager" is a Batch Manager specialized  on distributed render using multiple computers at the same time, while monitoring their progress and managing all aspects about render nodes and render jobs. 

Most of these applications are agnostic about the actual render software, which needs to be installed separately. In this context, the actual renderer (vr, mistika, or workflows)  can be connected to the render manager by providing a description of  its command line interface (CLI), which for the case of Mistika comes already integrated with some render managers but may require a manual configuration process for others (this is explained below).  

Once the render manager is also configured the user does not need to type any command line to submit render jobs, as the Add to render queue button will do it automatically. 

These are the render managers that are available by default:

- Mistika Ultima BatchManager ( send to Mistika Ultima ):  

It is the usual render manager that is available in all Mistika Ultima linux environments (these render farms are linux only, but you can still submit rnd jobs to them from any other platform ).  In these cases the Add to render queue button will create the Mistika render jobs ( .rnd files ) and it will copy them to a specified queue folder. This action is enough to submit render jobs to the Mistika BatchManager application, which is the one that will start the actual render processes.

The configuration file also offer parameters for "path translation", so it can replace local paths for the corresponding paths that are equivalent in the destination system before sending the .rnd job  (the complete instructions are in the runBatch.cfg file).  However, since v8.10 each Mistika installation also keeps its own configuration file with all the path translation pairs used in the past (when using the relink tool), so using the path translation in the runBatch.cfg file may not be necessary.  However you can use one or the other method as preferred.

- Uberware Smedge: 

It is a third party multi-platform render manager,  developed by Uberware. It works on Windows, Mac, and Linux. It is probably the easiest render manager to setup, as it provides a lot of automated configuration. For that reason we have also tried to simplify our side of the integration as much as possible. 

Please note that Mistika does not include licenses for any 3rd party render manager. At the date of this document Uberware Smedge is free of cost for the first 4 systems, while additional nodes require to purchase Smedge licenses from Uberware. 

The recommended installation procedure is as follows:

1 - First thing, make sure that all the render nodes are sharing common storage volumes for the source media files, Mistika projects and rendered files. Check that Mistika can read the media files from those volumes and also render to the planed destinations from all computers, otherwise nothing is going to work properly on the next steps (except if you plan to use Smedge in the local computer only , which also makes a lot of sense as a powerful Batch Manager ). 

2 -  In all the render nodes, install both Mistika and Smedge (you can find Smedge at  http://www.uberware.net/ ). 

Make sure that all nodes have the corresponding licenses as necessary, and test that they can render using Mistika manually as usual, without using the Add to render queue function yet (obviously, it does not make sense to try the integration functions with Smedge until Mistika is rendering correctly by itself).  

3 - (Optional): If you are not using Mistika default paths then you will need to modify the Mistika module for Smedge . Example .psx files are  attached to this document, but are also available in the "Modules" folder under the Smedge installation path (except for the case of Mistika Workflows, which will support Smedge from Mistika Workflows 10.6 version). Please note that once a .psx file is changed you will need to restart Smedge. 

4 - To submit jobs:

- From MistikaVR, press  File->Options->BatchManager->Configure 

- From Mistika Boutique: Render->Add to render queue->settings wheel (also available in MistikaConfig->BatchManager menu).

 It will offer several configuration options, just choose the one to Send .rnd jobs to Smedge. 

From that point, every time you execute the Add to render queue button it will submit the selected render jobs to Smedge.  

Note: The Smedge progress bar of each render job is based on counting the number of rendered files. As a result, enumerated sequences will show a smooth progression as it advances, but movie files will jump from 1% to 100% in one step. This is the expected behaviour in Smedge because a movie file is "just one file". However, you may still see the frame number being rendered in the metadata columns at the right of the progress bar. And if you need more detail Smedge also provides configuration options to show the actual progress bar of the renderer application and even its console output, although they are not visible by default.

- AWS Thinkbox Deadline:

The Deadline installation is not trivial at all, it is a powerful render manager but in general it requires advanced system administrator skills and significant dedication to customize it. However, once it is done configuring the Mistika plugin should not be complicated. 

For the particular case of Workflows, as said beofre it has its own dedicated document for Mistika Workflows integration with Thinkbox Deadline.

For the other Mistika products:

The following is an example for the integration of Mistika VR with Deadline: 

https://docs.thinkboxsoftware.com/products/deadline/10.1/1_User%20Manual/manual/app-mistikavr.html

Please note that the MistikaVR plugin that comes with Deadline is just an example of a possible integration and it is not updated often, so it will normally be obsolete.  Also it only covers the case of MistikaVR and not other Mistika products, and the Mistika executable paths have changed since the original document above.  As a result, at the very least you will need to make these changes:

1 - Install the latest Mistika plugin for deadline and adapt it to suite your needs. Attached is an example plugin for modern versions of MistikaVR, called MistikaVR.py, and also its MistikaVR.param companion (plugin configuration file). Both files are attached at the end of this document (the attached files are only valid for Mistika 10.5  and later versions) and they need to be placed in this folder of the Deadline installation:

DeadlineRepository10\plugins\MistikaVR

Deadline also requires to define the paths for each particular installation and specific Mistika product.  For example in the MistikaVR.param you can start with the example and change the paths to use the Mistika Boutique renderer rather than Mistika VR, or make more versions to create multiple plugins, etc.

2 - In the Mistika side:

Go to the Render->AddToRenderQueue settings wheel and select "Send Render Jobs to Deadline". First time you do it will create a runBatch.cfg file with your preferences in here:

SGO AppData/MistikaProductName/runBatch.cfg 

Then you will need to edit that file (the line calling to the Deadline submission script) to match the installation paths in your system (this only applies to Mistika Boutique and Mistika VR, not necessary for Mistika Workflows).  In one example the Deadline submission script is in here:

...DeadlineInstallationPath\DeadlineRepository10\scripts\Submission\MistikaVRSubmission.py

But it may change depending on your Mistika product and your installation paths.

They are all text files that can be easily modified, please check the Deadline documentation or contact AWS Thinkbox support if you need more hep. 

Compatibility with other render managers and workflow automation tools:

In addition to Smedge and Deadline, the Add to render queue  function in Mistika VR and  Mistika Boutique should be compatible  with any other render manager that permits to submit jobs via command line (CLI).  This is because the runBatch.cfg file permits to define the exact command line to execute  for each rnd job,  also passing the path to the rnd file and other common parameters in the command line (start frame, end frame, media paths, etc).  

A better way to integrate with other applications can be to use Python nodes in Mistika Workflows. This is a much more powerful and flexible method, but it requires Python programming.

Support services and trouble shooting:  

A characteristic of most render farms is that they are based on a combination of products from different manufacturers. Then, in the case of problems the first thing is to isolate which product is creating the problem (logically, each of the providers can only help you with the configuration of their own products). We recommend the following procedure to find where the problem comes from and which support services need to be contacted:

- First thing check that all your network and shared storage volumes are working correctly on all computers before installing any render farm management software , as network and permission issues  are the most common source of problems in a render farm. 

Specifically, test that you can can access all source  files and overwrite render folders from all the computers without any permission problems.  If you detect problems on this preliminary tests then please contact your  system administrator, and do not continue with the next points until this part works perfectly. It is highly recommended to start with a working network and fully operational network drives before installing any render manager software on it, otherwise their installer tools will fail to execute automatic configuration steps,  and when you finally fix your network and permissions you may still need a lot of manual configuration steps that were not solved by the installer.

- If the problem has appeared at a later stage, then a useful test is to configure your local system as the only render node, and test the connectivity between Mistika and the render manager locally on that single node. 

 If the integration between Mistika and the render manager works well on each computer  but not when you add them all together then the cause of the problem is probably a network problem or a security restriction (unfortunately most operating systems are becoming more paranoid day by day, and in many cases for no other reason that "just in case" ...). 

In particular, check that all your computers are discoverable in the local network, as many render managers will use that function. (for example in the case of Windows make sure to activate Network Settings->SharingOptions->Turn on Network Discovery).  And make sure that the firewalls and antivirus software are not blocking any necessary connection (if possible, deactivate them for a while and reactivate them when it works)

- Once the above problems are discarded,  check if Mistika can render normally on each render node using the shared network drives (without using Add to render queue or any render manager yet). 

- Once that Mistika standalone render is working well in all computers when using the shared volumes then the only piece that is left is the render manager configuration. That should be the last piece to be installed and configured,  and their documentation and support services should be the ones to be used  for this purpose.