Modeling Best Practices#

In order to provide a high level of consistency when incorporating 3D assets from multiple sources into a single scene, the following guidelines are provided for use in asset creation and export.

Scaling And Orientation#

SimReady 3D assets should adhere to the following modeling guidelines.

  • All assets should be created at real-world scale using meters as the scaling unit. It is important that real-world scale is used so that relative sizing of objects in a scene is accurate when 3D assets provided by different sources are used. Real-world scaling also ensures consistency in the physics behavior of the 3D assets when a simulation is run.

  • Assets should be exported in Z-up orientation. Some 3D software applications use Y-up as its default modeling orientation. Maya is one example. When creating 3D assets in an application where an axis other than Z is up, be sure to choose Z-up as the coordinate system when exporting the 3D asset.

  • The 3D asset must be aligned in terms of its “front” to the “front” viewport of the chosen 3D app as shown below. If your 3D asset doesn’t have a defined front (e.g. pencil or bolt), then use your best judgment on alignment.

SimReady Kettle Model

3ds Max viewports#

SimReady Kart Model

Maya viewports#

SimReady Monkey Model

Blender viewports#

  • Pivot points must be properly placed and aligned so the 3D asset “sits” properly with respect to the ground plane. If the model is supposed to hang on a wall, or from the ceiling, it should have the pivot located in a position that allows for natural placement in relation to those surfaces, but it should remain centered at the origin.

  • There should be no transformations on the 3D asset. This means no scale, offset, or rotation information. All transformation values should be zero, except for the scale, which should be set 100%. Most 3D applications have the ability to freeze or reset transformations and these tools should be used prior to export.

  • Complex assets need to be broken out into moveable pieces, with each moving part having its own transform. If the asset is made up of multiple parts, each of the individual components of the asset should have its pivot at its respective base/center. If these parts are expected to move, pivots should be placed where they assure rotations won’t break the expected function of the object.

  • Any reusable asset that will be embedded into the ground (e.g. a light post) should extend below the ground plane enough that it can be placed on a 45-degree slope without the base of the object floating over the surface. The pivot for the object should remain at the world origin even though the geometry extends beneath the ground plane.

Naming and Packaging#

All SimReady 3D assets should be created using the following naming conventions.

  • All file names should be written as lowercase_with_underscores and should describe the geometry in human-readable terms (e.g. car_hubcap, door_knob, speaker_grill_cover)

  • Do not use double underscores, hyphens, or other special characters.

  • Material names should be indicative of the surface substrate that they represent. If a material is supposed to be worn, dented steel, then it makes sense to name it something like metal_steel_dented_worn. This will also assist as physical and non-visual sensor attributes are applied to the SimReady asset downstream.

  • Each 3D asset should be exported individually. In other words, do not export groups of objects together as one 3D asset (e.g. a table and chairs) since they won’t be able to be positioned independently. The table and chairs should be exported as their own individual 3D assets so they can be positioned as needed relative to one another. Keep this in mind when constructing your 3D assets, and pay attention to the “atomic” level of what is being exported.

Geometry#

General#

As has been mentioned earlier, there is no one “right way” to build a SimReady asset. The visual organization of your asset is not important. However, a simple hierarchical organization is recommended given that it makes the asset easier to understand from a human perspective. Separate parts/meshes should be created for the following cases:

Separate Moving Parts#

Complex objects need to be broken out into moveable pieces, with each moving part having its own transform and properly placed pivot point. Moving parts can include many meshes, but they should all be parented underneath an XForm prefixed so it is obvious of it’s purpose (e.g. XForm_Left_Door). Location and orientation of the XForm is also important as it will define the joint location through which the part will be connected to the parent.

Separate Dynamic Objects#

Dynamic lights for vehicles are just one example. A single ‘lights’ object could contain a turn signal, headlight, and running light materials. An object that contains an emissive map that is enabled or disabled by time of day, or is meant to have dynamic behavior however, needs to be separate.

Separate Glass Parts#

Transparency is costly to render. For this reason special effort is made to clearly define which objects have transparency and take steps to allow for optimization as described below:

  • Objects with transparency (e.g. glass) should be kept as separate mesh primitives. A building, for example, might have a ‘glass_windows’ object that contains all of the glass windows for the entire structure. Keep these objects separate from other objects so they can be identified for any further special handling or performance optimization that might be required for a given simulation runtime.

  • The glass should be modeled with the same thickness it has in the physical object. Glass surfaces can share UV space with other non-glass materials. Do not model glass as non-manifold geometry.

On this page