![](https://csdnimg.cn/release/download_crawler_static/12247044/bg12.jpg)
Models
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