3D Asset Naming Conventions

There are four separate areas where a naming convention is needed:

• Asset names (includes models, textures, materials, etc.)

• Node names (mesh, curve, and group / null / locator nodes)

• Catalog Item names

• Rules and Attributes

Asset Names

Asset names should come primarily from the file names that get uploaded. It would be best if assets are only renamed when necessary to match with a renaming of the actual source files as well, or for other specific purposes. Retaining the same name for both the assets and their source files ensures that assets on the platform can be automatically updated when a file with that name gets drag-and-dropped on that asset folder.

The naming convention that can be used with the file names can vary from project to project. Overall, however, we would like to stick with capitalization for the first letter, and a separation of elements by the use of underscores ‘_’. For example, a chair asset with its associated textures and material can be named as follows:

Chair_Lounge.fbx Chair_Lounge_MAT Chair_Lounge_diffuse.jpg Chair_Lounge_roughness.jpg Chair_Lounge_specular.jpg Chair_Lounge_opacity.jpg Chair_Lounge_metalness.jpg Chair_Lounge_emissive.jpg Chair_Lounge_AO.jpg

This example will allow us to quickly identify on the platform each of these assets as what they are intended for. The materials need to have the _MAT suffix, in order to distinguish them from the model asset when we have to select them in the Catalog Item 3D Asset reference dropdown.

For the attribute reference on the textures, we stick with lowercase names that match the attribute intended for the texture (ie. _normal instead of _Normal).

Node Names

The node names refer to the names of nodes in the scene graph. These nodes can be mesh nodes, NULLs or groups, lights, curves, cameras, etc. The naming convention here would follow a similar pattern as the asset names, although there are fewer restrictions. In general, this would follow the typical naming convention used inside Maya or 3dsmax.

It is useful to name nodes with the appropriate suffix that describes the type of node it is. This comes in very handy when selecting the nodes inside rules. Take this for example:

• Chair_GRP (the parent group)

  • Chair_Legs

  • Chair_Back

  • Chair_Cushion

  • Chair_Legs_CRV (for curve nodes)

  • Chair_Legs_JNT (for Joint nodes)

  • Chair_LIGHT (for Lights)

  • Chair_CAM (for Cameras)

CameraTarget_NULL (for Null nodes)

Catalog Item Names

For Catalog Items we need to follow the naming convention provided by the client. This would mean that we would need to pick the same names that the client uses in their system as much as possible. The choice between product codes and their English readable names has to be made on a per-project basis, with the dev and the art team in agreement.

Aside from the actual products there will be supporting catalog items that will need to be created, including the main configurator items. For these, the same naming convention as the Asset names could be followed:

Chair_Lounge (or Chair Lounge).

It is less important to avoid special characters like spaces or dashes in the catalog item names, since they are not associated with file assets. The special character restrictions on asset names are primarily due to the file and node name restrictions inside different Operating Systems and the 3D applications. For example, Maya does not allow any special characters aside from underscores “_”.

The more important item to consider here is matching names between catalog items and assets as much as possible, to avoid any potential confusion.

For example, use names like:

Catalog: Chair_Lounge (or Chair Lounge) Asset: Chair_Lounge

Instead of:

Catalog: LoungeSeat Asset: Chair_Lounge

Rules and Attributes

When it comes to attributes in particular, it is very important to use names that clearly identify the purpose of the attribute and how it is used. Avoiding confusion will be very important.

For example, if the cushion on the chair above is configurable with a mix of leathers and fabrics, it would be suitable to create an attribute named Material, or** Fabric**, since both terms can be interchangeable in this scenario. It would not be suitable however to name the attribute Leather.

Within this context, also avoid naming multiple attributes with similar names, such as having two attributes named Material and Fabric.

If the purpose of the Material attribute is to describe the wood choice for the chair, then a more appropriate name for it would be Wood, WoodMaterial, or WoodChoice.

Avoid names that are non-descript, such as x, or increment. Instead, use a more descriptive name such as spacingIncrement. Note how in this example we made use of the camelCase naming convention for attributes that are used solely inside Assets for logic purposes. You could also name it SpacingIncrement, Spacing Increment, Spacing_Increment, as long as you maintain the same convention throughout. Avoid mixing underscores and spaces for attribute names.

A similar descriptive logic applies to the Rule names as well, except that rule names should generally be kept more sentence-like. For example, it is preferable to have a rule titled

Apply Material only on assets with just one material swap. If multiple materials are being swapped in that single rule, then call it Apply Materials

For rules that are dependent on conditions like ON or OFF, or values like “Blue”, “Red”, “Green”, etc, it is best to clearly identify this on the rule name as well. For example: Load Shirt for Jacket_OFF Vest_ON, or Apply Material Blue, Apply Material Red, etc.