Gradient accuracy in Trainz

mezzoprezzo

Content appreciator
.
Help please from the wise ones.

I’ve been modelling the Swanage Railway and have recently acquired the gradient profiles from The Oakwood Press, “Swanage 125 Years of Railways”, by B. L. Jackson. I’ve been applying these gradients to my tracks.

I’ve completed the full run of the main & branch line from Wareham to Swanage, a distance of approximately 11 miles.

I started modelling the route from Corfe Castle station, approximately 6 miles down the route. The gradient profile, helpfully, also gives the elevations of some of the stations. Corfe elevation is given as 24m. I adjusted all of my trackwork from that point, converting the “one in ..” numbers from the profile to the percentages required for the apply gradient tool. I input all of the climbs, falls and levels back up to Wareham, and down to Swanage.

On checking the outcome, Trainz gives an elevation for Swanage of 4.07m. The published gradient profile gives 4m. Not bad eh, given that there were fourteen changes of gradient in that section alone! The tiny difference must be rounding because the gradient profile only gives integers - or so I thought.

My delight soon turned to confusion.

Here’s the problem, there’s a station, Harman's Cross, two miles down from Corfe which is the highest point of the line at 48m. Trainz track vertex height shows this at 43.91m.

I get another error at Wareham where the published elevation is given as 5m, but Trainz vertex height gives 2.36m.

I’ve checked other sources such as maps and Google Earth. Although the latter is well known for elevation errors, it is still closer to the published Gradient profile values than the heights arrived at by Trainz.

Now, I’ve checked and rechecked the input values to the Trainz apply gradient function and cannot find any errors. Wherever possible I’ve managed to precisely locate the positions of where the gradients change. I’ve done this, painstakingly, from images and from freeze framing the Swanage to Wareham Cab Ride DVD which captions the screen at each gradient change. The latter can be further fine tuned because several of the gradient posts and arms can be seen on screen as the DVD cab ride passes them. With the added use of Google Earth and other imagery it’s even possible to position some of them in line with individual sleepers!

I’m quite happy to do yet another cross check of all of my work so far, but there seems little point if this is a known “fault” with Trainz (or my ancient edition).

Is my method unreliable, or have I missed something obvious?

I’m getting frustrated with it now. It’s holding up my landscape painting & decorating. I do want to get it right though so that the physics of the route will be correctly reflected and the finished article will look and feel right in operation.

All advice gratefully received.
 
On a DEM the first thing I do is almost sink all the track spline points, almost just a hair below the surface.

This would be the tree top topography (unless it is a desert DEM).

When a gradient shows something ludicrous like 3.75%, that is too steep.

When a gradient is @ 1.75% that is the maximum on most RR's.

Also the transition from a downhill gradient, should not abruptly, swing to a ridiculously steep uphill gradient ... there should be several subtle gradients in between. Never hit the smooth spline tool until months down the road, once you have perfected the gradient. Instead work in the wireframe mode, by dialing the time of day to a eye pleasing semi-sweet chocolate color.

You will develop a feel for those spline point arrows, and know when the arrows have 2 or more segments, that they are too high, or too low.

Using free Skype, I would be more than happy to tutor anyone on gradients and trackwork.

90% of my tracklaying is done from looking straight down from directly above.
 
Hmm....... Don't know about 2004 but in 2009 upwards it doesn't take much of an error to throw things completely out, should try the gradient profile for the Welsh Highland which has long bits of 1 in 40 and a couple of reverse curves thrown into the mix took me about two weeks of continuously adjusting to get it anywhere near right. I don't think most gradient profiles are actually more than an average between two points and don't reflect the actual variations in-between.
Re your problem, you may find increasing or reducing the gradient very slightly over a couple of miles will get you to the correct height, it's what I ended up doing, Say make 1.8 1.9 or 2 that sort of thing.
 
.
@ cascaderailroad

Thanks cascade.

I haven’t used a DEM. If I did, I don't think I'd use one as a base to lay a track. I’d sooner use well documented, detailed and accurate track information as a basis for creating a realistic route. My basemaps allow accurate lateral placement of the track. It's the application of accurate gradients I now want to get right.

The gradient profile I’m using appears to be authentic. The steepest grade is 1 in 65 (1.54%).

I've already laid a lot of landscape, but the finishing will only be done when the track gradients are correctly set, not before.

I’ll also use the Cab View DVD to ensure that cuttings and embankments are correctly placed and adjusted to reflect reality.

I've seen some nice DEM results for general landscaping, but I'm not sure it would help with rural single track line-side detailing, particularly with UK data.

Thanks too for the Skype offer, but I don’t use it.


@clam1952

Thanks for your observations and experiences on arriving at a solution. I think I’ll run with your method, unless there are any other possibilities which might pop up from other users.

There are three quite long sections of a mile or more with steepish grades of 1 in 76, 78 & 80 which should give me some scope for adjustment.
I did wonder if there might have been some underlying obscure issue such as too few (or too many) spline points perhaps influencing how the geometry might work.

I did have one road crossing (a flat object) linked to one part of a long gradient, which I removed. That corrected some, but not all, of the “error” at one end.

I presume placing track objects, signals etc. on the line, shouldn’t cause a problem. I've signalled quite a lot of it already and disconnected all of the points and sidings which caused grief in the beginning.

Any other observations would be welcome, before I finally nail down the track and get on with the landscape.
 
Last edited:
. Is my method unreliable, or have I missed something obvious?

If your distance from one point to the next is correct, and if you calculate and apply the gradient correctly, then that next point should be set to the correct level. There's no reason that won't work over any number of segments. Where you have level segments, such as a road crossing, then you will need to insert that later, and that will affect the measured gradient either side, but there's no way around that. It's not clear from your description whether or not the points where the height doesn't match were part of your gradient-setting procedure. If not, then the effect that you are seeing is because Trainz calculates heights within segments using a smoothing function similar to that applied to horizontal curves - the height of the track at any point is a function of the gradient of that segment and the (vertical) angle at which the adjacent segments attach. This angle might be very different than the average for that adjacent segment, depending on the change in gradients that occurs between the two segments, and that can create some local gradients that vary considerably from the average over the segment. If it is possible that this is what is happening then you need to drive along the track using the gradient display in the HUD to check for variations from average. You can reduce (but not eliminate) these variations by adding new spline points at carefully calculated heights, but some exaggerated waviness will remain despite every effort.
 
If your distance from one point to the next is correct, and if you calculate and apply the gradient correctly, then that next point should be set to the correct level. There's no reason that won't work over any number of segments. ~snip~
That’s what I thought.


~snip~ Where you have level segments, such as a road crossing, then you will need to insert that later, and that will affect the measured gradient either side, but there's no way around that. ~snip
I have a few level segments where it matches the gradient profile, but these are track sections only, so I’m assuming that these, with 0.0% values, are OK. I have removed the one and only road crossing object, which imposed the obligatory short flat section. I do have a few crossing boards which are trackside objects, but these don’t seem to impact the gradients, so I’m assuming it’s OK to leave these in.


~snip~ It's not clear from your description whether or not the points where the height doesn't match were part of your gradient-setting procedure. If not, then the effect that you are seeing is because Trainz calculates heights within segments using a smoothing function similar to that applied to horizontal curves - the height of the track at any point is a function of the gradient of that segment and the (vertical) angle at which the adjacent segments attach. This angle might be very different than the average for that adjacent segment, depending on the change in gradients that occurs between the two segments, and that can create some local gradients that vary considerably from the average over the segment. ~snip~
The height points were direct observations of the Get vertex height values after all of the gradient percentages had been applied from my central start point. However, I did notice that some of the values had changed, by a few decimal points, from what I had originally entered. Thinking that this was an error, in that the percentages didn’t match the “official” prototypical published gradient profile data, I went back over the route and re-input the “correct” values at each appropriate spline point. From what you have said perhaps I should have left them as they were. It would now appear that they had been automatically geometrically adjusted, in-game.

I also noticed some very badly distorted sidings. They developed a switchback effect when the main line profiles were applied. I’ve therefore disconnected all of these to concentrate on getting the main line sorted. I plan to re-attach the points to these sidings if/when I get a satisfactory result on the main line, probably aligning them by eye or getting and applying appropriate adjacent spline heights.


~snip~ If it is possible that this is what is happening then you need to drive along the track using the gradient display in the HUD to check for variations from average.~snip~
That’s a different approach. I hadn’t thought of doing that and will check it out.


~snip~ You can reduce (but not eliminate) these variations by adding new spline points at carefully calculated heights, but some exaggerated waviness will remain despite every effort.
That seems to fit in with Malc’s observations and advice.

Thanks both for the collective wisdom.

I’ll go back and save the route under a new name, then re-apply the gradient values, without correcting what I thought were errors, and see how that pans out.
 
I do have a few crossing boards which are trackside objects, but these don’t seem to impact the gradients, so I’m assuming it’s OK to leave these in.

If they have the tag follows-gradient 1 they work well, if they don't just add the tag to the config. I made all my NG crossing that way so they work on a 1 in 40 without either having very obvious flat spots or crossings stuck up in the air at one end and buried under the sleepers at the other. Effectively it solves the flat spot issue.
 
Only works as far as I know on trackside assets, however it goes anywhere in the config so long as it's not in a container.
 
Well, no result yet!:(

I have checked, re-checked, and re-input the gradients along the whole route and still have exactly the same differences.

I guess there could be an error in the published gradient profile or it may have been badly averaged. I also cannot guarantee that all of my gradient changes are exactly placed, although I reckon on an accuracy of ±10m on the very few which I haven’t been able to precisely locate.

I’m now wondering if the direction of the track spline segments may have something to do with it. I’ve always be in the, “it doesn’t matter which way you lay track”, camp and have therefore never been diligent in laying tracks in the same direction. It has never shown to be a problem before, not even when running AI over some quite complex areas. However, I think it might be worth a look having just laid a track marker on every segment. I clearly have several facing, “the wrong way”.

I’m wondering if these “backward” facing sections may also have had something to do with buckling and distortion of some of the sidings which I described in an earlier post and have temporarily disconnected. I’m therefore going to re-lay the (possibly) offending track sections to see if this might help correct the gradients and get my elevation closer to the marked heights on the published profile. If nothing else it will at least make my signals and rolling stock face the right way when placed on the tracks!
 
I have never noticed that the track laying direction affected gradients, although it is easy to click in the wrong spot and get a negative when you intended a positive, or vice versa. Now that you have re-checked the gradients you need to look at a specific instance of the problem. Create a consist of an exact length (500m is easy) and use it to measure the actual track length in 500m steps, placing a milepost or other marker each time you relocate the consist. Add the marker distances together to give the track length, then calculate the end point height from the applied gradient. That should confirm your first assumption - that a gradient applied over a certain length of track will give the correct height at the end of that segment. If your map heights don't match the calculated height, then there is an error in the height information (a different datum, perhaps) or there is an error in the track length between map points.
 
Last edited:
Back
Top