Scene definition

The MPK scene file format is a simple extension of the Open Inventor scene file format. (For details on the Inventor file format, see an Open Inventor manual or tutorial.) Scene files have an '.iv' extension and are typically in the scenes/ subdirectory. MPK extends the Inventor file format by three node types: mpkObstacle, mpkRobot and mpkIncludeFile (for details, see below). These are derived from the Inventor node type SoSeparator and can thus have the same attributes as a SoSeparator, in addition to their own specific attributes that are described below.

Before creating a new scene file, it can be helpful to examine one of the existing scene files. E.g., take a look at 'scenes/demo1.iv'. One can add an arbitrary number of robots (nodes of type 'mpkRobot') to the scene file, each with its own 'scaleFactor' and 'translation' attributes, in the same way as the one robot that is included in the 'demo1.iv' file. See on which robots are available and how to define new robots.

Besides robots, one can include one or more files (nodes of type 'mpkIncludeFile') containing obstacles, like the wall file 'wall.iv' in 'demo1.iv'. Obstacles can also be defined directly using nodes of type 'mpkObstacle' (e.g., see file 'scenes/mov_puma_vwbody.iv').

The following descriptions summarize the available MPK node types:

mpkObstacle

Adds a static obstacle to the scene.

Example: The following example defines an obstacle named 'box' that is a cube of side lengths (1, 2, 3). Note that Cube is an Inventor node type.

DEF box mpkObstacle {
  DEF __triangulate__ Cube {
    width 1
    height 2
    depth 3
  }
}

The 'DEF __triangulate__' tag is required to tell MPK that the triangles of the Cube node are part of the collision model. Similarly, one could add other Inventor models inside the same mpkObstacle node. Without the 'DEF __triangulate__' tag, the models would be displayed but not be checked for collisions. Note that all tagged models within the same mpkObstacle node are merged into a single PQP hierarchy for collision checking.

In the example, the 'DEF box' definition can be omitted. However, it is recommended to give names to obstacles to identify which obstacles are involved in collisions.

mpkRobot

Adds a robot to the scene.

Example 1: In the following example, a robot named 'puma1' is inserted into the scene. Its kinematics definition is read from the 'puma500_torch.rob' robot definition file in the 'robots/' subdirectory. The robot is scaled, translated and rotated before it is inserted into the scene.

DEF puma1 mpkRobot {
  fileName "puma500_torch.rob"
  scaleFactor 2.2
  translation 0 -0.01 0
  rotation 0 -1 0 1.6
}

The rows with scaleFactor, translation and rotation can be omitted. The rotation parameters are x,y and z of the rotation axis followed by the rotation angle (in radians).

List the '.rob'-files in the 'robots/' subdirectory to see which robot types are currently available.

Example 2: In this example, a hard-coded robot of type DEMOROBOT is inserted. Hard-coded robots have the advantage that they can realize arbitrary parameterizations (see files 'robots/mpkDemoRobot.H' and 'robots/mpkDemoRobot.cpp').

DEF robot mpkRobot {
  robotType DEMOROBOT
  scaleFactor 1.5
  translation 0 1 0
  rotation 0 1 0 3.2
}

Check the file 'basic/mpk_robot_type.h' and the '.cpp'-files in the 'robots/'-subdirectory to see which hard-coded robot types are currently available.

For information on how to create your own types of robots, see .

mpkIncludeFile

Includes a file with a complete scene definition.

Syntax:

DEF <identifier> mpkIncludeFile {
  name "<filename>"
}

The part 'DEF <identifier>' can be omitted. However, this may result in ambiguous object identifiers if the same file is included several times. To avoid ambiguities, define a different name for each mpkIncludeFile node that loads the same file.