The PathBuilder utility generates an xml file that represents the railroad route. The xml file contains: route, terrain, billboards, model locations and other properties that represent the path and branches of the railroad. The file also includes the meta-data associated with the route properties (GIS data catalogs, 3d models, era information, etc). PathBuilder maintains a catalog of all GIS resources and scans used to build the path. PathBuilder will create local snap shots of GIS data covering only the route paths for local edit and creation of the route. The utility provides for notes and other documentation to be attached to points along the path. PathBuilder generates the terrain patches and adds initial default textures. The route file with extension “.path” is the core data for a route and can be merged with other routes or split from other routes. The route path file will be maintained and versioned using a group network svn repository. The route title is function of the routes placement in the repository directory tree. The route will also have a descriptive title, but this title will not be guarantied or required to be unique. Intellectual property rights will be maintained by attaching the same public/private key signature used as a network id (svn network data base) to the route path. This is a social method of maintaining intellectual property rights where users as a group will not allow the use of others property in their routes or network game play.

PathBuilder CASE
ACTORS:

• Author – The route creator and owner.
• Editor – A route editor.
• File-system – The local computer file-system.
• Internet – The network based files and servers.
• Working – The svn working repository.
• Repository – The local svn repository.
• Network-repository – The common group svn network repository.

USE-CASE:

• Create an empty route.
• Clone a route.
• Create an empty catalog.
• Edit a catalog.
• Add map or image to a catalog.
• Catalog a CD or DVD map or image.
• Catalog an internet map or image.
• Import a catalog.
• Export a catalog.
• Create an empty path.
• Edit a path.
• Import a path.
• Export a path.
• Plot a “world file”.
• Edit a “world file” plot.
• Create a “world file” for scanned images.
• Plot map or image.
• Edit a map or image plot.
• Plot a route.
• Edit a route plot.
• Generate a reduced extent map or image.
• Create a “world file” for a reduced extent map or image.
• Download a cataloged map or image from the internet.
• Download a “world file” from the internet.
• Add a property to a path.
• Plot a path property.
• Edit a property plot.
• Export a property to another route.
• Import a property from another route.
• Edit a property.
• Generate default properties.
• Generate terrain.
• Generate terrain textures.
• Edit terrain.
• Generate billboards.
• Generate billboard textures.
• Edit billboards.
• Generate 3D mash.
• Display a 3D path.
• Display a 2D path.
• Verify a catalog.
• Verify a path.
• Verify a route.

SUB-SYSTEMS

• Network – libcurl – FTP, DAV, P2P operations.
• GUI – wxWidgets – User and operating system interface.
• Version-control – imbedded Subversion (svn) – Maintains working, local and network repository.
• GIS – GDAL/OGR – read, write, convert and position the maps and GIS data.
• Mapping – Process and catalog maps and scans.
• Terrain – Generate and edit mesh and textures from GIS elevation data.
• Billboard – Generate and edit backdrops and textures from GIS elevation data.
• 3d – Display 3D terrain and billboards.
• 2d – Display 2D images and maps.
• Path – Generate and edit the knot points, control weight values and the rectangle for each knot point based on initial user assigned path width. Adjust the path for smoothness for mainline/yard requirements.
• Catalogs – Maintain catalogs of maps and scanned images.
• Property – Add and edit path properties.

The purpose of the MSTS2Blender is to convert from Microsoft Train Simulator mash/texture format to/from Blender DNA and OGRE mash/texture formats. The reason that Blender format was selected is that it is a free professional quality 3D Graphics editor and specifying it will not create two classes of users for OSRail as in MSTS, those that can afford expensive 3D tool and those that must use free tools.

The program source is in the src/utilities/msts2blender directory. The current status of the project is that it can read most of the MSTS format (mash and textures).

The method used to create the utility is to first create software routines to read all three formats (MSTS, Blender, OGRE mesh) and display them in a 3D OGRE window (OgreWindowManager).

The next step is to build conversion routines between the various formats and OGRE mash format, displaying the result in the OGRE 3D window. With this working the third step in building the conversion utility is to convert from OGRE format to the various formats and testing them in MSTS and Blender. This should create a Utility that can be used both for OSRail and MSTS.

Intellectual property rights should be maintained by attaching the same public/private key signature used as a network id (svn network data base) to the conversion to/from OSRail/OGRE mash format. This is a social method of maintaining intellectual property rights where users as a group will not allow the use of others property in their routes or network game play. See PropertyConfigurer.

There are various existing methods to convert to OGRE mash format using scripts (Python) added to Blender. These would require an OSRail user to become familiar with Python and its interfaces to Blender, transparent in Linux but problematic in Windows. This method also requires multiple steps. So to create a single step and consistent interface for OSRail, this utility will be a stand-alone program producing the three native formats required.

The Console utilities primary purpose is to display the Inter-Process Communication output from the Simulator program and its utilities. The program reads the command structures in the ConsoleFrame::readNextFromClient(consoleframe.cpp) routine of the Console Utility. The following commands are implemented or planned:

• ASSERT – implemented – example (src\simulator\main.cpp) Assert prints source file, line number and message. Assert will stop on the initial discovery, but can be overridden from the Console.
• MESSAGE - implemented – example (src\simulator\main.cpp) Message prints the source file, line number and a message.
• MEMORY – not implemented – Create memory statistics.

  PROFILE/PROFILE_START/PROFILE_STOP – implemented – example (src\simulator\main.cpp) Produces a min, max and average instruction counter(rdtsc) output (hex).

• EXCEPTION – implemented – example (src\simulator\main.cpp) Exception prints source file, line number and a message. Exception reference the line number of the exception in the “catch” statement.

• PLOT – not implemented – Will produce 2D or 3D graphics of a variable (time) or an array of variables.

• DUMP – implemented – example (src\utilities\msts2blender\mstsace.cpp) Dump will print a variable ("sprintf" format) to the Console utility.

• TWEAKER – implemented – example ( src/simulator/graphics.cpp )Allows simulator variables to be displayed and changed in real time. )

• UNITTEST – implemented – UNITTEST is not a macro, but is implemented in vendor/cxxtest/cxxtest/TGConsoleGui.h. The source TGConsoleGui.h is used to tie cxxtest unit tests to the Console IPC. The TGConsoleGui GUI displays detail test results in a Console frame if the Console utility is running prior to the RUN_TEST project of the build system.

   
"Program Name" will generate a new Console window frame, (card box) with that title and "Page Name" will generate a new tab on that frame with "Page Name" for a title (card). Although the labels imply program and page name they my be any classification that will server to order the Console output.