Smedge does not try to move any files around for you. For your farm tasks to succeed, the rendering machines must all be able to access the source data using the same paths for all production content, scenes, caches, source files, and so on. This is usually handled with some kind of file server, SAN, or NAS device mounted in the same way on every machine. The details of setting up file servers are beyond the scope of this documentation, but basic instructions can be found online if you need.
Smedge can handle cross-platform differences for how the storage is accessed, but all Windows machines should use the same path and all Linux machines should use the same path, even if the Windows and Linux paths are different from each other. See Cross-Platform Setup.
Most third-party applications will automatically be detected and used by Smedge if you have installed them in the default locations. If you need to customize where various applications have been installed, you can do so in several ways. The most common is to follow these steps:
Select all of the Engines in the SmedgeGui
Use the menu command Engine > Configure Product Options
Find the product you want to modify
In the Path to the Executable field, put the path to the appropriate render executable program file
(Repeat steps 3 and 4 for other products if needed)
Click Apply and Close
To reduce the Smedge overhead when a machine is primarily being used for rendering and not as an active interface to the system, Smedge includes a feature called “Engine Mode” where the GUI disconnects itself from the Master, and shuts down any redundant backup Master running on the machine. In this mode, the machine runs with about the same overhead as if you ran just the SmedgeEngine component manually.
Automatic Engine Mode kicks in after a certain amount of time without any interaction in the GUI. The amount of time is configurable at the system level in the Administrator Options dialog box, and can also overridden for a specific machine in the SmedgeGui options. You can also manually enter Engine Mode using a menu command in the system menu.
If your computer’s name includes one of the words: “render”, “node”, “blade”, or “smedge” and a number, or consists only of numbers, Smedge assumes that this machine is primarily meant to run as an Engine, and the GUI will start in Engine Mode by default the first time you start Smedge. You can always use the Connect menu command to run in normal mode.
For successive runs, GUI will run in the same mode as whatever the last mode it was in when it shut down. Note that the Master component is also stopped in Engine mode, unless your machine is the primary Master machine. When you restart a machine that was in Engine Mode, the Master component is not started with the GUI, and is only restarted when you try connecting if your machine was previously the Master when it last shut down.
In normal usage, this is not a problem. If you generally start the same machines up in the same modes, things will work consistently. If you end up with no Master on your network, you will need to manually start the Master on at least one machine. If that machine was not the master or an up-to-date mirror the last time it was running, you may have out of date job information. If you find this to be the case, you can stop that master and try starting it on a different machine that may have been up-to-date.
Smedge communication is encrypted using perfect forward encryption included with the networking library used internally (ZeroMQ). This security uses a public/private key encryption mechanism. By default, the Master uses a built-in private key, so every user gets encryption automatically by default. However, since this private key is shared by all installations of Smedge, it’s not truly secure unless you generate your own key pair. You can use the SmedgeMaster command line to generate a new truly random private key, which gives you complete security.
Use this command to generate the public and private key file:
SmedgeMaster -keygen
This will generate 2 files:smedge_public.keyandsmedge_private.key.Move the private key file into a folder where the Master can read it on startup. Commonly you can use the Master “Machine Folder” or the Smedge program folder
Copy the public key file into a place your clients will read it. The Smedge program folder is usually the best place.
As long as you use the matched public and private key files on your network, any client on any OS will be able to connect and communicate correctly. Any mismatch in the keys will result in the client not being able to connect to the system at all.
When you are mixing multiple operating system platforms together, any Smedge component application can be run on any platform and they all interconnect together. However, because each platform handles access to network resources differently, there are some additional steps that are required for completely transparent multi-platform operation.
The key to making Smedge work across multiple platforms is to tell the system how to translate the different access systems that you are using on your site. For example, if your project files are generally kept on a file server that is mounted on a Windows drive letter, you would tell Smedge the drive letter that you are using on Windows, and the mount point on a Unix file system that a Linux or OS-X machine uses to access that same file server.
To configure path translations, follow these steps:
In the SmedgeGui, choose System > System Commands > Configure Master…
Select the Path Translations tab
Click the Add button
Use the fields to supply the “root” part of the path for each operating system.
If you access the file with X:\job\scenes\file.mb on Windows and /Volumes/Jobs/job/scenes/file.mb on Mac, the root is the part that differs:X:for Windows and/Volumes/Jobsfor Mac.Click OK to add this translation to the list.
Click OK again to send the updated options to the Master.
The Python API lives inside the Smedge distribution. The most common way to make it available is to set your PYTHONPATH environment:
| Platform | Environment |
|---|---|
| Windows | set PYTHONPATH=C:\Program Files\Smedge\python |
| Mac | export PYTHONPATH=/Applications/Smedge.app/Contents/MacOS/python |
| Linux | export PYTHONPATH=/opt/smedge/python |
Some environment variables that can configure the Python API:
| Variable | Meaning |
|---|---|
SMEDGE | Override the Smedge program folder location (default assumes the code is in the default deployment location). |
SMEDGE_MASTER | Override the Master location. You can specify the master hostname or IP and optionally the port. |
SMEDGE_MASTER_PORT | Override the Master port (default is 6870). |
SMEDGE_LOG_LEVEL | Set the log file level (default is 5, debug level is 6). |
SMEDGE_CONNECT_TIMEOUT | Set number of seconds the CLI tool will wait trying to connect before returning a failure (default is 10). |
Further documentation can be found online:
https://www.uberware.net/support/python-api/
Please contact support if you would like access to Smedge source code or help building more sophisticated integration than the CLI or Python API can provide. Smedge uses a C++ library architecture where most of the important common functionality is in a library that you can use to communicate as a Smedge component application doing whatever you want.
On Windows, Smedge integrates with the programs control panel and includes an uninstall script, which can be accessed through the standard control panel, or via the shortcut in the Start menu.
On Linux, use the standard RPM management tools to remove Smedge.
On Mac, you can drag the Smedge app icon to the Trash to remove Smedge.
Uninstalling Smedge cleans up all of the program files and common system data. It will not clean up log files that were generated with your scene files during renders, and it may not clean up log files and preferences in each user’s home folder (or equivalent) on each platform.
Smedge only touches the file system, so you can always remove Smedge simply by deleting all of its files.
If you have any questions about removing Smedge, you should contact Überware technical support.