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.
A model is defined in following steps:
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:
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.