Modeling in Maya
Table of Contents
- 1 Table of Contents
- 2 Summary
- 3 Video Demonstration
- 4 Starting the task
- 5 Requirements and best practices
- 5.1 Hierarchy
- 5.2 Anim VS Static
- 5.3 Meshes
- 5.4 Polycount
- 5.5 Naming
- 5.6 LODs
- 5.7 UV Unwrapping
- 5.8 Transforms
- 5.9 History
- 5.10 Load assets as references
- 6 Publishing the version
Summary
This document details the workflow of modeling in Maya with SYNK, highlighting essential steps, requirements for naming conventions, hierarchy, LOD management, UV Unwrapping and preparing models for following production stages like texturing and rigging.
Video Demonstration
Starting the task
Ftrack
In order to start working on the modeling of your asset, you will first need to:
Make sure you’re logged in to Ftrack connect, which is a standalone app.
Travel to the Modeling task of the asset you want to work on.
Launch the SYNK Maya action.
A version of Maya which includes the SYNK Pipeline will now launch automatically.
Maya
Once Maya opens, you will be greeted by a window that will allow you to select which version of the file you want to work with.
Open the version you want to work with or create a new version and start modeling.
Requirements and best practices
When preparing a 3D model for a production usage, you need to ensure the following guidelines are followed to maintain quality and usability before publishing it to ftrack.
Hierarchy
Our modeling scenes have a hierarchy of 6 levels:
The root group, which is the name of the asset following our naming conventions.
A group containing all the geometry (to distinguish it from later rigging groups)
An LOD node to make the different LODs visible in Maya
A group of the specific LOD
Either the anim or static group of that LOD
The meshes themselves (this is where you come in!)
Do not change the name of the nodes/groups that were generated when creating the modeling file. They are important in next steps of the pipeline.
Anim VS Static
Under each LOD group, you will see an anim group and a static group. These are meant to make a distinction between skinned dynamic meshes and unmoving static meshes. Static meshes will be included in the light baking of real-time projects.
As a general rule:
All meshes of a character will be under the anim group
The meshes of a prop will often be under the anim group (except in the case of a door, where the doorframe will be under the static group, or a windmill, where everything except the blades will be under the static group)
All meshes of a decor will be under the static group
Meshes
To limit the amount of draw calls, it is crucial to merge different meshes together as much as possible. This does not mean they need to touch each other or share vertices (although this can be done to limit polycount), just that they need to be considered as one object in the modeling software.
Due to current pipeline limitations, there can be only one material per mesh. This means some mesh splitting will be necessary in case some parts of a model need a different shader OR a different tiling texture.
Make sure that the model is clean by fixing any:
ngons
flipped normals
overlapping vertices
non-manifold geometry
Position the mesh at the origin (0,0,0) in the scene and sitting on the ground plane for proper alignment which is essential for layout and set dressing.
Use a 1x1 meter primitive cube or import any character model as a scale reference to ensure your asset’s scale is correct and relative to the other assets of the project.
Polycount
This measure depends highly on the type of project and output. A VR project needs to be highly-optimised to run consistently and smoothly, hence we will aim for a lower polycount. For a rendered feature film, the polycount can be higher, depending on the art direction, level of detail, etc. A good rule of thumb is to have between 50k and 100k vertices for hero assets and 5k and 25k vertices for background assets.
This is ok. | This isn’t. Use texturing instead. |
One way to reduce polycount is to analyze the topology of the model and remove unnecessary edges. For instance, simplify grid-like topology where edges could instead connect to corners directly. Also remove any unnecessary faces, especially those inside cavities or other areas that will never be visible.
Polycount is less important than mesh and material count (see just above)!
Naming
All geometry in the hierarchy should have _geo in their name. Usually the suffix of a mesh will be _geo_LODX with X being the level in the LOD in which your geometry is located. (There is a sanity check in place for this and will alert you if it’s not conform). If you do not name your meshes correctly, your file won’t get published to ftrack.
Other than that you can name your meshes whatever you want, but please use camel casing and think about possible artists who will have to work on the asset after you. Follow consistent and descriptive naming conventions for all geometry in the outliner and - for certain cases - the layers.
The grouping of meshes together doesn’t matter much as long as it’s logical and consistent.