Задани на лабораторные работы. ПРК / Professional Microsoft Robotics Developer Studio

www.it-ebooks.info

Chapter 5: The MRDS Visual Simulation Environment

Sky and Ground Entities

The simulator provides two built-in entities to define the sky, as well as a number of entities to define various types of terrain. You can build a scene without these entities if you prefer, but they make the environment look more realistic, particularly for outdoor scenes.

SkyEntity and SkyDomeEntity

You don’t really pay a lot of attention to the sky until there isn’t one. The sky provides diffuse scattered light that illuminates objects in the scene. It is also sometimes useful to simulate bright and overcast outdoor conditions. The difference between the Sky entity (see Figure 5-15a) and the SkyDome entity (see Figure 5-15b) is the way they are drawn:

Figure 5-15

The Sky entity surrounds the entire scene with a 3D sphere mesh. A cube map, specified in the VisualTexture property of the Sky entity, provides the color of the mesh. This method of drawing the sky is somewhat inefficient because the ground obscures half the sky mesh that is drawn. Half the texture stored in memory is never seen. The texture used by the simulation tutorials for the sky is simply called Sky.dds.

The SkyDome entity is more efficient because it uses a half dome to surround only the part of the environment above the ground. It is colored by a 2D texture map such as Skydome.dds. The one disadvantage to the Skydome entity is that if you rise too high in altitude, you may see a gap between the sky and the ground. The Sky entity is preferable for high-altitude simulations.

Both the Sky entity and the SkyDome entity can add to the diffuse lighting of the scene. The color and intensity of light that they cast on the entities in the scene is defined by a special texture map called a cube map. To visualize how a cube map works, imagine yourself on the inside of a giant cube. Each of the six faces of the cube has an image on it so no matter which direction you look, you see a pixel in one of

253

www.it-ebooks.info

Part II: Simulations

the images. The lighting cube map surrounds the entire scene and defines the color and intensity of the light that shines on the entities from each direction. It is common to define a diffuse light map that lights entities brightly from above and less from the sides. The illumination coming from below is usually a little more than from the sides to simulate light scattering from the ground.

You can see how this cube map affects the lighting of the scene by clicking Start Visual Simulation Environment Multiple Simulated Robots. Start the Simulation Editor by pressing F5 and then select the Sun entity in the Entities pane and delete it by pressing the Delete key. Although there is no light in the scene, the robots, table, and ground are lit by the light coming from the sky. You can remove this light from the scene by clearing the texture specified by the LightingTexture property on the Sky entity. The sky will still be lit, but the objects in the scene will be very dark.

The Sky and SkyDome entities also provide a way to set the fog in the scene. The FogColor property defines the color of the fog. For a night scene, you want to use black fog, and for a day scene, grayish or white fog. Using the FogStart property, you can also specify the distance at which fog begins to appear. The FogEnd property specifies the distance at which entities in the scene are completely fogged. The fog increases linearly between the FogStart distance and the FogEnd distance.

One diffuse sky texture is provided with the MRDS kit. It is called, oddly enough, sky_diff.dds. The .dds format is associated with DirectX, and the extension was originally an abbreviation for Direct Draw Surface. These days, .dds files are most often used as texture maps for Direct3D. You can edit and create

.dds texture maps using the DirectX Texture Tool, which is part of the DirectX SDK described previously in this chapter under the section “Software Requirements.”

The simulator changes the Y offset of the Sky and Skydome entities to follow the eyepoint of the Main Camera. This prevents the camera from ever going above the sky. Do you remember that episode of Star Trek in which a whole colony of people were living inside a hollowed-out asteroid that was a spaceship, except they didn’t know it was a spaceship until an old guy climbed a mountain and touched the sky? You don’t have to worry about that in the simulation environment.

The SkyDome entity is used in Simulation Tutorial 1. You can run this environment by clicking Start Visual Simulation Environment Basic Simulation Environment. Notice how the skydome texture is less blocky than the sky texture. It also consumes less video card memory. You can purchase additional textures that will work with the SkyDome entity from www.hyperfocaldesign.com.

If you find yourself occasionally becoming disoriented in the simulation environment, you can literally paint a compass in the sky using the Sky entity. Start the Simulation Editor by pressing F5 and then select the Sky entity. In the VisualTexture property, select Directions.dds. This texture will paint the direction you are facing on the sky (see Figure 5-16). For example, if you are looking along the Z axis, then you should see Z ahead of you.

254

www.it-ebooks.info

Chapter 5: The MRDS Visual Simulation Environment

Figure 5-16

HeightFieldEntity

The HeightFieldEntity is used as a ground plane in many of the simulation tutorials provided with the SDK. It is one of the more important components in the scene because without it, everything falls into an abyss.

A HeightFieldEntity is flat, with an elevation of 0 meters. It may seem infinitely large but it is really just 49,000 square meters, ranging from ( 4000, 0, 4000) to (3000, 0, 3000). Columbus would not have fared well in the simulation environment.

A HeightField shape contains a grid of height values. The HeightFieldEntity uses a grid of 8 rows by 8 columns, and it sets the altitude of each height value to 0.

The most remarkable feature of the HeightFieldEntity is the texture that is applied to it. The default texture used in most of the SDK samples is 03RamieSc.dds, which looks a little like industrial carpet. It is a little depressing to look at 49,000 square meters of carpet, so you are encouraged to find another texture for your scenes. The only requirement is that the texture should tile properly without any seams, because it is repeated across the ground many times. The default scaling for the texture on the ground plane is 1 meter by 1 meter. This scale can be changed programmatically but it can’t be changed using the Simulation Editor.

You can change the texture associated with the ground by selecting the ground and then opening its EntityState property. Enter a new 2D texture filename in the DefaultTexture property.

The friction and restitution (or bounciness) of the ground can be changed by editing the HeightFieldShape property. This brings up a dialog that enables you to edit its shape properties, among which are StaticFriction, DynamicFriction, and Restitution. These shape properties are described more fully in the upcoming section, which describes SingleShapeEntities.

255

www.it-ebooks.info

Part II: Simulations

TerrainEntity

The TerrainEntity is a much more interesting way to describe the ground than the HeightFieldEntity. The HeightFieldEntity is fine for simulating indoor scenes, but the challenge that many robots face is navigating uneven ground in an outdoor environment. The TerrainEntity provides a way to construct such an environment.

You can take a look at a TerrainEntity by clicking Start Visual Simulation Environment Simulation Environment with Terrain. The TerrainEntity uses the HeightField physics shape just like the HeightFieldEntity, but it sets the HeightField grid values to varying heights based on the pixel values of a grayscale image file. The pixel values range from 0 to 256 and the terrain entity converts these values to –12.8 meters to 12.7 meters, with height samples spread one meter apart by default. Figure 5-17 shows a TerrainEntity built from the terrain.bmp image file with the terrain_tex.jpg texture map to color it.

Figure 5-17

There aren’t many TerrainEntity properties that you can modify in the Simulation Editor, but you can change the image that generates the HeightField and the texture that you apply to it. Start the Simulation Editor by pressing F5 and select the entity named Terrain. Change TerrainFileName to another image filename, such as particle.bmp. Nothing immediately happens because this particular entity does not automatically refresh when a property is changed. With the TerrainEntity still selected, press Ctrl X and then Ctrl V to refresh the terrain. You’ll notice that the ground level has changed noticeably, and when you leave the Simulation Editor by pressing F5, the physics engine will pop the buried objects out of the ground.

You can change the texture that is applied to the TerrainEntity by changing the DefaultTexture in the EntityState property.

256

www.it-ebooks.info

Chapter 5: The MRDS Visual Simulation Environment

TerrainEntityLOD

The TerrainLODEntity is identical to the TerrainEntity except that it does some extra tricks to try to reduce the load on the graphics system. It calculates a reduced resolution version of each section of the height field and then uses that version when the section is far away from the eyepoint. This reduces the number of triangles that must be drawn, as shown in Figure 5-18. The left side of the figure (a) shows the TerrainEntity and the right side (b) shows the TerrainEntityLOD. It does not reduce the number of HeightField samples used by the physics engine, so it does not affect physics behavior.

Figure 5-18

Unfortunately, the TerrainEntityLOD may not be suitable for many applications because it changes the height values for portions of the terrain in the distance, which may cause some entities to be incorrectly visible or obscured in the distance. In addition, it makes no attempt to seam together the edges of each section, so you may see unattractive cracks between sections. Nonetheless, if your graphics card is struggling to render a scene with terrain, the TerrainEntityLOD is an option for you.

Lights and Shadows

The simulator provides three different types of lights to illuminate the scene. They are implemented as a single LightEntity, which has three different modes of operation, described further in this section. You can define up to three lights in the scene, but be aware that each additional light creates extra work for the graphics chip and may reduce your frame rate. You can continue to use the simulation environment with Terrain to see how lights work in the simulator.

Directional Lights

You use a directional light to model a light that is very far away, such as the sun. The position of the light doesn’t matter, only its direction. Most of the tutorial and sample scenes provided with the SDK include a directional light named Sun. Put the simulator into Edit mode by pressing F5 and select the Sun entity.

257

www.it-ebooks.info

Part II: Simulations

Now select its Rotation property and drag the left mouse button while holding the Ctrl key to see how changing the direction of the light affects the lighting in the scene.

When the simulator is in Edit mode, LightEntities are represented by simple meshes, as shown in Figure 5-19 (from left to right, directional lights, omni lights, and spot lights).

Figure 5-19

The Color property defines the color of the light for all light types. The SpotUmbra, FalloffEnd, and FalloffStart properties do not affect directional lights.

Omni Lights

Omni lights are so named because they send light out in every direction. Consider light bulbs. These lights are usually very close to the objects that they illuminate, so their position is very important; but because they cast light in every direction, their rotation is unimportant.

You can change the Sun to be an omni light by changing its Type property. Try changing its rotation just as you did for the directional light. No effect. Now select its Position property and move the light around. You can see that even small changes in the position of the light change the way entities are lit in the scene.

If you ever need to position a light in the scene but you can’t find it, you can use the same trick that works for every other entity. Select it in the Entities pane and then hold the Crtl key and press the up arrow. The eyepoint will be moved to be just above the selected light.

The FalloffStart and FalloffEnd properties affect both omni lights and spot lights. They define the distance at which the light starts to diminish and the distance after which the light has no effect, respectively. Unlike the sun, light bulbs tend to have limited range here on earth.

Spot Lights

Finally, a light for which position and rotation are both important. In the real world, many light bulbs have reflectors and shades to direct the light in a particular direction. That is exactly what a spot light does. It projects a cone of light with the apex at its position. The angle swept out by the cone is specified by the SpotUmbra property. These types of lights are good for headlights or emphasis lights.

258

www.it-ebooks.info

Chapter 5: The MRDS Visual Simulation Environment

Shadows

Light shadows provide cues to our brain regarding the position of objects in the world. They can be a help to robot vision processing algorithms and they can also be an added challenge. The simulator supports casting shadows from one light. Each LightEntity has a CastsShadows property, which, when set to True, causes that light to cast shadows. Switch the Sun back to an omni light and turn on shadows. The first time shadows are turned on, the simulator must generate special shadow meshes for each mesh in the scene. If a mesh was read from a file, the shadow mesh is saved to a file in the store\ media directory with the same name as the mesh file but with a .shadowMesh.bin extension. It may take several seconds to generate shadow meshes for very complex or large models. For example, the LEGO Tribot can take 20–30 seconds on a fast machine. The next time the shadow meshes are needed, they are read from the disk, rather than generated. If the original mesh is changed, its shadow mesh is updated.

Move the omni light around the scene and note how the shadows are updated (Figure 5-20 shows shadows cast from a single omni light). The entities in the scene are self-shadowing, which means that one part of an entity can cast a shadow on another part.

If more than one light has the CastsShadows property set to True, the simulator will cast shadows from the first light encountered as it is drawing the scene. Be aware that drawing shadows is expensive and can slow down the rendering of the scene substantially.

Figure 5-20

General-Purpose Entities

Some entities in the environment don’t justify extensive modeling. If you need to test how well your robot avoids obstacles, a few entities made of a single box shape will probably suffice. You can build furniture or stairs or ramps out of multiple box shapes.

The simulator provides the SingleShapeEntity, the MultiShapeEntity, the

SimplifiedConvexMeshEnvironmentEntity, and the TriangleMeshEnvironmentEntity

to make it easier for you to add objects to your scene. Each of these entities is used in the scene built

259

www.it-ebooks.info

Part II: Simulations

by Simulation Tutorial 5 and is discussed in detail in this section. You can run this scene by clicking Visual Simulation Environment Simulation Environment with Terrain.

SingleShapeEntity

As the name implies, this entity is wrapped around a single physics shape — either a sphere, a box, or a capsule. This is the easiest way to add a single object to the environment: Decide which shape will best represent the object, specify its dimensions, and add it to the scene. You can even specify a mesh to make it look more like the object you are modeling.

The bluesphere, the goldenscapsule, and the greybox are good examples of SingleShape entities that use the various physics shapes. In the Simulation Editor, you’ll notice that SingleShape entities have three properties under the Shape category representing each of the three possible shapes. You can edit the properties for the shape that is defined, or you can click the value of one of the other shape properties to change the entity to use that shape. This is probably a good time to talk about general shape properties because they are used in nearly every entity.

Expand the shape properties associated with the sphere in the bluesphere entity. The properties are divided into the following categories: MassDensity, Material, Misc, and Pose. The Material category is where the friction and restitution properties of the shape are specified. Several shapes may share the same material, and changing the material for one shape will affect the other shapes as well.

MassDensity

AngularDamping/LinearDamping These properties mean the same thing as the corresponding

260

www.it-ebooks.info

Chapter 5: The MRDS Visual Simulation Environment

Material

261

www.it-ebooks.info

Part II: Simulations

Several of the entities in the terrain scene do not specify a 3D mesh, so their visual mesh is built from the shape itself. The StreetCone entity does specify a 3D mesh. Switch to the combined view and look at this entity, and you will see that it is just a single cube for physics purposes but looks like a traffic cone visually.

MultiShapeEntity

The MultiShapeEntity is much like the SingleShapeEntity except that it contains — yes, you guessed it — multiple shapes. It only supports boxes and spheres but you can have as many of them as you like. The table_mesh entity in the scene is built from multiple box shapes, but you would never know it until you select the physics view because it also uses a 3D mesh to give it a nicer visual appearance.

The state for a MultiShapeEntity is very similar to the state for a SingleShapeEntity except that the BoxShapes property is a collection of boxes and the SphereShapes property is a collection of spheres.

SimplifiedConvexMeshEnvironmentEntity

This entity enjoys the distinction of having the most syllables of any other built-in entity so it must be important. In some cases, it is not sufficient to have a single box represent the physical shape of an object because it just doesn’t collide with other objects the right way. The simulator can construct a physics object called a simplified convex mesh from any 3D mesh. A convex mesh is built from the points of a convex hull, which is the smallest polyhedron containing all of the points of the original mesh. You can think of generating a simplified convex mesh as similar to taking an arbitrary mesh and wrapping it with shrink wrap. When you heat the shrink wrap and it pulls tightly around the object, the resulting shape is very close to the convex mesh representation. (Of course, the physics SDK does this using math, not shrink wrap.)

SimplifiedConvexMeshEnvironmentEntities interact with the physics environment just like spheres, boxes, and capsules except that they are more expensive to calculate. The table_phys_m is an example of this type of entity. It is shown in Figure 5-21 (right) along with a

TriangleMeshEnvironmentEntity (left).

Figure 5-21

262