Latest revision as of 11:04, 30 November 2023

This document is in beta 02.11.2020

Who should use this document

This document is for use with TMT version 1.8 or greater. Do NOT use this document if you are working with a TMT version less than 1.8.

Summary of changes in this version

This version of the Tile Mosaic Tool contains significant updates to the tile model library.

Elevation Maps Elevation maps have been implemented on some tile model intersections. These are 3-D surfaces within an intersection. The primary characteristic of elevation maps is they support different surface materials within an intersection.

Elevation maps are one way to determine curb strikes within an intersection based on a surface material code (SMC).

NOTE: Failure to use the correct rotation will produce a road network that ADOs cannot navigate because the elevation maps produce an offroad condition when the wrong rotation is used in the TMT.

File:elev_maps_20200211.jpg

NOTE: Elevation map intersections include a 'rotation key' in the tile name. Due to implementation requirements, it is required to rotate the tile model to the rotation specified.

Rotation Key

No code = 0 degrees A = 90 degrees B = 180 degrees C = 270 degrees

NOTE: Tiles with intersection elevation maps that are not rotated (default rotation = zero degrees) are located in various tile categories. Only tiles containing intersections can contain intersection elevation maps.

Obsolete models One significant change is that some tiles are now considered obsolete. Obsolete models are contained within the tile category 'Obsolete'.

It is strongly recommended that .MOS worlds using obsolete models be revised, as future versions of the Tile Mosaic Tool may not include those models.

If a world.mos file contains tile models that are missing from the library and it is saved, that .mos file will become corrupted.

There is currently no way to recover from this condition.

The Obsolete tile category is included with this version to permit replacing obsolete models with compatible tiles. It is strongly recommended that obsolete tiles be converted to the correlated tile model.

A list of compatible models is included in the Appendix of this document.

Transition tile category

Transition tile models are now grouped into a new Transition tile category. If you require a transition between different roadway types, the Transition category is the place you will find it.

New tile models

Another change in this version is the addition of new tile models, listed below.

bike_lane This is a new tile category. Tiles within the bike_lane category contain bicycle lanes, which are narrow lanes defined as Vehicle Restricted lanes. This definition is intended to prevent typical ADOs from using this lane.

However, scenario authors should be able to author pedestrian and bicycle models that will use the bike lane. In some cases it may be necessary to author scenarios using the standard road lane and apply a lane offset to shift the scenario object over into the target lane.

bike_lane tile models

1. 2ln_3Mi_01
2. 2ln_3Mi_02
3. 2ln_4way_3Mi_01
4. 2ln_4way_3Mi_02

NOTE: Bike lanes are not necessarily included as a separate network adjacent to the road network. At this time they are an attribute of the road.

city tile models

1. 4ln_city_1x1_02
2. 4ln_city_1x1_crv90_02
3. 6ln_4way_01
4. 6ln_4way_02
5. 6ln_city_straight_01
6. 6ln_city_straight_02

comm tile models

1. 2ln_4ln_3way_comm_02
2. 2ln_4ln_3way_comm_03
3. 4ln_4way_comm_01
4. 4ln_comm_straight
5. 4ln_comm_straight_04
6. 4ln_comm_straight_05
7. 4ln_res_3way_comm
8. 4ln_res_hill_curve01

filler tile models

1. gen_common_3x5
2. urban_01
3. urban_02
4. urban_03

fwy tile models

1. fway_2ln_04
2. fway_2ln_10k10kS_01
3. fway_4ln_2ln_DTL01
4. fway_4ln_straight_13x17

railroad tile models

1. railway_1xgrade_rural_01
2. railway_1xgrade_rural_02
3. railway_1x_straight
4. railway_3xgrade_city_01
5. railway_3xgrade_rural_01
6. railway_3xgrade_rural_02
7. railway_3x_straight
8. railway_4ln_city_01
9. railway_90
10. railway_straight

res tile models

1. 2ln_res_mult_school
2. 2ln_res_rural_trans
3. 2ln_straight_res
4. 2ln_straight_res_2
5. res_2ln_3way
6. res_2ln_3way_02
7. res_3way
8. res_3way_02
9. res_90
10. res_straight

rural tile models

1. 2ln_3way_rural_res01
2. 4ln_1mi_02

suburb tile models

1. suburb_2mi_01
2. suburb_90_01
3. suburb_Scurve_01

transition tile models

1. 2ln_fwy_2ln_rural
2. 2ln_fwy_3ln_fwy
3. 2ln_fwy_3ln_fwy_02
4. 2ln_fwy_4ln_fwy
5. 2ln_fwy_4ln_urban
6. 2ln_rural_2ln_gravel
7. 2ln_rural_2ln_gravel_02
8. 2ln_rural_2ln_res
9. 2ln_rural_2ln_res_3way
10. 2ln_rural_2ln_rural_10f_lane
11. 2ln_rural_2ln_rural_no_shoulder
12. 2ln_rural_3M_rural
13. 2ln_rural_4ln_city
14. 2ln_rural_4ln_rural
15. 3ln_fwy_3ln_urban
16. 4ln_BLVD_4ln_urban_e20
17. 4ln_BL_urban_2ln_rural
18. 4ln_city_4ln_BL_city
19. 4ln_city_4ln_BL_city_ROT_C
20. 4ln_rural_2ln_fwy
21. 4ln_suburb_2ln_rural
22. 4ln_suburb_2ln_rural_night
23. 4ln_urban_6ln_urban_day
24. 4ln_urban_6ln_urban_night
25. 5ln_urban_4ln_urban

urban tile models

1. 4ln_urban_4x8_01
2. urban_2ln_4ln_s1400A
3. urban_4ln_arterial_02
4. urban_4ln_straight_01

Introduction

The Tile Mosaic Tool (TMT™) was created to build visual and virtual correlated databases, a process generally known as world or database generation. The TMT is used to arrange tile models into a configuration (world). Tile models typically contain roads, terrain and feature objects. The construction of these elements and additional models and textures require the use of 3rd party software for the creation of textured 3D models. At the present time, only OpenFlight™ models and RGB format image files are supported by the TMT. Many commercially available (and many shareware or free) 3D programs can also be used for tile creation, but their output will need to be converted to OpenFlight™ format for use within the TMT. For a partial list of applications, please see Appendix B.

Command line Syntax/Conventions

In this document the following conventions are used for command line interaction. #Information enclosed within bracket characters <like_this> is for user input.

1. The phrase <ENTER> means that the user should press the Enter key, not to type in the word.
2. Where the percent character is used to enclose a string, it indicates an environment variable or environment variable value.

Getting Started

The TMT tile library contains of a number of related model files which reside on your computer. It is necessary that all tiles reside below a single parent directory (folder). Within this top-level directory, sub-directories are used to divide the tile library into different categories. Currently these categories consist of tiles with similar characteristics, but you are not limited to these. Additional tile categories may be created under the top-level directory. It is recommended that you do not change the basic tile category set, but you are able to add new tiles to existing categories, or create new categories for your tiles at any time.

NOTE: Each tile model must be unique – you should not have two tiles within the library with the same name, even if they are in different categories.

Start the TMT by double-clicking the icon. You may want to open existing database worlds, or create a new world (terrain database). To create a new world, choose New from the File menu (File >> New). If the TMT has not been used on this computer before, you’ll have to preprocess the tile library in order to proceed. Click Preprocess to load the tile library. This procedure will occur only when the TMT is first used on your system, or when a tile geometry file (.FLT) has been modified. The TMT loads the Tile Library automatically in normal use.

To open an existing terrain database/world file, choose File >>Open and navigate to the database location on your computer.

The TMT workspace window will appear. To place tiles into the terrain database, use the category tabs on the left to choose a tile category, and select a tile from the list by clicking with the left mouse button (LMB) on it. This will “attach” the tile to the cursor. Move the mouse to the right onto the terrain and position it, then LMB on any open grid to place the tile. The TMT will attempt to snap the placed tile onto the terrain grid. For more precise positioning, enable the terrain grid View >> Draw Attributes >> Grid and position the tile within the gridlines.

You can rotate a tile while it is attached to the cursor by pressing any key.

NOTE: When you are placing tiles onto a terrain that already contains tiles, the tiles will attempt to connect only where tile edges are the same. For example, the default tile edge is GEN (for General or Generic). A GEN edge will not match with any other edge unless it is forced. Although you can force tiles together, this is a procedure that has larger ramifications and can create visual and logical discontinuities and errors. Forcing tiles should be carefully considered.

When you are finished placing tiles, save the world file. Choose File >> Save and navigate to the directory location you wish to save the file set to. Because each world consists of multiple files, it is good practice to segregate them into their own unique directories. The Database directory installed with the TMT is a good location. For testing purposes, you may choose to use a single default “scratch” directory when doing rapid-cycle development or debugging and simply over-write the files repeatedly until a desired configuration is achieved.

NOTE: Avoid the use of spaces in the folder path to the TMT project files, as this can create problems for various TMT script utilities.

NOTE: To force/override the tile placement function, press and hold CTRL-SHIFT as you place the tile. This procedure will not allow you place a tile on top of another; it will however allow you to place two tiles together when their edges do not match.

NOTE: Each road map created in the TMT must be evaluated in ISAT to determine if the map is good and traffic can travel on all sections. The simplest way to test for a valid road network is to use ISAT and an ADO lead vehicle that drives across all road sections you plan to use during your simulation.

The ADO path should look like the intended drive path for your external driver/XD.

You can set a set Dial >> ADO >> Force Velocity action on the lead vehicle to maintain a consistent headway gap relative to the XD. This will allow you to see if there is a problem in the road network.

Run the test scenario in ISAT rehearsal mode and see if the lead vehicle can navigate the entire road network. Following a successful rehearsal, drive the scenario in miniSim and see if the results match. If the lead vehicle disappears in either case, review the road network in ISAT following the above guidelines.

Creating Output

The process of building and driving a world on the miniSim is:

1. Produce a terrain map by placing tiles on the workspace to create a road network using the TMT.
2. Output the visual files using the TMT.
3. Create a scenario control list (SCL) file using the command line.
4. Create a logical road information (LRI) file using the TMT.
5. Convert the LRI file to an optimized form (BLI) for ISAT and MiniSim using the command line.
6. Convert the visual files to an optimized format using the command line.
7. Install all required files on the miniSim using the install script.
8. Create a scenario that uses the world and save it to disk. At a minimum you need to place an external driver on any roadway. You can also set the ownship cab type using ISAT.

NOTE: All steps must be completed in order to view the created world on the MiniSim simulator.

To generate files for use on the miniSim, you will use the TMT Output menu. Environment creation workflow consists of building the visual database first. The miniSim will render these output files after they are optimized and installed. You must also process these visual files to produce a scenario control list (SCL) file. After the SCL file has been created, you can choose Output >> Scenario LRI file from the TMT to create a Logical Road Information (LRI) correlated database file. It will be necessary to convert the LRI file into a Binary LRI file (BLI), since that is the format the miniSim uses during simulation. It can be useful to be able to read the text form of the LRI file when troubleshooting problems with the world output process.

Conversion of the output flt files to an optimized format for use on the miniSim happens with a two-step process. First a command list is created in the flt folder, and then that file is processed to generate the required files. The database is ready for visualization on the miniSim when all the files have been installed.

Tile Library Contents

The Tile Library has been designed as an open-ended, extendable library of re-usable components. Tile models are a different class of model from model objects such as signs, vehicles or virtual objects. Tile categories are intended to provide a coarse level of differentiation between tiles with different features (culture). Generally, tiles will contain roads, roadway markings, terrain and vegetation. More complex tiles will include signage or traffic control devices such as traffic signals, railroad crossing signals, and general signage. In most cases, signs and traffic control devices are designed to be operated during simulation, which means they may be authored in ISAT to change appearance either during simulator initialization (i.e., changing a stop sign to a yield sign), or change dynamically during simulation (i.e., traffic light state changes from red to green to yellow).

NOTE: Tile Library content may be added to at any time without affecting previously constructed terrain databases. However, it is important to understand that scenario events are closely coupled with geographic locations within the world. Changing a world after scenario authoring has begun or following authoring completion may result in unexpected results or even failure to load or run the scenario in ISAT.

Typically it is possible to change a portion of the road network if there are no scenario paths or elements on that portion. Extending a road network beyond an intersection will not affect the road network on the upstream side of the intersection.

This example assumes there are no scenario authored objects, events or paths in the areas modified by the addition of tile models to the original design.

NOTE: Tile models require additional development for night rendering effects. Not all models in the library contain these effects.

Tile categories include:

1. City
2. Comm (commercial features)
3. Elev_maps (models contain elevation maps)
4. Filler (borders, panoramas and fillers)
5. Fwy (freeway)
6. Ind (Industrial features)
7. Mtn (Mountain)
8. Obsolete (these tiles should not be used)
9. Railroad (includes a rail line)
10. Res (Residential)
11. Rural (Countryside)
12. Rural_bike_lane (rural tiles with bike lanes)
13. Special (Tiles which are non-standard in some way, or project-specific and not intended for general-purpose use)
14. Suburb
15. Transition (tiles that connect between different road types and lanes)
16. Urban

Due to the nature of the visual and virtual correlated databases, special effects such as wet or snow environments have been constructed as specialized tiles, with the intended effect built into the tile model.

Time of day is a more general simulation effect, although for some complex tiles, a lighting effect has also been built into the tile. These special-function tiles are identified by keyword within the tile name (wet, day, night).

Although it is possible to use day tiles at night or vice-versa, the resulting database may appear odd and incongruous to the viewer.

Additional tile categories may be created by editing the alltiles.txt TMT configuration file located in the ProjectData\Tiles\ directory. 

Tile Model Naming Conventions

As the tile library grows, it is useful to know how the tile model name is constructed.

Tile model names are intended to provide some clue as to the nature or content of the tile, without requiring the user to actually view the model. Viewing the model is, of course, a really great way to become familiar with the model.

Here are a few examples:

• 2ln_city_01
  • 2 lane road, tile version 1
• 2ln_city_1x1_crv90_01_20
  • 2 lane road, road bed is a 90 degree curve, tile version 1, 20f elevation
• 2ln_city_4way_20
  • 2 lane road, 4 way intersection, 20f elevation
• 4ln_2x2_Hill_02
  • 4 lane, 2x2 tile (1320f x 1320f), tile version 2

NOTE: elevated tiles WILL NOT connect to standard tiles. You will require a hill tile to connect elevated and standard tile models. Forcing connections to these tiles is not advisable unless the connecting model has the same elevation.

NOTE: Tile versions are typically small variations from earlier version models. However, they may be completely different content on a similar road layout.

What happened to version x?

In cases where there is a missing version number, chances are that tile version is either not yet developed, or the missing version was left out of the TMT for some reason. There is no requirement that model versions be sequential, it just a mechanism to help classify a model.

Compatible Tile List

This command provides a list of tiles which are compatible in terms of edge specifications for placement at an open grid location in the terrain database. You must select an open grid location adjacent to a placed tile to use this command.

1. Select a grid location.

To select a grid location, double click (DBL) the grid location. That selected grid location will draw a yellow outline, indicating it has been selected.

1. RMB >>Compatible Tile List or Edit >> Compatible Tile List. A dialog will list all compatible tile choices for the selected grid location.

Tiles are listed in terms of tile name, rotation, size and category. Select a compatible tile by LMB a Tile Name in the dialog. To place the compatible tile into the terrain, LMB the Apply button. The tile is placed at the selected grid location in the terrain. You can continue to choose other tiles from the dialog and apply them to the terrain until the desired tile has been placed. LMB OK to close the dialog or Cancel to cancel.

Manual Tile Placement

The most common way to create terrain databases in the TMT is by placing the tiles manually. This provides the greatest control over creating the exact road network desired for simulation. After a tile has been placed in the database, you can edit the tiles to meet specific requirements* through the use of ISAT to change features that were created as configurable features.

Note: Editing the source tile model requires the use of a 3D editor. Tile editing and 3d modeling is outside the scope of this document.

To manually place tiles, choose a tile category from the left panel. Select a tile and LMB on the icon. Move the cursor to the right side, into the terrain layout. You can rotate a tile by pressing any key. Click on an open grid location to place the tile. To detach the tile from the cursor, move the cursor to the edge of the terrain database window.

The TMT will prevent placement if the following conditions occur: 1. You are attempting to place a tile onto another tile. 2. You are attempting to place a tile where the tile edge does not match. The TMT will turn the placed tile edge red when this happens, indicating an invalid edge match.

NOTE: You can override the edge match by pressing CTRL AND SHIFT when placing the tile. Be aware this can cause discontinuities and visual mismatch when you override edge matching.

After a tile is placed, you can modify the orientation by invoking commands from the Edit menu, RMB or Tool Bar. 1. Select a tile or group of tiles in the terrain database. 2. Choose a function from the Edit menu, RMB menu, or Tool Bar.

Auto Tile Placement

You can fill in defined areas in the terrain database using automatic tile placement, which is used when no particular configuration is desired and a large region of coverage is desired. From the Auto Tile Placement dialog, you can choose tile categories and individual tiles within each category for placement. Tile placement is based upon a weighting factor which is controlled by this dialog.

Selecting a grid area by DBL at an open grid location. If properly selected you will see the terrain grid outlines in yellow. Move the cursor to another location, holding the SHIFT key, and LMB again at the new location. You will see a region of terrain grid now has a yellow border, indicating a valid selection. Choose Edit >> Auto Tile Placing or RMB >> Auto Tile Placing.

NOTE: if a grid area is not properly selected the command will not enable.

The Auto Tile Placement Control Dialog will appear. The dialog has two parts:

1. Category selection and adjustments
2. Library tile placement and adjustments

In the Category selection and adjustment area, choose the tile categories you wish to use for auto tile placing. You can select multiple categories, or LMB Select All. When you have chosen tile categories, LMB the Add button. Use CTRL to select discontinuous categories, or SHIFT to select a continuous list of categories. You can also remove single or multiple categories from the destination list.

In the Library Tile Selection and Adjustments section, you can choose the library tiles you wish to use in auto placement. Tiles within the selected Tile Categories appear in the source (left bottom) window. You can use Select All, Add, Remove and Clear buttons for both Tile Categories and Tiles. Adjust the weighting factors of each tile by using the slider bar. The Optimal Tiling button applies higher weights to tiles that have the most common edge specifications among the list of tiles chosen. Click OK to apply the settings to automatically place tiles within the terrain. Cancel will cancel the auto tile placement command.  

Controllability: Unique vs. Generic Functionality

The MiniSim™ uses scenario control software to control individual components within a tile (ie., changing a traffic light or sign). But what happens when there is more than one tile reference of the same tile within the terrain database? In order to control each model component, tiles must be flagged as a unique tile instance. This is achieved by enabling the Unique Control setting in the TMT™ (the traffic light icon) and then enabling Unique Control for a tile or selection of tiles.

NOTE: Unique control options in the menu are disabled until the Unique Control Mode is enabled in the TMT.

Select a tile by LMB or a group of tiles using fence select. RMB >> Enable/Disable Unique Control (Selected Tiles) or Edit >> Enable/Disable Unique Control (Selected Tiles). A uniquely controlled tile will display a small green X in the terrain layout view. Because this function is a toggle, to turn off unique control, you can disable all controls or for the selected tile using the same menu as enable.

When are Unique Controls necessary?

Unique controls are not necessary if there are no controls available within the tile!

However, if a tile contains SWITCHES, then the tile has been built to support changes to the simulation scene from scenario control. For example, some tiles contain street signs. It is often desirable to have a world contain unique street names. If the world is built with Unique Controls enabled, then a scenario author may adjust each street sign to a different name using the Interactive Scenario Authoring Tool (ISAT). This mechanism is used for all cases where a change in appearance is desired within the terrain tile.

NOTE: The TMT will output a file for each Unique Control tile.

NOTE: Turning a visual element off within a tile does not disable the CVED representation. Even if the object is not visible to the simulator driver, the object still exists.

This has implications if the miniSim is configured with collision effects enabled. In this case, driving into a visually disabled object will result in a collision.

Due to the nature of switch controls, it is possible to implement controllability for visual scene elements at any time. However, there is no corresponding capability for any applicable CVED representation.

For example, it is possible to create controllable road markings with different visual conditions (pristine, aged, off) but without additional programming CVED will not reflect this functionality. In this case, the CVED road marking representation will always be present, until the CVED code has been modified to support a variable condition road marking.  

Load Management for Visual Databases

It is possible to create databases which will not perform optimally on the MiniSim™. To avoid this, adjust the visibility of terrain tiles by using the level of detail (LOD) node within each tile. More complex tiles may contain additional LOD nodes.

Right-click any tile and choose Tile LOD Settings… from the context menu. The LOD dialog will highlight each LOD in the configuration window as you select LODs from the list. You can change the Center, Switch Distance, Transition Range and Freeze flags for each LOD. Setting a small Switch Distance will cause the tile to display when the eyepoint approaches closer to the tile. Large values cause the tile to become visible over longer distances. Excessively long values, especially within complex environments, may contribute to performance problems.

It is most desirable to have terrain tiles visible only for the period they are needed. The LOD Center X, Y and Z values can be manipulated to shift the LOD so that the tile disappears behind curves. Thus, curve tiles are ideal for load management elements.

NOTE: Changing the LOD Center values will require the Freeze flag to be enabled. If the freeze flag is not enabled, the tile may not display as anticipated.

Notice how the curve tile LOD has been edited so the tile is not visible from the North-South road along the right side, and it is not displayed to the left of the large S-curve tile since it is unlikely the tile can be seen from that location anyway.

LODs can be adjusted significantly as needed, as shown below.

Output for Visual Database

1. After a world has been developed and saved to disk, you can publish the visual database world to disk. From the TMT™ Output menu, choose Output Scenario/Visual Data. A dialog will appear. Disable the LRI flag, and use the default settings for OpenFlight Output.

NOTE: This will over-write the files located within the project flt directory; in the event you wish to retain these files, it is best to create a backup copy of the flt directory prior to generating output.

2. The next step is to generate a scenario control list for the terrain database/world that you've just generated. The SCL is a text file that lists all available switches, which can be authored using the ISAT. Without this file, although you can generate a world that will run on the MiniSim™, you will be unable to author objects within the environment such as street signs, traffic lights, etc.

Open a command window at the FLT directory. You can use the windows explorer to navigate to the Database directory under Favorites: Favorites >> ProjectData_Databases. Open the directory containing your database, then right-click on the FLT folder and choose “Open CMD here” from the context menu.

At the command window, enter: buildscl <DB_NAME.flt><ENTER>

Remember that DB_NAME is the name of your .MOS world file (terrain database), and you do not type the ‘<’ or ‘>’ characters. <ENTER> means press the Enter key on your keyboard.

The program buildscl will create a scl file that is the same prefix as your terrain file (i.e., buildscl myTerrain.flt will generate the file myTerrain.scl). 4. Generate the optimized files for use on the Minisim simulator. Open a command line in the flt output folder. Type in the following command: buildbatchlist <DB_NAME> <ENTER>

To automatically execute the optimization script, include the execute flag on the command line:

buildbatchlist <DB_NAME> -e <ENTER>

The script will create a command file (do.bat) that will process all the flight files in your output flt folder.

To manually execute the optimization command file on the command line: do <ENTER>

The command line will process all the flight output files. When this is complete you will navigate up one folder level to prepare for processing the LRI file. cd .. <ENTER>

• NOTE – this is two periods, which means “go up one level”.

• • NOTE – if you forget to generate optimized files for the simulator the database installer script will not complete.

Output for Correlated (Logical) Database

1. After you have generated the visual database and a .scl file and optimized the flight output, create the correlated virtual environment database. From the TMT™ Output menu, choose: Output Scenario/Visual Data and this time, disable all the OpenFlight™ Output options. Although you may enter a different output prefix, it is easiest to maintain projects if the default file name is used for both the terrain database.mos and the correlated virtual database.lri file.

A DOS window will display the status of the LRI build. Because this window is not persistent, if there are any error messages you wish to save you must collect them from the window using the quickedit mode: select the text you wish to save, and press <ENTER>. This places the text into a buffer, which you can now use to paste into a text log file for later use.

The most typical error will be a warning that a .summary or .scl file has not been found. In that case, you can proceed with the correlated virtual database build but no switches will be available to author. To correct this, simply follow step2 from Output for Visual Database located above, and then re-output the correlated virtual database file.

2. Navigate to the world/project folder. If you have a DOS window open to the FLT directory already, to move up one directory you can enter: cd ..<ENTER>

3. From the DOS command window, enter the following: mlri <database><ENTER>

This will cause a script to convert the ASCII correlated database .LRI file to an optimized binary form. This script will copy your database BLI file for use within ISAT to the ISAT directory. If you wish to see the script command commands necessary to convert the LRI file, simply enter: mlri <ENTER>

and the script will echo the command and parameters in the DOS window.

Test the New Database

Just because a database can be built, and the BLI can be read by ISAT, does not mean the road network is entirely valid and drivable. Testing can validate the database for simulated traffic and the External Driver (XD).

To test the database, place an ADO on the roadmap/BLI in ISAT and extend a path over the entire route that the XD is intended to drive. If ISAT cannot build a path over the entire route then there is some problem in the BLI to resolve. It is likely that the point where the path ends is where simulated traffic will die during simulation and disappear from the scene.

Reasons for this include:

1. Forcing two tiles together in the TMT that do not share the same road characteristics (number of lanes, elevation).
2. A problem in a tile on either side of the location where the path ends.'
3. some other as yet unknown condition.

A successful path is only the first step. To be sure that you have a working database it is necessary to drive the desired route on the miniSim. Ideally you would start the driver just behind the test ADO, and use a Maintain Gap or Force Velocity action to keep that test ADO in sight throughout the drive.

Note: if the ADO is on a forced velocity and the XD speed exceeds the limit of what the ADO can support for cornering, it may disappear as a result.

When both the test ADO and XD arrive at the end of the drive, it is safe to say the database is valid and ready for scenario authoring.

Note: Authoring scenarios and then making changes to the BLI can invalidate the scenario, so testing should be the first thing to do when starting a new project with a new database world.

Database Use Within ISAT

Following the successful creation of the visual and logical world, you will be able to open the world BLI from ISAT to create scenario events and conditions using your new database. The build process automatically copies the .BLI and .placeholder support file into the %MINISIM_ROOT%\Data/ directory. You can also access the primary files from the Projectdata\Databases/ directories. Care should be taken to maintain one pristine copy of files for development, and where necessary, backup copies should be made prior to major changes to your scenario (.SCN) files.

File Transfer to MiniSim™

Database worlds that are created using the TMT™ must be copied into the MiniSim™ directory tree before they are available for use within the MiniSim™ simulator.

A script has been provided to copy files for user convenience, although it is advisable to be aware of the various file types and locations where these files are to be placed for proper configuration.

To install a database world, run the following script from the database directory:

dbinstall <DB_NAME><Minisim™ Version Number><ENTER>

This script expects the database files will be available from the location the script is activated, which means the default configuration as installed and described in this document. In the event of an error, the script will discontinue operation and inform the user it has encountered a problem.

NOTE: Non-standard file locations may cause the installation script to fail. The following files are copied (version refers to the installed software version number):

DB_NAME.scl C:/MiniSim™_version/bin.x64/

*.FLT/*.IVE C:/MiniSim™_version/visuals/db_name/

DB_NAME.BLI C:/MiniSim™_version/data /

DB_NAME.FTR C:/MiniSim™_version/bin.x64/

TMT™ Reference Help: There is currently no online help feature available for the TMT™.

Associated file set

The Tile Library contains a number of related files, all of which are necessary to the use of the TMT™ and creation of Minisim™ environments:

1. allTiles.txt – this text file contains a list of the tile library tiles and categories (configuration file for the TMT™).
2. CD1 – A text file containing a list of the Tile Library Tiles used in the MOS.
3. CD2 – A text file that defines the connective edges between tiles.
4. DDS – these are compressed texture files for use on the MiniSim™.
5. FLT – These are binary OpenFlight™ files that contain geometry and references to image texture files. These files are necessary for MiniSim™ simulator operation.
6. FTR – This is a TMT™ support file that contains all the tile references necessary for a terrain configuration including XYZ offset, rotation, and tile category type. This file is necessary for MiniSim™ simulator operation.
7. ICN – this is a binary file that is used for the TMT™ tile icon.
8. Intersection.map – a text file that contains terrain data and specifications for unique elevation maps applied inside intersections.
9. IVE – these are binary converted files optimized for MiniSim™ use.
10. JPG – this is a binary snapshot view of the tile from an overhead view.
11. LatProfileList.lat – this text file contains all the lateral specifications for every road type. It includes a cross-section profile and a material code index.
12. MOS – this binary file is a TMT™ project file, also referred to as a world or project file.
13. PATH/CORR – these are text data files that contain coordinate data describing either roads or intersection corridors.
14. PET – this text file contains logical database tag information.
15. RGB, RGBA, DDS –binary image texture files. The RGB and RGBA files may also have associated .attr files: these files are produced from the modeling environment tools and are not currently used by the TMT™ or MiniSim™. However, the RGB, RGBA and DDS files are necessary for MiniSim™ simulator operation. These files will already be present in the MiniSim™ configuration, but additional (new) files must be copied to the proper location.
16. SUP – this binary file is used by the TMT™.
17. SurfaceMaterialSpecifications.xlsx – an Excel™ document that contains surface material codes for road surfaces.
18. tileSizes.txt – this text file contains a list of tile library tiles and their dimensions, given in Tile Units (increments of 660 ft; a 1 x 1 tile = 660ft x 660ft). Secondary configuration file for the TMT™.
19. TXT – this text file contains TMT™ information. The TXT file will be updated when the binary FLT file changes, and should remain read/write. If you want to force the TMT™ to re-process the tile library or any particular tile, delete the TXT files and the TMT™ will re-create them.

Included Databases

The following is a list of databases installed with the TMT™ with general descriptions:

1. day_night_01: A long environment containing urban, residential, highway and rural environment. This database is designed for day or night use from the highway to rural area only. The urban environment is a night-only area.
2. day_night_snow_01: The same environment as day_night_01 but with snow effects and roadways for the highway and rural roads.
3. nadsdemo_dsc: A demonstration database containing dry, wet, and snow environments. This database includes a small urban area, a small rural area, and a small mountainous area.
4. nadsdemo_geospecific: A small, geo-specific database built to match a real-world location in Iowa.
5. nadsdemo_kiosk: A small, geo-typical database containing 3 separated environments. Contains rural and urban environments.
6. simple_rural1: a basic, small rural environment
7. simple_rural2: a basic, small rural environment with unique tiles enabled.
8. rural_long: A simple rural environment intended for longer simulation drives. It begins with a long, straight roadway and contains varying curves and hills, with some intersections and one cross-road.
9. test_all: A database that contains all the TMT tiles. Tiles are connected to each other for each category, and connections have been forced. This makes it possible to create a scenario for each tile category and to drive all the tiles, to become familiar with each tile and roadway type. The original tile orientation has been preserved where possible. Each tile category reads from top to bottom, left to right where possible.

<image_here>

Database Creation Guidelines

Using the TMT™ it is possible to overload the visualization capacity of the MiniSim™. A few common sense rules will help to avoid that situation:

1. Build only what you need. If your scenario requires 3 miles of highway driving, there is no point in building a ten mile stretch of terrain database. Keep the region of interest (ROI) or gaming area extent reduced to the smallest necessary footprint.
2. Fewer larger tiles are more efficient than many smaller tiles. If you need 3 miles of highway, do not create a terrain that uses a small 1x1 tile to make the longer road.
3. If you cannot see it from the road, don’t include it in the terrain. If something will never be visible, why include it in the terrain? There is one caveat: sometimes you will want to enclose the ROI such that it is not possible to see beyond the terrain edge. You will enclose the terrain using filler tiles, which are designed to block the view. These are secondary tiles with very little detail, small amounts of features and no drivable roads.
4. Adjust the load for optimal performance. Even if you follow these guidelines, you may still bump into processing limitations. You can modify each tile within the TMT™ to display only when it is visible to the driver, and to turn off when it is not. This is accomplished by using level of detail (LOD). Each tile contains an LOD that is controlled from the TMT™ to permit the terrain database author to disable or enable tiles as needed to ensure consistent performance.
5. Although the TMT™ itself does not enforce a rule, mixing coordinate units within the same terrain database is likely to cause problems. All tiles in the TMT™ Tile Library were constructed with units = feet, using the right-hand rule of coordinate systems: X increases to the right, Y increases forward, and Z increases upward.
6. Forcing tile edge matches: although you can force a match in the TMT™, almost always you will not want to as it is likely to create problems within the visual terrain or logical database. A rural road that is forced to match an urban road will appear OK in the TMT™, but when you drive that database you will see how different the two road types are, and how the rural tile edge contains a different elevation profile than the urban edge. Use a transition tile to change from one road type to another instead of forcing these types of matches. There are only a few road types that can be forced that will still look and work due to their construction, profile and lane information.

Note: After you have begun authoring scenarios, it is no longer trivial to change the terrain database. This is due to the internal data structure elements of the SCN and BLI files. The best approach is to finalize the road network configuration prior to scenario authoring activities.  

Script Utilities

A number of script utilities have been developed to assist with the terrain generation process. These files are located within the utils directory. In addition to the scripts mentioned within this document, the following scripts are included:

• lg.bat – This script will generate an LRI file from within the database project folder. In order to use this script the TMT™ must have already published the tile models, and the user should also have created the db_world.scl file from the TMT™ tile models located in the flt folder. This script is run from the same folder location as the db_world.mos file.

• mlri.bat – This script will generate a .BLI file from a .LRI file, and is run from the same folder as the db_world.mos file. The lri file can be published from the TMT™ or created using the lg.bat script.

• view.bat – This script allows the user to review an object or tile model without having to create a database and scenario and driving them on the MiniSim™. The viewer is only for reviewing models, it cannot be used to review a scenario. This command should be run from a command (DOS) window that is opened to the folder containing the models to be viewed. In the event this command does not work, the user should run nadsconfig_system.bat and then use the osg_viewer.exe application to view the model, and then communicate the script failure to NADS so the error may be corrected.

Lessons Learned: Things that can go wrong

Although the terrain creation process is fairly streamlined, a number of issues may arise that could lead to problems. Mitigation strategies are provided to get you back into production:

1. Test every road map. Just because the TMT produces a database does not guarantee the result is a completely drivable road network. Test to make sure that it is.
2. Every time you make a new build, generate both the visual and logical databases together. This is because there are no versioning schemas built into the TMT™, so it is necessary to re-generate all your files for a build in the same session. This has the highest chance for success. Often when a terrain control is not operating the way you think it should, the issue can be traced back to a mismatch between the visual and logical databases.
3. Use a script for consistency. To repeat procedures over and over again with a consistent approach, use a script to ensure that you are using the commands and command line options the same way every time you perform a build.
4. Do not copy/paste large areas using the TMT™. This can create corrupted terrain databases. Once a terrain file has been corrupted, there is no way to recover it. By saving a terrain database as another file, you can jump-start the construction process and provide yourself with a backup file at the same time. Copy/paste multiple tiles can be combined with rotation.
5. To control objects in the environment (signs, traffic signals, etc) it is necessary to ensure the database world has been created using the “Unique Tiles” option, as described in the section Controllability: Unique vs. Generic Functionality (p10).

NOTE: You can have multiple TMT™ sessions open at once, using one database as a reference for LOD settings while building a second database.

Unwanted collisions during simulation

If collisions are encountered with invisible objects during simulation - ie, there is no apparent source for the collisions, or if there are many collisions happening - the procedure involves: 1. Identify the tile containing the collisions. A coordinate is helpful for this, which can be determined from ISAT (reported on the status bar) or miniSim (has to be enabled). 2. Review the tile.pet file for Objects. 3. Each Object in the tile.pet will reference a sol2 object. 4. Locate the sol2 object from #3 then find the CollisionSoundID record. 5. Any positive number will enable collisions. To disable, replace the value with -1.

Note: If the object is not found in the sol2.txt file, then search all sol2_aux*.txt files. Note: Remember to copy the modified file to ISAT\data if you are editing the file in NadsMiniSim_x.x\data (and vice-versa) to maintain consistency. NOTE: You must exit miniSim and/or ISAT before making changes to system configuration files.

Appendix A

Obsolete and compatible tile models

Do NOT use obsolete tile models - instead, locate the compatible tile model and use that instead. Obsolete models are included solely to avoid potentially corrupting existing world.mos files.

Appendix B

The following is a partial list of applications used to support the creation of TMT™ compatible 3D models and textures. There are many programs available. The basic requirements necessary are the ability to create texture-mapped 3D geometry and the meta-data files containing simulator data. These files may be examined in the ProjectData\Tiles folders installed with the TMT™.

A. Graphics Programs • Adobe Photoshop™ or CreativeSuite™ • GIMP™ • Painter™ • Any other raster editing graphics application

B. 3D Programs • Presagis™ Creator • Autodesk Maya™ • Autodesk 3D Studio™ • Google Sketchup™ • Any other 3D application capable of applying and saving textured 3D models C. Conversion Programs • Deep Exploration™ • Okino PolyTrans™ • Export from 3D Program

NOTE: Currently in order to use your models within the TMT™ to produce terrain databases, it will be necessary to utilize some form of conversion software to convert from the application native or export format into OpenFlight™.