Topic: Nonsense rail physics?

[DrSuperGood]

The very first horse drawn trains have arrived to the server game. However I am struggling to get them to cope with inclines. A single 18 km/h horse will pull a single passenger truck at 18 km/h on the flat but fall to a painful <<1 km/h on a single incline (1 elevation difference, not a double incline). Trying with 2 such horses yields similar, but slightly better results. Only with 3 horses per passenger truck can it go up single elevation inclines at a reasonable speed while still dropping to 1 km/h towards the top of a single incline.

So I went ahead and tried the silly thing of 0 trucks and 1 horse. The results are that a horse pulling no load can achieve 18 km/h on the flats but only 7 km/h climbing an incline. The UI says it will drop as low as 4 km/h if multiple are chained but it seems pretty stable at 7 km/h. Now I am no expert on horses but I am pretty sure they can gallop up hills at a faster speed than 39% of their flat gallop speed, after all horses are often found in hilly areas.

Now I do not really know about rail physics but from a game play perspective this is kind of ludicrous. I understand that single slopes are meant to represent an incline of ~26.565 degrees which is kind of steep as far as transport goes. However that is the shallowest one can make an incline due to game limitations meaning more realistic inclines of 10 degrees or less over longer distances is mechanically not possible for the player.

I am not saying the physics itself is wrong but game play wise something is off.

[jamespetts]

This is quite a complex issue to solve, as it is necessary for all the various values to be fully consistent with one another in order for there to be any possibility of balance. There was discussion about this in relation to road vehicles some time ago, and not much in the way of resolution was reached, as no data was forthcoming. Indeed, without data, it is going to be very difficult to find any sort of resolution to this issue in a way that is meaningfully consistent with the rest of the game.

Do you or does anyone else know of any data on this subject that would allow the tractive effort and/or power of rail horses and/or the rolling resistance of horse drawn rail vehicles to be calibrated more accurately than they are at present?

[ACarlotti]

It seems that the main issue is that we can't directly build gentle slopes. We probably need some system for averaging these out over a longer period of time. (A similar problem arises in handling corners, although the solutions might not be exactly analgous.) To help account for the difference between the visual slope and the simulated slope, it would then be good to add the current gradient (averaged along its length?) alongside the speed in a convoys status window. However, I'm not totally sure how computing gentler gradients would work, and also whether it should be stored in the way (as a fractional adjustment to the way height), or computed on the fly for each convoy.

[jamespetts]

There is a system already that adds the effect of gradients together (working on the fly), although this is inherently difficult to calibrate accurately.

[ACarlotti]

Is that the case also on roads? Because at present, I seem to see road vehicles affect by gradients only as they are actually on the sloped road tile, whereas I was suggesting spreading the effect of (single) gradients over a number of tiles.

[jamespetts]

Is that the case also on roads? Because at present, I seem to see road vehicles affect by gradients only as they are actually on the sloped road tile, whereas I was suggesting spreading the effect of (single) gradients over a number of tiles.

I think that it works on roads - but I must confess that I cannot recall for sure now. I do not recall differentiating this by way type when coding the feature, however.

[DrSuperGood]

Possibly the way info window should show the interpolated gradient of the way tile? That way if the convoys have problems climbing a hill one can see what gradient they are struggling with. It need not even be in degrees, but could be in some internal unit as long as it is clear what is flat and extremely not flat.

[jamespetts]

I cannot see how this can be done, as the gradient is calculated on the fly based on the convoy's route and can thus vary depending on how the convoy has reached the tile.

[Ves]

Can’t the logic from the rail cornering be used? I believe that calculates a radius based on multiple tiles. Or, perhaps that was what you where saying is happening on slopes too already, James?

[Kirill Stepanoff]

Now I do not really know about rail physics but from a game play perspective this is kind of ludicrous. I understand that single slopes are meant to represent an incline of ~26.565 degrees which is kind of steep as far as transport goes. However that is the shallowest one can make an incline due to game limitations meaning more realistic inclines of 10 degrees or less over longer distances is mechanically not possible for the player.

May be it would make sense to accept different Z-scale?
26-degree incline on 250 meter tile gives height of 125 meters per Z-level. And it means for pak-Britain-ex that twodecker-tram or tall ship cannot fit in 100+ meter clearance of "low" 1Z-height bridge - clearance more than enough for Nimitz-class carrier.

[jamespetts]

Can’t the logic from the rail cornering be used? I believe that calculates a radius based on multiple tiles. Or, perhaps that was what you where saying is happening on slopes too already, James?

Corners are slightly different, in that what is calcualted is the turn radius by taking the angle between any two straight sections and the number of tiles between those two straight sections and working out what the maximum radius of curvature consistent with those angles would have to be in the Simutrans scale.

However, the basic idea of adding up tiles is indeed what is used for slopes - but this is done based on each individual convoy's route, not held statically in the tiles.

Kirill - what sort of calibration for the different Z-scale were you thinking of here, and how would this fit into all of the various sybsystems?

[Kirill Stepanoff]

Kirill - what sort of calibration for the different Z-scale were you thinking of here, and how would this fit into all of the various sybsystems?

I just was scared of 500 per mille gradients assumed by DrSuperGood However there are no traces of them in the code.

Gradients that present in the code are rather steep - up to 40‰ for 1Z slope and 80‰ for 2Z slope for railways, and slow and weak vehicles (read "horses") are more prone to reach maximum gradient penalty :-(

[jamespetts]

I just was scared of 500 per mille gradients assumed by DrSuperGood However there are no traces of them in the code.

Gradients that present in the code are rather steep - up to 40‰ for 1Z slope and 80‰ for 2Z slope for railways, and slow and weak vehicles (read "horses") are more prone to reach maximum gradient penalty :-(

Thank you for taking the trouble to look into the code for this. I have to say that I have had trouble calibrating gradients - anything less than I have specified seems to have no effect on more powerful trains, which then gives players no incentive to build level track, which is entirely at odds with reality, but these values seem to be too harsh on horse transport. I wonder whether we might fudge it a little by reducing the effective gradient slightly for bioligically powered vehicles until we can find a way of calibrating this more accurately, which improved calibration has so far proven elusive?

[ACarlotti]

As far as I can tell, the code for determining calculating resistance due to the gradient is in simvehicle.cc line 1963, vehicle_t::calc_drag_coefficient(). This only takes into account the slope of the current tile, although it seems to update to the new gradient on a hill over two steps, and then takes a few steps to return to the base level after climbing a hill. If curve_friction_factor is nonzero, the behaviour doesn't look sensible

It does not do any averaging over surrounding tiles, which I think is necessary to simulate gentle slopes, such as are needed on a railway. Such averaging could be done either as an attribute of the way, or within the vehicle or convoy. The former approach seems better, as this would involve less computation, and would be consistent between all vehicles using the way.

I think a reasonable approach would be to assign a 'microheight' to each edge between adjoining way tiles. If this tile is an intersection, then this microhieght is forced to be the displayed height, and if the tile has an obstacle (another way tile or building) within two levels above or below it, then this microheight is forced to be at most or at least the displayed height. Otherwise, for each slope tile, search up to 2N tiles along the way (where N is the maximum distance in one direction to average over), until reaching another slope, an intersection, or a obstacle above/below the tile (depending on whether we're averaging a downhill or uphill slope). The linearly interpolate the microheight between the two end points (which are either the middle of a slope tile, with a height of +/- half the height difference per level relative to the level section of way; or the edge of an intersection or tile with an obstacle, with a height equal to the displayed height). This gives a height at each edge, which can be used to assign a gradient to each direction on each way tile.
(Note that there are some inconsistencies in what I write here that should not be included in an implementation, but the basic idea is correct.)

I'm not sure what the best value for N would be - that's probably something to determine partly by experimentation. However, given that shallow gradients are (I believe) currently 4% (uphill in the physics engine; downhill is less for some reason), a value of N=4 would give a minimum gradient of about 0.5% (+/- some imprecision in my definition of N). Does that sound like a reasonable gradient for an early railway? Perhaps N should be different for rails and roads, although that would create inconsistencies for street-running trams.

This does mean that building sloped ways will come with some implicit earthworks (in open terrain, but not in busy terrain). This could be taken into account in the cost of building sloped ways, although it could equal be decided that the land should never have been perflectly flat up to the slope in the first place, and we are just countering Simutrans' lack of infinitesimal variations in height and gradient.

[jamespetts]

These are very interesting ideas - thank you for that. This might well be a worthwhile thing to implement. I will have to look into this when the current set of projects are completed.

As to the calibration of the gradient height, perhaps if gradients are re-done, it might be worthwhile having this as a simuconf.tab setting to allow easy recalibration in the future?

Edit: I have now added this suggestion to the list of projects. Also, as to the cost: I think that it would be clearer for the player not to vary the cost of building on an upward slope (especially as there will be some circumstances in which there are no implicit earthworks, so it will be very confusing to players to know what to pay), and we can sensibly assume for our purposes that the land being simulated is only approximately depicted by the displayed terrain in any event as you suggest in your final paragraph.

[Vladki]

Hello,

just a link to previous discussion about the slope/gradient issues:
https://forum.simutrans.com/index.php?topic=16815.0

Please look at it I have started some research, but did not find time to finish it (got distracted by other interesting things)...

My idea is that you cannot scale the Z-axis in the same way as XY-axes. That woud be full height slope being 24.23° (or 45%) and half height  12.40° (or 22%). Both are indeed very steep.

What I propose is to make it according to required clearance. Half height slope has not enough clearance under bridges, but full height does. What about 4 m for half height. If we make the calculation with 125 m/tile and 4 m for half height slope, we get some gentle 3% (or 6% for full height). Nice slope for road, but still quite steep for rail.

I'm not sure if penalising consecutive slopes is good idea. IMHO two consecutive half-height slopes should be easier to climb than one full-height slope.

Also the game physich works with "friction factor", which IIRC is the slope in %. Roads have a default friction factor =2 even on level road. I think this shloud be removed, because for all vehicles  their own rolling resistance can be specified, and there are already some sensible default for road/rail/... So this is just extra non-sense penalisation of road transport.   However a per way extra friction would be nice to differentiate between dirt road/gravel/cobblestone/asphalt/...

If you have any questions, just ask. I'm willing to dive into the code again and try to find a solution

[jamespetts]

The most important thing with any changes of this nature is to make sure that everything stays consistent with everything else and does not produce anomalies. There is no problem in principle with a different scale (for physics purposes) on the Z axis than on the X and Y axes, sine this will not cause anomalies elsewhere, and we should indeed make sure that whatever the gradient of a half height slope is presumed to be, it is always exactly half of whatever an equivalent full height slop is presumed to be, but, if I have understood A. Carlotti's proposed system correctly, this symmetry should not be broken (A. Carlotti - have I understood this correctly in this regard?).

In relation to the friction factor, surely there is no problem with the current arrangement, given that the gradient is (if I recall correctly) added to rather than multiplied by the base friction factor? (If it is multiplied, then perhaps changing it to be added would make the hill physics more consistent? Indeed, if this is multiplied, that might explain some of the difficulties. I have not looked into this recently, and do not recall the precise algorithm used.)

[ACarlotti]

In the diagrams below, "-" represents level ground, "+" represents an intersection (or equivalently a restrictive over/under bridge), and "u"/"U" and "d"/"D" represent uphill and downhill slopes from left to right, with capitals representing steeper slopes. I'm going to list the physics gradient of each tile assuming that 40 represents the gradient of a single change in level in the length of a single tile. I'm going to take N to be equal to 4.

+u+ = 0|40|0
+U+ = 0|80|0
+uu+ = 0|40|40|0
----u---- = 2|5|5|5|6|5|5|5|2
----U---- = 2|5|5|5|46|5|5|5|2
----uu---- = 2|5|5|5|23|23|5|5|5|2
+u---- = 0|23|5|5|5|2
----ud---- = 2|5|5|5|6|-6|-5|-5|-5|-2 (this is slightly different to the literal specification in my previous post)
+-u-+ = 0|13|14|13|0
+u-+ = 0|27|13|0


There are a couple of issues to take into consideration.
Firstly, how should the scaling change if the metres per tile changes? Either we can say that each level corresponds to a fixed height difference (which means that bridges have a consistent height), in which case the displayed gradients will be steeper with less metres per tile. In this case, we can in increase N to ensure that gradients in open terrain are reasonably gentle. However, this present problems in cities when the junctions could be too close together. Alternatively, we can scale the height difference in proportion to the metres per tile. However, this then means that bridge height vary depending on the metres per tile setting, which seems undesirable. As James suggests, this could be a pakset setting, in which we don't really have to pick one option or the other here.

Another issue is that this only partly mitigates the issue mentioned by Vladki, in which convoys struggle with hills adjacent to intersections. One way to improve this would be allow gradients to be spread out through intersections as well, but that will increase the complexity of the code.

[Vladki]

@ James: base friction is added to slope "friction", not multiplied

I think that slope height should be independent of meters_per_tile scale. Perhaps specified per pakset in simuconf.tab.
The question is if slope height is to be specified, which will lead to different slopes with different meters_per_tile, or if the gradient (in %) should be directly specified - leading to different "height" with different meters_per_tile. I would advocate for specifying the gradient directly. Then it would be easier to balance it somehow reasonably. Even if it would mean that the clearance under the bridge is non-realistic. It is not realistic for ships and planes anyway.

[jamespetts]

A. Carlotti - thank you very much for your helpful illustration of your suggestion here. I agree with Vladki that it would be better for this not to be dependent on meters per tile, as the meters per tile setting is intended to define the x and y axes, and this system assumes a different scaling for the z axis in any event.

What we might do is have a "meters_per_vertical_tile" setting in the pakset, which would then be easy for pakset maintainers and players alike to understand and make consistent with the existing systems.

[ACarlotti]

(Written in reply to Vladki:)
I would rather go with settings "height per level" and either "minimum physics gradient" or "gradient smoothing distance". We would then have that 2N (or maybe it should be N?) in my earlier post corresponds to "gradient smoothing distance" divided by "metres per tile", and "minimum physics gradient" equal to "height per level" divided by "gradient smoothing distance".

If height per level and gradient smoothing distance can both be set, then together they determine the gentlest gradient that you can build. On the other hand, the steepest possible gradient would be determined by "height per level" and "metres per tile". If trying to handle a really small "metres per tile" we run into issues with the city road building code not adapting to different settings of "metres per tile", which makes steep slopes unavoidable. But maybe undesirable stuff happens in that case already.

[ACarlotti]

The current code and settings for pak128.Britain use (I believe) a height per level of 5 metres, which can currently be smoothed over a maximum distance of 125 metres (equal to the metres per tile). My suggestion is to make 5 metres per level explicitly configurable, and to make the maximum smoothing distance equal to 1km by default.

[Vladki]

AFAIK there is no height per level setting now.

Currently the friction on first tile of half height slope is 23, full height 47.  If I understood the code correctly, it is the slope in per mille (I might have errorneously written % somewhere). That is not very steep for road, and the height difference for one tile (at 125 m) is 2.875 m for half height and 5.875 m for full height. Just barely enough for single decker bus. Not enough clearance for overhead wire or double decker. Yet road vehicles have problem to climb this hill. So there has to be a bug in the slope physics code or in calibrating the tractive effort (maybe it is using per cent instead of per mille somewhere). If we get this right, we won't need the "gradient smoothing" proposed by ACarlotti, and I would prefer to get rid also of the current system of making consecutive gradients steeper.

[jamespetts]

Vladki - that is interesting. I wonder whether there is a bug somewhere - but would a recalibration of this mean that moderately powerful trains would then find all gradients to be of no significance at all? It is important that any change to the physics code allows for even relatively modest grades to have a significant effect on the performance of railway locomotives, especially steam locomotives.

[ACarlotti]

There is certainly a bug in there, in that the behaviour of the current code is inconsistent, although it's hard to tell what the intended behaviour is. I don't think it's worth worrying about in detail though, as if convoys are failing to get up short hills now I think they would also fail in a corrected version, and I think the whole section of code should be modified.

Vladki, I think we really do need some system of smoothing to be able to balance the game. To give some relevant figures:

Steepest UK mainline rail gradient: Lickley Incline, 2.65% (over 3km, so a rise of about 80m)
Early railways: apparently limited to around 0.05%
Steepest road: around 30%
Steep roads: 10% counts as steep (on signage), I'm not sure if anything gentle is signed.
Modern railways: I don't think I'm aware of gradients less than around 0.5% (or something similar) being marked as such.

If we wanted to simulate this full range of possible slopes directly, then we would need almost 1000 different possible gradients. Now I think we can probably ignore some of the more extreme gradients, but we certainly need more than two different gradients to get any degree of realism.

With the numbers I suggested above, we would be able to simulate slopes ranging from 0.5% to 8%. This does still chop off stuff at each end of the range, but it might be enough to work with.

[Vladki]

I have managed to buy a book about the Budweis Linz railway (horses 1820's). I'll look for an translate relevant info (slope gradients, curve radii, how many horses pulled how much load and how fast.

[Kirill Stepanoff]

----ud---- = 2|5|5|5|6|-6|-5|-5|-5|-2 (this is slightly different to the literal specification in my previous post)

I think that something like
2|6|6|6|2|-2|-6|-6|-6|-2
would be more realistic for this case - "vertical curves" tend to be S-curve and avoid rapid gradient changes.

[ACarlotti]

That's true for railways and high speed roads, but not as true for low speed roads. However, the reasons for this (comfort and avoiding derailment/skidding, due high vertical acceleration) are not simulated in Simutrans. The gradients I listed were calculated according to a single consistent rule, and I think deliberately trying to implement vertical curves would be unnecessarily complicated (although certainly doable). Most of the gradients I calculated did happen to have curved ends, but that was only a side effect of terminating the slope in the middle of tiles, and not a deliberate design decision.

[jamespetts]

Thank you all for your thoughts on this. ACarlotti - can you elaborate on the inconsistency that you have found in the behaviour that leads you to believe that there is a bug in the code?

[ACarlotti]

Some of the main issues in the results of the current code:

• The force due to downhill slopes is less than the force due to uphill slopes. They should (from a physics perspective) be equal.
• The current code for smoothing gradients gives inconsistent results to the total force (averaged over distance) for some combinations of different slope values, due to varying use of min and max without accounting for what the previous slope was.
• The addition of curve_friction_factor looks problematic, but might be ok as long as it's never too large.

I could fix these issues separately, but I think it would be more efficient to leave that code alone until we've decided whether or not implement gradient smoothing properly.

[jamespetts]

Some of the main issues in the results of the current code:

• The force due to downhill slopes is less than the force due to uphill slopes. They should (from a physics perspective) be equal.
• The current code for smoothing gradients gives inconsistent results to the total force (averaged over distance) for some combinations of different slope values, due to varying use of min and max without accounting for what the previous slope was.
• The addition of curve_friction_factor looks problematic, but might be ok as long as it's never too large.

I could fix these issues separately, but I think it would be more efficient to leave that code alone until we've decided whether or not implement gradient smoothing properly.

Ahh, yes, that would be sensible indeed. I am in favour of gradient smoothing as indicated, but will not be likely to have time to implement this myself until after the current round of vehicle management features are completed.

[Vladki]

This is going to be a longer post about roads and early railways in Austro-Hungarian Empire

First I will deal with roads - so called imperial roads (or state roads) were built 1740–1850 accordig to "french style" most probably it was the method of
https://www.britannica.com/biography/Pierre-Marie-Jerome-Tresaguet
https://amedia.britannica.com/700x450/45/23945-004-EA668418.jpg
Such roads had very similar surface to later macadam roads, the difference was in lower layers (macadam was cheaper).
So for the sake of rolling resistance, we can consider them to be the same as macadam. They were often built in straight line, so they also had to climb quite significant hills. The maximum gradient was 4.16 % (imperial roads exactly 3 inches/fathom, austrian inches were a bit larger than english, but 1 fathom is 6*12 inches in both systems), 4.70 % (state roads), 5.50 % (land roads) and 6.25 % (regional roads). The state norms defined also the width and other parameters, but that is not important now. There were often pubs or post stations at the bottom of steeper gradients, where it was possible to hire extra horse(s) to help. Maximum permitted weight of loaded waggon was 3360 kg (i think including the waggon itself). No more than 6 horses were allowed to pull single waggon. I have checked a piece of old (land) road that is still in use and it has 5% gradient (50m/1km). https://en.mapy.cz/s/2rdle  I think we can safely assume that 6 horses can pull 3.36 tons on 5-6% gradient even if very slowly (3 km/h ?)

To get an idea about speed of travel: in 1826, fast post coach with passengers travelling cca 310 km from Prague to Vienna took cca 34 hours, including stops for meals. So the overall average speed was almost 9 km/h (without stops it could be even 10 km/h). There is no information how often they changed horses. The road exists till today - just with modern surface, but the trajectory is the same as 200 years ago. https://en.mapy.cz/s/2rdbs

To be continued - about horse drawn railway Budweis - Linz

[jamespetts]

That is very interesting - thank you.

[Vladki]

So, about the horse railway Budweis (České Budějovice) - Linz. I was built between 1827–1836. The primary purpose was to carry salt from austrian salt mines (that's where Salzburg got its name) to Bohemia. Water channel was considered many times to connect Donau and Vlatava, but in early 19th century a railway was recommended. The chief engineer F.A. Gerstner visited England before the construction, so he knew about steam operated stockton-darlington railway. He decided that stationary engines pulling cars on cables are not the way to go. Although this railways was horse drawn, he built it with steam operation in mind. The northern part is built with max gradient 1.0 % and min curve radius 189 m (100 austrian fathoms). It is constanly rising up from the Vltava walley to the watershed on Bohemian-Austrian border. Unfortunately, the construction in this manner was too expensive, and F.A.Gerstner was fired. The southern part was built by M. Schonerer more like narrow-gauge railway. Cutting costs per mile to half in comparison with the northern part, but minimum radius was only 38 m. It was also going up 2.17% and down 1.43%, closely copying the terrain. When the track was rebuilt for steam operation in 1870's, the norther part was used almost "as is", only with some curves rebuilt to radius 250/284 m. But  the southern part was completely abandoned, and new track was built in different trajectory (max grade 1.3 %, min radius 284 m).

I don't know where Acarlotti got his information about early railways having only 0.05% gradients, but as you can see horse railways were able to overcome some decent hills. Of course at the steepest part of this railway, trains had to be split and extra horses employed. More on that later.

This is the design of rails: https://cs.wikipedia.org/wiki/Kon%C4%9Bsp%C5%99e%C5%BEn%C3%A1_dr%C3%A1ha_%C4%8Cesk%C3%A9_Bud%C4%9Bjovice_%E2%80%93_Linec#/media/File:Konka_koleje.jpg

to be continued...

[ACarlotti]

I don't know where Acarlotti got his information about early railways having only 0.05% gradients, but as you can see horse railways were able to overcome some decent hills. Of course at the steepest part of this railway, trains had to be split and extra horses employed. More on that later.

From a terrible source -  https://en.wikipedia.org/wiki/Grade_(slope). So I think we can probably disregard that figure. In any case, that seems to be referring to early steam locomotives, rather than horses, and it also doesn't imply that they were incapable of handling steeper gradients.

I think 0.5% would be a sufficiently low minimum gradient (and we could make that a bit steeper if desired). What about the steep end? Do we want gradients above 8%?