3D Modeling Guidelines
These guidelines have been developed in order to maintain a high degree of predictability and flexibility across as many unique working environments as possible. The dynamics of application will vary among different 3D Modeling programs but the underlying concepts of these guidelines are relevant to all 3D modeling workflows. The end goal of these guidelines is to create a system of 3D Model management, both in scenes and in file directories, in such a manner that reduces the likelihood of disaster. Things go wrong, files get lost, names get forgotten— well-defined guidelines can help weather the storm of disorder and chaos. The rigidity of 3D Model guidelines will be influenced largely by the industry and use-cases for which they are developed. Higher demand industries such as film and gaming will necessitate a higher complexity and order in their guidelines while more casual uses such as architectural visualization and product rendering allow for less granular systems. The guidelines outlined in this article are meant to serve as a source of inspiration to be adapted to specific use cases. They should not be considered adequate enough to ensure performance in every field of visualization or modeling.
Layer Names
3D Models should be placed on layers to allow for easy visual separation by the end user. The naming convention used, for individual model files, is SKU-Product-Name. This layer should contain all objects in the final model including, lights, helpers, rigging, and any objects that will always be included with the product deliverables. Other objects such as studio environments, dome lights, cameras, or scene helpers should be excluded from the model layer and be placed on another layer appropriately describing their use. Collections of multiple products should exist as a layer containing sublayers containing individual products. Below is an example of the preferred layer organizational convention:
Unrelated Scene Objects Layer
Rendering Studio Group Layer
Camera
PhysCamera001
VRayLight001
VRayLight002
Studio Backdrop
0123-00-123-001 Model Collection Group Layer
0120-00-121-001 Individual Model Group Name A
Product Object Name A
Product Object Name B
Product Object Name C
0121-00-121-001 Individual Model Group Name B
Product Object Name A
Product Object Name B
Product Object Name C
0122-00-121-001 Individual Model Group Name C
Product Object Name A
Product Object Name B
Product Object Name C
Object Names
Objects within scenes are to be given human-readable names to denote their general significance to the 3D Model. These names do not need to be explicit nature but should allow for easy association with the model. Models with fewer numbers of objects will allow more generic and meaningful naming while objects with greater numbers of objects will necessitate more granular conventions per file. An example of a many-objects file naming approach for a model of a bedroom dresser would be dresser-foot-001, dresser-foot-002, dresser-foot-003, dresser-foot-004. This would exemplify a circumstance where the 4 feet of a dresser were separate objects within a scene. If these objects were attached to a single object, they could be more simply-named as dresser-feet. Below is an example of this convention in practice, for an imaginary 3D Model of a Dresser & Mirror, as it would appear within a layer navigation pane.
0123-00-123-001 Dresser & Mirror Model Name
Dresser Base
Dresser Drawer Fronts
Dresser Mirror
Group Names
Many 3D applications, such as 3DS Max, functionally treat groups as additional scene objects in such a way that can make scripting and algorithmic modeling more complex. For end-users however, grouping can provide valuable front-end organization. RenderNode modeling guidelines state that the collection of individual parts that comprise a single end-product 3D Model should be grouped for easy front-end identification and selection. This includes any scene object that is deemed to be a vital aspect of that 3D Model’s appearance such as a light object used in a table lamp model. Group naming should adhere to product naming conventions and reflect the unique identifier used to label that 3D model. An example of the correct model-grouping convention would be to name the group containing the lamp base, lamp shade, and light object of the 0123-00-123-001 Table Lamp.max 3D model file as 0123-00-123-001 Table Lamp. This allows for easy scene identification when imported into larger and more complex visualization scenes.
File Names
File names should be given a numerical identifier in such a way that allows referenced identification agnostic to the human-readable description. A common example of this convention would be to add numerical leading identifiers to the beginning of all file names as such; 0123-00-123-001 Model Name. This 3D Model could be easily identified by the leading “0123-00-123-001” numerical string if necessary and the trailing “Model Name” supplement is simply to offer a bit of narrative. There are a lot of considerations to make when developing a file-naming system. For a deeper discussion read this article. There are a lot of dependencies on how your models will be used, how many categories they will be used in, and how many variations may exist. Many opt for non-significant numbering systems to avoid conflict while others prefer to use a significant system to describe product information.
File Format Considerations
Different file formats are often needed to allow for wider range of uses of 3D Models. 3D Models which contain single variations of multiple file formats should reflect identical file names, discernable only by the file-extensions. In cases where multiple versions of same file formats are required these filenames should add an identifying string to describe the variation. The choice in approach for naming variants should be decided on use case but the one commonality is that it should be predictible and implemented identically for all 3D Models. For example, a file named 0123-00-123-001 3d Model should have the following names for its various formats:
- 0123-00-123-001 3d Model.max
- 0123-00-123-001 3d Model_2013.max (denotes a 2013 release version)
- 0123-00-123-001 3d Model.fbx
- 0123-00-123-001 3d Model.dwg
- 0123-00-123-001 3d Model.obj
- 0123-00-123-001 3d Model.3dm
- 0123-00-123-001 3d Model.iges
- 0123-00-123-001 3d Model.sat
- 0123-00-123-001 3d Model.3ds
- 0123-00-123-001 3d Model.c4d
Texture Resolution
Textures included with models should reflect the purpose of the intended use of the 3D Model. Models to be used in real-time, low-poly applications such as gaming should be as optimized and as size-reduced as possible. Textures used with models intended for photorealistic still image rendering can be as large as is needed to provide the ability to render detailed and life-like compositions. When possible, textures should be designed in such a way to allow easy tiling in such a way that avoids both vertical and horizontal seams. Unless otherwise stated, all RenderNode models include seamless textures which allow easy tiling.
Filepath Stripping
Filepaths should be stored within asset managers in such a way that allows access to the intended end-users. This file path convention implicitly-dictates that texture files be stored in locations accessible to the end-user. For companies working on local area networks (LAN), this dictates that texture paths be routed to shared network drives. There is no way to predict the most convenient storage location for users in cases of marketplace sales or online distribution to non-networked users. In such cases where 3D Models are intended for use in unknown environments, such as 3D Models sold in marketplaces or the RenderNode website, file paths should be relative to the project folder that will be provided to the end-user. Many 3D programs such as 3DS Max will search all sub-directories of the parent folder in which the active file has been opened, which can allow a compromise in some cases. Stripping file paths to the filename and including these files in the project folder is the best way to ensure maximum compatibility for a maximum set of end-user use cases.
