Configuration settings for Tentaculo consist in creating a configuration file in the json-format and then uploading it to Cerebro.
In order to upload a configuration file to Cerebro:
After the upload is completed, Tentaculo configuration will be available to all users in your universe.
Note:
In order to make sure that the configuration is correct, it is recommended to use the debug mode first.
Configuring the Tentaculo configuration consists of the following parts:
configuring the file storage access protocol. To do this, you need to fill in two sections in the configuration file:
-protocol – list of storage access protocols;
-project_path – list of projects' root paths.
configuring the naming convention. To do this, you need to fill:
expansion expanding Tentaculo features:
The protocol variable allows you to configure file access protocols; note that different values are possible depending on the application in which the plugin is launched.
Element structure:
"protocol":
{
"all": [],
"cerebro": [],
"maya": [],
"nuke": [],
"houdini": [],
"blender": [],
"cinema4d": [],
"3dsmax": [],
"katana": [],
"revit": [],
"autocad": [],
"tbharmony": [],
"tbstoryboard": [],
"photoshop": [],
"aftereffects": [],
"indesign": [],
"illustrator": [],
"animate": [],
"premiere": [],
"flame": [],
"fusion": [],
"clarisseifx": [],
"unreal": [],
"substance": [],
"vegas": [],
"tdequalizer4": []
}
The key is the internal name of one of the supported applications ("cerebro", "maya", "nuke", "houdini" и т.д.), and the value is a string containing a protocol name or a list of protocol names. All key allows you to set the protocols for all possible programs at once, including Cerebro. If you need to specify an individual file access mode for any of the applications used, then you need to set your own protocol, different from the all one.
Note:
A value must be specified for the "cerebro" variable so that Cerebro application could independently determine which protocol it will use to access files. Otherwise, access to the file storage from Cerebro application will be denied. This is done to control access to your main file structure.
Possible protocol variable values for different applications:
Important:
To work with the Git protocol, the user's computer must have the Git client installed (https://git-scm.com/downloads).
Access protocol to remote repositories are supported http/https.
The description string follows this pattern:
"git:https://{remote git repository address}/{group name}/{repository name}:{working branch name}:{file working mode}"
{remote git repository address} — is the address of the git repository where remote repositories are located.
{group name} — is the name of the group the repositories belong to. The group can be omitted or contain subgroups, separated by a backslash.
{repository name} — is the name of the Git repository. It can be specified in the protocol or in the project_path section for each project if you are using multiple repositories for different projects.
{working branch name} — is the name of the branch in which work is being done. It can also be specified in both the protocol description and the project_path for each project.
{file working mode} — is the mode in which Tentaculo works with files in the repository.
Three working modes are supported:
version (default) — versioning occurs at the file level. When publishing a new version, a new file is created with the version number in the name (settings through file_path). For example, for the file photo_v01.jpg, the new version will be a new file photo_v02.jpg. In this mode, the entire project is fetched into the local repository, and only new version files are sent when publishing.
revision — the file version is determined by the revision in Git. Work is done with the same file, which is updated by the git commit command. In this mode, the entire project is fetched into the local repository, and only one file, which was being worked on, is sent when publishing.
project_revision — file versions, just like in revision mode, are determined by the revision in Git. The difference is that when publishing, all changes within the project are sent. This mode is needed for working with projects that involve changing many files at once when working with them.
You can set one or more protocols for each application, including Cerebro. For example, you might have a network drive that is accessible both on the local network and via FTP. In this case, you can set two protocols:
"cerebro": ["network", "ftp:ftp://mycompany.com"]
Additionally, when trying to access files, the user will be able to choose the protocol that suits him best – depending on where the user is at the moment, whether it's the office or a remote location.
The project_path variable contains a list of elements that describe the root paths to project files:
"project_path":
[
{
"project_name": "",
"task_activity": ""
"paths": []
}
]
Each of the elements describes possible file paths to the project's root directory and contains the following fields:
project_name – project name in Cerebro. If an empty string is specified as a value, then this structure contains default values for all projects that are not described in other list structures;
task_activity – the name of the activity. If the path leading to the root directory depends on it. For example, files for different types of activities can be stored on different servers. An empty value also means that the described paths are by default applicable to tasks containing any kind of activity;
paths – are the list of possible paths to the root directory. The path format depends on the protocol. Several paths can be set depending on access to the project repository from different remote work locations.
folder_path — allows separate file storage paths within a project. This enables the separation of scenes, assets, and other data.
Example:
"project_path": [
{
"folder_path": "/Project/scenes",
"paths": ["network://projects/scenes"]
},
{
"folder_path": "/Project/assets",
"paths": ["network://projects/assets"]
}
]
Priority order:
Network protocol
For this protocol, paths are set in standard operating system formats. For example, if you need to set the root path for several operating systems, use multiple entries:
"paths":
[
"//server/projects", // for Windows
"/Volumes/projects", // for MacOs
"/server/projects" // for Linux
]
FTP protocol
For this protocol, use the prefix ftp://. The path is specified from the address indicated in the protocol, for example:
"paths":
[
"ftp://projects" // for FTP
]
Since users working on the same project may have different access methods, such as in a local network or remotely, multiple paths can be specified for various protocols that refer to the same location. For example, if projects in the local network are accessible via a network path and remotely via FTP, the paths can be written as follows:
"paths":
[
"ftp://projects", // for FTP
"//server/projects", // for Windows
"/Volumes/projects", // for MacOs
"/server/projects" // for Linux
]
SFTP protocol
For this protocol, use the prefix sftp://. The path is specified from the address indicated in the protocol, for example:
"paths":
[
"sftp://projects" // for SFTP
]
S3 protocol
For this protocol, use the prefix s3://. The path is specified from the address indicated in the protocol, for example:
"paths":
[
"s3://projects" // for S3
]
Note:
For cloud storage connected via the S3 API, the project_path is usually not required, as there are no actual folders in such storage, only tags that mimic them.
yadisk protocol
For this protocol, use the prefix yadisk://, for example:
"paths":
[
"yadisk://projects" // for Yandex Disk
]
gdrive protocol
For this protocol, use the prefix gdrive://, for example:
"paths":
[
"gdrive://projects" // for Google Drive
]
dropbox protocol
For this protocol, use the prefix dropbox://, for example:
"paths":
[
"dropbox://projects" // for Dropbox
]
Git Protocol
For this protocol, use the prefix git://.
Path entry format:
"git://{repository_name}:{working_branch_name}:{file_working_mode}"
These are the same parameters that can be set in the git protocol, under the protocol section. If different repositories are used for different projects, they need to be defined in paths.
For example, for the myproject project, the repository myproject.git is used, with the working branch trunk and the working mode project_revision, meaning the entire project is updated as a whole.
"paths":
[
"git://myproject:trunk:project_revision" // for Git
]
Сargador protocol
For storage Cargador project_path is not required, as root access is determined by the storage itself.
The file_path variable contains a list of elements describing how tasks in different branches and projects match your file structure:
"file_path":
[
{
"folder_path": [],
"task_activity": "",
"name": "",
"name_editable": false,
"publish": "",
"version": "",
"ver_prefix": "",
"ver_padding": "",
"use_local": true,
"local": "",
"local_postfix": "local",
"use_review": true,
"review": "",
"review_postfix": "review",
"publish_status": "",
"lock_in_progress": true
}
]
Each of the structures describes a set of subfolders and a file name template which are used to store file versions, and it contains the following fields:
The folder_path and task_activity variables are, in fact, the key for task mapping in Cerebro, when files are either shared or downloaded. The rest of the variables determine where the files for this task should be located.
If the value of the publish or version field is not specified, then when the file is sent to the storage, the main or the numbered version of the file respectively will not be created.
Any components of the file_path variable can contain the following substitutable variables:
Example: "publish": "/$(task_parent_path)/$(date{/%Y-%m-%d/})"
Result: project/scenes/sc_01/2025-02-28
For substituted variables, there is the possibility of partial definition and support for regular expressions.
To highlight a part of a variable, use the syntax $ (variable_name [i: j]), where i and j are the starting and ending index in the string.
For example:
$(task_name[0:8]) — select part from position 0 to 8.
When the task name "modeling_main[0:8]" we get "modeling".
To highlight a part of a variable, you can also use regular expressions, while the first group from the regular expression is selected by searching for the first match in the string.
Syntax:
$(variable_name{/regexp/}), where regexp - regular expression.
For example:
$(task_parent_name{/_(.*)/})-— select the part after the character ‘_’.
When the parent task is named "asset_main{/_(.*)/}" we get "main".
In formatted strings, you can also use the operating system's environment variables if their names do not match the variables listed above. Their application format is the same: $(VARIABLE_NAME).
The value of the soft_folder variable is set depending on the application in which the files are created.
Element structure:
"soft_folder":
{
"maya": "",
"nuke": "",
...
}
The key in a set of paths is the internal name of one of the supported applications («maya», «nuke», «houdini» и т.д.), while the value is a string containing the variable value. It is used in the file_path section to specify file paths or file names, depending on the application in which the files are created.
Note:
Please, note that the keys do not list cerebro, since Cerebro application does not create files. When you share files using Cerebro application, the soft_folder value will be determined by the file extension corresponding to any of the supported applications.
The variables contains a list of user variables that can be used in file_path to describe file paths.
Element structure:
"variables":
{
"my_assets_path": "/$(url[0])/assets",
...
}
Next, the variables you described can be used in file_path:
"file_path":
[
{
"publish": "$(my_assets_path)/$(task_parent_name)",
"version": "$(my_assets_path)/$(task_parent_name)/versions",
...
}
...
]
You can use variables in the variables list inside the same section.
For example:
"variables":
{
"main_path": "/$(url[0])/$(task_parent_name)/$(task_name)"
"publish_path": "$(main_path)/publish"
"version_path": "$(main_path)/versions"
}
The version_save variable defines what to do with the work file when saving the version — save, move, or always ask the user. The parameter can be defined for each app in which versions are saved.
Element structure:
"version_save":
{
"all": "",
"cerebro": "",
"maya": "",
"nuke": "",
...
}
Possible values:
The default value is 'status_question'.
The trans_mode variable allows you to enable transliteration of file paths corresponding to tasks in Cerebro – depending on the application in which the files are created or shared.
Element structure:
"trans_mode":
{
"all": true,
"cerebro": true,
"maya": true,
"nuke": true,
...
}
Possible values: true, false. Transliteration is enabled by default.
When transliteration mode is enabled, all non-Latin characters in the file path are automatically converted to Latin characters, while spaces are converted into underscores («_»). For instance, instead of the /Project 01/Моделирование path, there will be used the /Project_01/Modelirovanie path.
The case_mode variable allows you to determine the case of letters of file paths corresponding to tasks in Cerebro, depending on the application in which files are created or uploaded.
Element structure:
"case_mode":
{
"all": "",
"cerebro": "",
"maya": "",
"nuke": "",
...
}
Possible value: "", "lowercase", "uppercase", "capitalize". The default value is empty. An empty value means that the case of letters in file paths will repeat the case of the corresponding tasks in Cerebro.
The optional variable allows you to set task filtering parameters for each app.
You can set the following filters for each app:
Element structure:
"filters":
{
"all":
{
"status_filter": []
"activity_filter": []
"tree_hide_list": []
},
"maya": {},
"nuke": {},
...
}
status_filter – the variable allows you to set a list of statuses in order to filter tasks in Todo List. Standard filtering displays tasks in all statuses, except the stopped ones (work stopped). The variable type is an array of strings. In this filter, you can specify the filtering of tasks with no status by selecting the No Status option.
Example:
"status_filter": ["No Status", "ready to start", "in progress"]
activity_filter – the variable allows you to set a list of activities to filter tasks in Todo List. The variable type is an array of strings. In this filter, you can specify the filtering by tasks with no activity type by selecting the No Activity option.
Example:
"activity_filter": ["No Activity", "animation", "compose"]
tree_hide_list – the variable allows you to set a list of tasks hidden from the plugin users in Todo List and Browser tabs.
The variable type is an array of strings. Supported expressions:
Example:
"tree_hide_list" : ["/Project 1/{*}/Shot{?}{?}/animation", "/{*}/Task {?}/Work"]
An example of setting up task filtering for the Maya app:
"filters":
{
"maya":
{
"status_filter": ["No Status", "ready to start", "in progress"],
"activity_filter": ["No Activity", "animation", "compose"],
"tree_hide_list": ["/Project 1/{*}/Shot{?}{?}/animation", "/{*}/Task {?}/Work"]
}
}
The optional variable allows you to specify the full path to the Mirada app for each operating system, providing the ability to add thumbnails for attached files of supported formats. By default, Tentaculo searches for Mirada in the directory of the installed Cerebro app.
Element structure:
"mirada_path":
{
"windows": "",
"linux": "",
"darwin": ""
}
Example:
"mirada_path":
{
"windows": "C:/Program Files/Cerebro/mirada.exe"
}
The optional processors variable defines a set of python scripts that are additionally executed when performing actions in the plugin, such as opening a file, creating a new file in a task, saving a version, publishing a report (see the Processors section), and so on.