The Preferences View

The Preferences View gives you the ability to configure many aspects of the Aria system and shape network. Primarily the Preferences View provides a GUI for the configuration file that Aria looks too when naming nodes and working with splits and disk paths. The configuration file (or INI or .ini) holds certain sections that Aria will introspect when building out a shape network. For convenience we have provided the following GUI elements so a studio can easily create a configuration file right from within Aria.

The Preferences View is separated into sections - each with its own representative section in the configuration file. The terms "configuration file", "INI" and "Preferences File" are interchangeable within the Aria workflow context.

The Preferences File

At the top of the Preferences View is the listing for the path to the Preference File. Notice in the image above that the "preference file" is called "face.ini". As mentioned before the configuration files used by Aria are in the .ini file format so we can easily leverage the configuration parser within Python. For end users it is considered the preferences file. From the toolbar you can load a preferences file using the folder icon, save the current settings set in the GUI as the preferences file using the disk icon. You can also manually edit the ".ini" file (not recommended for end users). If the ini file has changed on disk you can load in those changes using the refresh icon to the right of the disk icon.

The Name Template

The Name Template section is where the name object model displays its properties for use when Aria builds the shape network. The naming settings listed here will determine the name of the blend shape target when the network is built. 

Long Name Separator

This property holds how various name elements should be separated - it is a delimiter. For example, if we created a combination node made from the jawOpen primary and the lipPucker primary the name of the combination node would be "jawOpen_lipPucker" where the "_" is the separator between the driver names.

Short Name Separator

This is exactly the same concept as the long name separator but for use in short names. This is convenient when using short names on combination nodes and could make the network more readable on the blend shape node. For example a combination node that is comprised of jawOpen and lipPucker would have a long name of "jawOpen_lipPucker" with the long name separator being used between the two upstream primary driver nodes. For a short name representation the same combination would be listed as JOxLP (jawOpen's short name, short name separator, lipPucker's short name). 

Split Maps Separator

This property holds how split maps names should be separated from other name elements. For example, if browFurrow has been split left and right then the name of the browFurrow "left" split node would be "browFurrow_left" where ether "_" is the split map separator between name elements. 

Incremental Separator

For Incremental network nodes this is the separator between the basename of the node and the incremental value. If we have an incremental node for jawOpen at 50% the incremental node would be named "jawOpen_50" where the "_" is the separator between jawOpen and its 50%.

Zip Delimiter & Zip Placement

The zip delimiter is the naming convention to denote zip nodes and is placed either before "Prefix" or after "Suffix" other name elements. So a zip shape for jawOpen set to "_zip" and suffix would equal the zip node named "jawOpen_zip".

Modifier Delimiter & Modifier Placement

Some shapes are not mean to act as primaries and are more independent modifier shapes. These typically represent more granular/atomic shape control over smaller areas of the face (like lip corners). Sometimes identifying modifier shapes helps animators know the difference between these small "control" shapes and larger primary shapes. The delimiter and placement gives you the ability to designate shapes as modifiers over other node types.

Represent Incremental Zero Value

When creating incremental nodes adds the full percentage value to the name. So for a 50% incremental like jawOpen at 50% with this setting off and an incremental separate set to "_" the node name would be jawOpen_50. With this setting on it would be jawOpen_050.

Format Template

This is the arrangement of naming elements that comprise the full long and short name of a network node. 

Option 1: Basename, Incremental, Split Map

Under Option 1 the basename of the node comes first then an incremental values with any split map name appended to the end of the network node name. For example a jawOpen primary that has an incremental trigger of 50% and is split left/right would be name like this "jawOpen_50_left" given the format template and the separators set to "_" for the long name separator, the incremental separator and the split map separator. If the node is not an incremental but split this format template would result in "jawOpen_left".

If no separators are declared for the long name and incremental separator but still "_" for the split separator you would get "jawOpen50_left"

Option 2: Basename, Split Map, Incremental

Option 2 interchanges the split map and incremental name order. So in our example above of a jawOpen incremental at 50% that is split left/right you would get a network node named "jawOpen_left_50". 

The format template represents the order the name elements come together with respect to the separators and delimiters set in the properties above.

The Primary Nodes Template

The Primary Nodes template allows you to pre-determine available primary nodes in a network. This is useful for pre-populating a network based on listing the primaries that are part of a "shape set". For example one .ini file might represent a full FACs shape network whereas another might represent the ARKit set of shape or Metahuman set of shapes. In this way you can switch out preference files and get the list of primaries you need to build. This is just a representation - you can still add any primary you want to a shape network by selecting a mesh and adding it as a primary so there is no true restriction - this would act more as a guide for modelers in a production to adhere to expected conventions of necessary shapes.

The Split Maps Template

The split maps template section allows you to declare split map naming conventions for long names and short names. In Aria the split map names are decoupled from the names of the split map files on disk. In this way a modeler can have a number of split gradient files for say left/right. Maybe there is a soft gradient just called "left.json" in the split maps directory and a hard gradient file called "leftHard.json" in the split maps directory. But to keep the naming convention similar across all nodes regardless of what maps you can assign the name "Left" for the split map node even though it uses the "leftHard" gradient file. So in this section you can setup the split node naming convention and give them a long and short name.

The Split Map Presets

In the split maps presets section you can setup common split map pairs that users will be accessing frequently. For example, most face splits have a left/right map pair and will use the same naming convention and same split map files. In the Split Map Presets section you can add a split preset that contains information for the split pair:

• Split A Long Name
• Split A Short Name
• Split A Map File
• Split B Long Name
• Split B Short Name
• Split B Map File

Presets are presented to the user when creating split map pairs via the split map assignment dialog.

As you can see in the image above our split map presets are loading in the dialog that creates a split map pair. This is really a quality of life issue for the end user. Select which preset you want and click the "Apply Preset" button. You do not need to apply a preset - it is there for your convenience and you can still manually fill out the information for the split node A/B of the split pair.

Path Environment Variables

The Path Environment Variables section give you the ability to declare environment variable paths for each type of supported disk path in Aria. If multiple users are accessing say split map files but their network mounts point to different locations (possibly using a Perforce setup as an example) then these environment variable paths enable the same Aria file to be opened and not have to repath each file.