[jtr1962]

 WaltN, on 10 September 2018 - 07:23 AM, said:

Assuming that your first picture is a screenshot from MSTS as you asserted, what is that double-line moving across the sky? Looks like it might be a "TDB-connector" from RE.

That's a track. MSTS doesn't cull tracks which are viewed from below.

Quote

Also referencing your first picture, perspective can be very misleading. The ties seem to sloping in a clockwise direction in the foreground, which suggests a twist to the right. However, the left-hand side of ties is closer to the viewpoint than the right and lower than straight ahead from the viewpoint. Moreover, the twist crossover is about equal in altitude to the viewpoint, and beyond that point, we are merely looking at the underside of the track. Now, it surprises me that the underside is not culled out by the graphics routines. I don't recall whether MSTS displays undersides. I can't check it, because my MSTS doesn't work at all with the current release of Windows 10. Can someone with any experience report that? If that's the top side, then a 180-degree twist has to occur in the region where the perspective projection is most narrow. No way!

Same thing here regarding displaying the underside of track. After the twist crossover you're indeed looking at the underside of the track. To add to the weirdness, when MSTS renders the underside of track past a certain viewing distance it doesn't render the ties, only the rails (which explains the double-line moving across the sky).

Quote

I have a definitive diagnostic test for you to perform. In the MSTS route editor if at all possible, construct a section of dynamic track of length 1.57 (full quadrant) and radius 100 m. Pitch it up at a grade angle of 3 degrees (MSTS max). Record the y-coordinate of the start of the section. Construct another track section (dynamic or non-dynamic). Retain that section at level (no grade). Record the y-coordinate of the start of that section. The difference between those two y-coordinates will give us the numerical change in elevation (delta-y).

Finally, take a close-in screenshot (IN MSTS!) at which the two sections join. Get close enough to the junction to judge whether there is any mismatch in alignment.

I haven't used the MSTS route editor in ages. I'll see if I can manage this and post a screenshot later.

EDIT: I managed to do what you asked. I attached some screenshots. The elevation change is 5.234 meters. It looks like the end of the dynamic track at the end of the elevated curve is level as it's supposed to be. Or at least there's no mismatch in alignment which I can see.

Attached File(s)

•  Dynamic Track Test 1.jpg (156.93K)
  Number of downloads: 3
•  Dynamic Track Test 2.jpg (119.27K)
  Number of downloads: 4
•  Dynamic Track Test 3.jpg (144.95K)
  Number of downloads: 4

[WaltN]

Thanks much for taking the time to do that test. The fact that the end of the DT section is level suggests that the section is rotated as a rigid body (as though the section was cut out of plywood). That's the same shape that OR's travelers follow and the shape that is generated procedurally by OR at tile load time for each section of DT.

I plan on verifying that numerically tomorrow morning with your elevation change number. Thanks again.

[SP 0-6-0]

Walt, I meant when you look down the track and see how it goes up and down hills with the change in the land. The practice of aligning the track as your thinking of is another issue. I am talking about the natural formation of the steel rail on the ties with the slope of a slight incline.

Robert

[WaltN]

 WaltN, on 10 September 2018 - 12:16 PM, said:

I plan on verifying that numerically tomorrow morning with your elevation change number.

Here goes. Here's the situation:
 Quadrant.jpg (55.97K)
Number of downloads: 1

The curve we laid is red, a circular arc rooted at point O, of radius 100 meters, and 90 degrees in extent. In addition, the grade specified is 3 degrees of rotation. Now, I said that the way MSTS behaves is that the grade rotation is as a rigid body rotation, namely that the curve shape is not deformed in the third dimension (y). That is, the triangle OAB is rotated about axis OC by the grade angle. If that's the case, point A is rotated from y = 0 up to 100 Sin 3. If you have a calculator with trig functions perform the calculation; if not, the answer is y = 5.234 meters. Compare that value to Joe's measurement. Moreover, since triangle OAB is rigid and is rotated about axis OC, y is the same for point C. Q.E.D.

What else can we observe? Well, the initial slope is, in fact, that of OA (3 degrees). But what Joe's screenshot suggests is that the final slope (at point B) is 0. (The section following is level.) If that's the case, the grade angle through the curve must be decreasing -- all the way to 0. Not at all what we intended when we specified 3 degrees. How do we fix that? Exactly the way Goku has suggested, by building the vertical profile into the curve section. However, before we can use that section in Open Rails, Open Rails must change its behavior. Its desire to maintain MSTS compatibility has dictated the present behavior. Without such a change, trains operating on procedural curves on a grade will rise to fly over up-grades and submarine on down-grades, falling or rising, respectively, upon meeting a section end.

What I will now do is redevelop the formulas for an arbitrary point along the curve. (I've done it before, but did not save it.) I plan to present curves reflecting the height of the curve and the grade angle, comparing it to the specified grade or alternatively "rise."

[jtr1962]

 WaltN, on 11 September 2018 - 06:39 AM, said:

Here goes. Here's the situation:

The curve we laid is red, a circular arc rooted at point O, of radius 100 meters, and 90 degrees in extent. In addition, the grade specified is 3 degrees of rotation. Now, I said that the way MSTS behaves is that the grade rotation is as a rigid body rotation, namely that the curve shape is not deformed in the third dimension (y). That is, the triangle OAB is rotated about axis OC by the grade angle. If that's the case, point A is rotated from y = 0 up to 100 Sin 3. If you have a calculator with trig functions perform the calculation; if not, the answer is y = 5.234 meters. Compare that value to Joe's measurement. Moreover, since triangle OAB is rigid and is rotated about axis OC, y is the same for point C. Q.E.D.

And my measurement at first had me scratching my head. If MSTS was doing things correctly, the elevation change should have been sin(3°)*(2pi*100)/4 = 8.2209 meters. Instead, it wasn't because as you observed the slope starts out at 3°, but gradually flattens all the way to 0. There are two potential fixes for this. One is the fix you described. The other is to use very small curve sections when you have a curve on a gradient.

Another interesting thing is that both OR and MSTS calculate gradient resistance on curves based on the curves's elevation. Therefore, the physics at least don't need to be fixed if we implement either of the solutions mentioned.

Finally, we should note at present OR doesn't draw procedural track the way MSTS does. At least MSTS draws it in small enough segments so that the procedural track remains more or less parallel to horizontal in the y direction. OR draws procedural curves as if the entire curve was a single shape file. The end result is that one end of the curve isn't level. That's a bug which needs to be fixed ASAP.

[jtr1962]

I just tried making a 90 degree, 120 meter radius curve with 5 degree track sections. I elevated each of the 18 sections to 3° as I placed it. The theoretical elevation change of this curve segment should be 0.5*sin(3°)*120*pi=9.8651 meters. The actual elevation change was 9.853 meters, or only 0.12% less. Therefore, it looks like we can come very close even using rather course 5 degree sections.

[Genma Saotome]

Scale Rail has 5 congruent curves for each nominal radius, the idea being to NOT use multi-track shapes because the largest radius will be higher than the smallest. When using the individual congruent shapes it became clear right away that each had to be set down on it's own elevation in order to get all of the far ends at the same level. It was a PITA to lay but the result looked good.

Anyway, I mention this because Goku has said he won't be doing multi-track, which is fine, but absent a built in cant single track in congruent curves has it's own issues too.

[jtr1962]

 Genma Saotome, on 11 September 2018 - 06:20 PM, said:

Scale Rail has 5 congruent curves for each nominal radius, the idea being to NOT use multi-track shapes because the largest radius will be higher than the smallest. When using the individual congruent shapes it became clear right away that each had to be set down on it's own elevation in order to get all of the far ends at the same level. It was a PITA to lay but the result looked good.

Anyway, I mention this because Goku has said he won't be doing multi-track, which is fine, but absent a built in cant single track in congruent curves has it's own issues too.

Scale Rail also has curves in very small segments, like 0.125° for 4000 meter radius curves, which comes to a length of 8.7266 meters. By using small enough segments, you largely avoid the elevation mismatch issues. Wider curves would need to use segments with a lower number of degrees, but I'd say segments of 5 to 10 meters long are good enough under most circumstances to approximate what happens in the real world. Of course, this makes building curved tracks on gradients somewhat tedious, but as you say the results look good.

[WaltN]

 jtr1962, on 11 September 2018 - 01:35 PM, said:

Finally, we should note at present OR doesn't draw procedural track the way MSTS does. At least MSTS draws it in small enough segments so that the procedural track remains more or less parallel to horizontal in the y direction. OR draws procedural curves as if the entire curve was a single shape file. The end result is that one end of the curve isn't level. That's a bug which needs to be fixed ASAP.

EDIT: Remember, you did your experiment (following my request) with MSTS. That's what the rigid body rotation predicts. Think about it! If you rotate a quadrant of arc (90 degrees) and pitch it up 3 degrees, what's the slope at the far end, tangent to the curve. (Granted, the transverse slope is 3 degrees.) END EDIT

OR does procedural curves (DT) exactly the way that MSTS does, simply because of a desire for MSTS compatibility. If OR modified its current behavior, every route created for MSTS would have to be reworked so that DT sections match up with following sections. What would you do if you were in OR Development.

My solution is to provide a flag that specifies the design mode -- MSTS curves or proper curves.

[longiron]

 Genma Saotome, on 11 September 2018 - 06:20 PM, said:

Scale Rail has 5 congruent curves for each nominal radius, the idea being to NOT use multi-track shapes because the largest radius will be higher than the smallest. When using the individual congruent shapes it became clear right away that each had to be set down on it's own elevation in order to get all of the far ends at the same level. It was a PITA to lay but the result looked good.

Anyway, I mention this because Goku has said he won't be doing multi-track, which is fine, but absent a built in cant single track in congruent curves has it's own issues too.

I would consider myself a relative power user of Scalerail, after laying over 200 miles of it across all kinds of situations - yards, single and multitrack mainline, branches over gradients ranging from 0% to 2.4%. As Dave so eloquently stated, trying to lay multi-track on a gradient using individual congruent shapes is an exercise in extreme patience and futility if you ever want to align with multi-track pieces down the road.

It shouldn't be that hard to lay a 2T or 3T mainline on a grade, without encountering a 'jump' or misalignment at each section - no matter how small. I don't know how other train sim programs solve the issue - but they "appear" to have.