Dynamic Track

A dynamic track section contains up to five subsections, each of which is either a straight section (up to 200 meters long) or curve (circular arc) section (up to 2000 meters radius and 90° of arc).  The subsections are constrained to number 1-5 and be straight, curve, straight, curve, straight, in only that order.  Why the developer of MSTS constructed this curious assembly is unknown.  But it is useful.  The ability to lay out an arc of arbitrary radius and any angle up to 90° is as advantageous as “flextrack” is to the HO railroad modeler.  Even a three-section assembly with an arc in the middle and tangents on each end can be a valuable “surveying tool” at route-editing time.

Program Structure

Dynamic track is processed with scenery objects (structures, vegetation, etc.) a WorldFile constructor (in Scenery.cs).  As of SVN163, dynamic track is constructed by helper method DyntrackAddAtomic, which has the following objectives:

1. It decomposes the subsections into individual, independent single-subsection dynamic track sections.  The reason for this decomposition is to simplify downstream code.
2. It tracks the positions of the roots of each independent section so that each section is aware of where it ends as well as begins.  This is important because no order of dynamic track sections is guaranteed.
3. It distributes elevation change throughout the sections according to a rule.  Currently, the rule is the MSTS “plywood sheet” rule, which is explained below in Grade-Reckoning Methods.  In the future, Open Rails will seek to correct anomalies in the MSTS method.
4. It builds a mesh for each of the independent sections.

Each dynamic track object is represented by an instance of class DynTrackObj and is accompanied by a WorldPosition object that relates the root position and orientation of the section.  DyntrackAddAtomic decomposes a multi-subsection section into multiple single-section sections, each accompanied by its own WorldPosition object.  A DynatrackDrawer object is created for each section and added to a dynamic track list.

Each DynatrackDrawer’s constructor creates a DynatrackMesh object, which defines the visual representation of the track section.  All MSTS dynamic track curves are left-hand curves.[1]  That simplifies mesh generation a little bit, but in TDBTraveller you have to worry about both types of handedness.

When the PrepareFrame method is called for each DynatrackDrawer object, the mesh and accompanying transformation matrix are added to the impending frame.

Grade-Reckoning Methods

There are two tasks for which computing elevation along a train’s path is required.  They are (1) mesh-building for the visual representation of track and (2) TDB traveling.  It is important that the computation be accurate and consistent for the two tasks.

The Ideal Way

Grade is generally defined as the rise (change in elevation) over the run (the distance traveled).  It is common to express it as a percentage (100 * rise / run).[2]  Hence, a one percent grade should result in a one meter rise in a 100 meter run.  This should be the case whether the track path is straight or curve, but it is important to point out that, in the case of a curve, the run is the distance traveled along the path of the curve.

The way that elevation changes with run should be linear – unless smooth transitions in vertical curves are attempted.  Track cross sections should be level – unless superelevation is attempted.

Although these are reasonable objectives for Open Rails, there is another objective that conflicts: Open Rails desires to be compatible with MSTS.

The MSTS Way

It is not widely known that MSTS does not produce grades to the specifications outlined above.  It does handle straight sections properly, but it does not handle curves properly.  Let’s examine what MSTS does.

When track is laid in the MSTS route editor, some unexpected things happen.  Consider a simple, but extreme case.  Let’s say you have a straight section oriented due north.  You lay a 100-meter radius, 90° curve joined to the straight section, and you incline it at 1°.  What is the elevation of the far end?  Strange things happen:

1. Given the ideal method above, we compute the distance along the periphery of the curve as 50 .  With a 1° inclination, the percent grade would be 1.75, and, with a run of 50π, the rise should be .875  meters (2.75 meters).  But it isn’t.  (Check it out.)  The rise produced by the MSTS route editor is 1.75 meters.  We got short-changed a meter (36%).
2. Although the curve starts with a 1° inclination, it finishes level.  (Think about it; the section is a 90° curve.)
3. As judged by adjoining straight sections, the curved section is tipped on one or both ends.

These problems stem from the way that MSTS rotates a track section to achieve an elevation change.  It rotates the section as a rigid body; you might think of it as the “plywood method.”  Think of the section fastened to a sheet of plywood.  Fixed in place at the curve’s point of beginning – the so-called Point-of-Curve (PC) – MSTS rotates the sheet of plywood to achieve the elevation change.  Depending on as yet undetermined conditions, MSTS may tip (pitch) the section down about an axis perpendicular to the tangent at PC.  (The axis joins PC to O, the center of the curve.)  Under other conditions, MSTS may introduce tilt (roll) about the tangent line at PC.  The situation gets yet more complicated for dynamic track sections with multiple subsections although the plywood analogy seems to hold.

Let’s analyze an actual curve from a route created with the MSTS route editor.  It is a 90° left-hand curve with a radius of 30 meters, pitched downwards 1.05°.  (This is a dynamic track subsection.)  In Open Rails, I logged the coordinates of the inner and outer edges of the ballast generated for the visual representation of this section, and I transformed the coordinates as directed by the world file entry for this section.  I plotted the elevation as a function of the actual distance run along the curve (in the x-z plane) --

The horizontal axis is the distance traveled (in the x-z plane) along the curve.  (It is the radius multiplied by the angle traveled in radians.)  PC is at 0, and the end (the Point-of-Tangent, PT) is at 47.12 (30π/2).  The vertical axis is the elevation (y) logged by Open Rails.  The two red curves are the elevations logged for the inner and outer edges of the ballast.  The green curve is the calculated midpoint (centerline). 

First, note that the initial slope over the first ten meters of travel is about .18/10.  That’s sin(1.05°).  Projecting that slope for a run of 47.12 meters predicts a rise of -.86 meters.  We’ve only achieved 64% of that, again, a 36% shortfall.

Second, the green curve (the centerline) starts downward at a 1.05° angle, but it ends up with a slope of zero – level.

Third, the two red curves exhibit about a .1 meter difference in elevation of the ballast edges at the end of the curve.  It’s tilted.

These are the results predicted by the “plywood theory.”  If the curve section is defined in the x-z plane and is rotated by the companion transformation matrix as a rigid body, then paths along the rigid body will reflect these three effects.

More on the blue line in the next section … .

The Open Rails Pragmatic Way

Why can’t Open Rails correct these anomalies?  Well, it can, but not for routes developed with the MSTS route editor.  First of all, the grade shortfall cannot be corrected.  The end points for route sections are cast in concrete at route edit time.  But, what can be done about the other two anomalies?

I contemplated attacking the second anomaly with the objective of making the path through the curve follow the blue line, that is, an elevation function that is linear with respect to progress around the curve.  I actually implemented that for both TDBTraveller and dynamic track mesh generation, but, “Surprise!” 

Terrain refined in the MSTS route editor with the terrain-flattening tool (Y-key) uses the green curve for its target elevation profile.  If we provide mesh generation that produces the blue line, our track ballast will be rendered above the terrain, which is fixed.  Worse, for an ascending grade, the blue line would be below the green curve, and terrain would spill over track.  The latter effect is a show-stopper.

Finally, in an attempt to eliminate the third anomaly, I decided that creating a mesh with level track built in was just too difficult for the gain.

Stuck with doing things the MSTS way for routes developed with the MSTS route editor, I at least managed to introduce code with a framework to lay track “the right way” – when we can create routes with an Open Rails route editor.  The beginnings of that structure were introduced as of SVN Revision 163 for dynamic track.  The primary motivation for the changes was to coordinate elevation computations between dynamic track and TDB travelers.

Mesh Generation

Each DynatrackMesh object depends on a definition of a “track profile,” which is a definition of the cross section geometry of a track section.  Currently, it is very simple, as illustrated by the drawing below.

Three groups of line segments comprise the profile:

1. Ballast (one black line segment): 0-1
2. Rail sides (four red line segments): 2-6, 3-7, 4-8, and 5-9
3. Rail tops (two green line segments): 6-7 and 8-9

These three groups reflect three levels of detail (LODs).  As a camera gets farther away from a track section, first its rail sides will be inhibited, then its rail tops, leaving only the ballast to be drawn.

This basic profile is repeated to define a mesh: one on each end of a straight section and one on each end plus one approximately every degree in the interior of a curve section.  The mesh consists of edges (lines) that run both in the plane illustrated above and longitudinally.  Each vertex on the mesh has an associated position vector, normal vector, and texture coordinate.

[1] Right-hand curves are made by laboriously laying out a left-hand curve and “flipping” it in the route editor.

[2] If an angular specification is desired, it should be sin^-1^(rise / run).