A model is a sub-element of a scene. A model by itself cannot exist, except in a file ("*.ttm"-file type), nor can it be simulated by itself. A model has to be contained in a scene in order to be operational.

Models are defined by a selection of scene objects built on a same hierarchy tree, where the base of the tree has to be an object flagged as object is model base. They can be loaded with [Menu bar --> File --> Load model...]. It is however much easier and convenient to load a model with a drag-and-drop operation between the model browser and a scene view. Models can be saved with [Menu bar --> File --> Save model as...], just make sure one single object flagged as object is model base is selected, otherwise the Save model as...-menu item will not be enabled. Make also sure to follow the tutorial on how to build a clean simulation model.

A model is defined in following steps:

  • attach all objects that logically belong to the model to a base object, so that the base object is the base of the model tree.
  • check the object is model base-item in the object common properties.
  • in the same dialog as above, check the object/model can transfer or accept DNA-item. This will simplify model re-instanciation if you modify it at a later stage.
  • in the same dialog as above, clicking Edit model properties, you can define special overriding properties (e.g. make the whole model invisible, non-collidable, etc.). That allows to quickly disable some properties for all objects defined in the model.
  • for all objects in the model, except for the base object, check the select base of model instead-item in the object common properties. This will protect your model: you won't be able to directly select individual objects in your model, and you will be able to manipulate your model almost as a single object.
  • for all objects that are normally not visible, check the Don't show as inside model selection-item. This will make the model bounding box appear in the right size around the model.
  • think about the role of the model: will you be able to attach it to some other object? (e.g. your model is a gripper that you could attach to a manipulator wrist). Or will you be able to attach some other model to it? (e.g. your model is a manipulator that could accept a gripper model). Once the role is decided, define the model's assembling behaviour. Refer also to this dynamics design consideration.
  • Now, individual objects build on the model base cannot be selected anymore in the scene (selecting them will select the base of the model instead), however they can still be individually selected by holding down the ctrl- and shift-key during selection, or by selecting them in the scene hierarchy. In addition to that, when the base object is selected, a stippled bounding box encompassing the whole model is displayed as can be seen in following figure:

    [Scene view and corresponding scene hierarchy view. The selected dummy is flagged as object is model base]

    Notice the model tag on the left-hand side of the icon of the object flagged as model base:

    [Model tag]

    A double-click on a model tag opens the model dialog, where model properties can be adjusted. It is also good practice to collapse a model's hierarchy once the model was edited in order to easily identify the number of logically grouped elements/models:

    [Scene hierarchy view displaying 5 collapsed models]

    Grouping several objects as a model is also important when a child script accesses the objects programmatically; remember that in V-REP, objects/models can be duplicated at any time, also during a simulation. In order for the duplicated child script to be able to access the correct objects (not the original objects but the duplicated objects), the child script should always be duplicated at the same time as the objects it accesses. One way to guaranty that is to create a model (as described above) and to make sure the child scripts that access objects in the model are associated with objects that are contained in the model. Best is to associate one child script (there might be secondary child scripts too) with the the base of the model. Refer to the accessing objects programmatically section for more information.

    In order for models to be easily combined (i.e. built on top of each other) without any additional modification, it is important to consider what role the model will be playing: will it be dynamically simulated? Will it be attached to other models, or will it accept other models attached to it? The answer to those questions will allow you to select the best object type to work as a model base. Refer to the section on designing dynamic simulations for more information.

    Copy and pasting a model behaves exactly like saving the model, then loading it (using however a memory buffer instead of the disk space). Models can be copied from one scene to another like any other object. Model files ("*.ttm"-files) also support drag-and-drop operations between the explorer window and the application window. Model files can also be double-clicked, in which case they will launch the V-REP application and be loaded into a default scene.

    The properties of a model can be individually adjusted in the model dialog.

    Recommended topics

  • Related API functions
  • Scenes
  • Object common properties
  • Model dialog
  • Building a clean model tutorial
  • Child scripts