News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Changes to sighting distance

Started by Mariculous, December 18, 2019, 03:52:32 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

I have just split this from my original post that covered a huge bunch of  thoughts.

As discussed, sighting distance behaves pretty strange. There are two things we can and should do in the short-term:
1. increasing gradients should not affect the sighting distance.
2. curves should be handled consistently.
Im Simutrans, that means visually, sighting distance should reach to the first tile behind the next visual corner (including that tile), but when entering the tile before that one, the driver will already be able to see the whole straight track behind the corner.

I will give an approach on how we can implement both, as I just stumled across that code anyway, when seeking a bug recently.
We can extract that information from the route, which is simply a list of koords.
I will assume that we want to cache the next straight of track so we don't need to detect it again and again on each single movement step. Currently, this is not done afaik.

There are two different cases to handle: longitudinal movements and diagonal movements
We can differ these when looking at the direction in between the current, current+1 and current+2 koords.
Once we detected the type of the following straight, we can extend to it's end by comparing the next entries of the route with

//returns the last index of the current straight
get_last_straight_index(route, current_route_index, route_count)
  //We need to catch the case where we are at the end of the current route
  if(current_route_index>+2>=route_count)  //Three points in a route are always on a straight line, so we can simly extend sighting to the end of the route
    return route_count; //end of a route can't be a slope, so we don't need to take care of gradients here.
 
  //calculate direction in between current and the next and next and next+1 tracks
  d0=koord2d(route[current_route_index+1] - route[current_route_index])
  d1=koord2d(route[current_route_index+2] - route[current_route_index+1])
 
  //calculate starting gradient
  grad=gradient(route[current_route_index])

  //handle longitudinal movement
  if(d0==d1)
    //iterate the schedule from the current location to the end. Skip the first as we can for sure see the tile we are on.
    for(i=current_route_index+1; current_route_index<=i<route_count-1; i++)
      if(route[i]+d0!=route[i+1])  return i; //check if we stay on the route when continuing in the current direction
      if(gradient(route[i+1])<grad) return i; //check if gradient decreases
      if(gradient(route[i+1])>grad) grad=gradient(route[i+1]); //check if gradient increases. In that case we need to update the gradient.
 
  //handle diagonal movement, roughly the same as longitudinal movement but we ned to move in altering directions and gradient can only change at the end of a diagonal
  else if(is_perpendicular(d0,d1)
    d={d0,d1}
    for(i=current_route_index; current_route_index<=i<route_count-1; i++)
      if(route[i]+d[i%2]!=route[i+1])  return i; //alternating directions
      if(gradient(route[i+1])<0) return i;


Not caching straights won't change a lot. We will just need to start at the end of the yet existing reservation instead and need a max_sighting_distance condition.


In the long run we should do some kind of curvature radius approximation, which will also, combined with a Structure gauge
width, imply a sighting distance, but this is admitedly pretty much work and changes a lot.

Phystam

If the sighting distance of a train is shown like a "green" reservation, it would be very helpful.

jamespetts

Thank you for your thoughts in relation to this. For a human, reading (as opposed to writing) computer code is very difficult, so it is not immediately clear from your extract how what you suggest here would differ from the current algorithm. Would you be able to set out a list of functional changes so that I can consider this without having to parse this code (and then parse the current code, as I do not remember the details of how I implemented this now).

As to gradients, may I ask why you do not think that a rising gradient would impact sighting distance?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

#3
QuoteAs to gradients, may I ask why you do not think that a rising gradient would impact sighting distance?
Imagine you are walking along a way in the mountains. You are in the valley and have a straight way in front of you, towards and up the hill. You can see te whole way up the hill without any problems. (gradient increasing from 0 to positive in between the flat in the valley and the way up the hill) However, you will only see what's on top of the hill once you are close enough to it (gradient decreasing from positive to 0)

Now you reached the top of the hill and see a veeery long flat land on that hill. You won't be able to see the way down the hill (gradient decreasing from 0 to negative) until you are close enough to it, but you will be able to see the whole way down the hill and in the valley, once you reached the way down the hill (gradient increasing from negative to 0)

QuoteFor a human, reading (as opposed to writing) computer code is very difficult
Well, I guess I have read too much signalling code in the past few days.

So about the algorithm, I didn't have a look at the details of the current one but I observed some reservations of drive_by_sight trains, which is pretty inconsistent around corners.
Sometimes sighting is up to the tile behind the corner, as in my algorithm, sometimes it's only op to the tile before the corner and sometimes even that tile can not be seen before entering it.
While this behavior is for sure deterministic and even always the same for the exact same piece of track, it is not pretty easy to tell for a given section of track where exactly sighting distance gets cut by curves.
Just see the attached save, enable the reservations overlay and see the tram moving.

For drive_by_sight this is not as bad. The train will slow down at some point anyways
For any signalling system, however, consistent sighting distance is extremely important. It is pretty annoying if you place a signal just in front of a corner, as that tile is visually clearly visible from the straight track, launch a route and see a few years later that your steam trains that accelerate pretty bad brake down to nearly 0 speed because they can not see that signal before entering the tile.

So a short comparisation table of the main differences:

featurecurrentsuggested
min sighting distance13
consistentyesno
gradient changesdecreasing cuts, increasing desn'talways cut

Octavius

But objects above the track will often obstruct the view: overpasses, supports for overhead wires, the ceiling of stations and tunnels, various types of truss or tubular bridges, signal gantries, snow sheds and even tree branches, in places where trees aren't cut down before they become a danger to the railway. The driver can only see past the change in gradient if there are no such obstructions between him the the change in gradient and then he can still only see until the first obstruction after the change. If you can find a way to take that into account, fine.

Vladki

I think that a min and max sighting distance would be nice. E.g. Czech railways have rule that a signal must be visible for at least 12 seconds at top speed (eg. 400m at 120 km/h), or 100 m for shunting. The rules may differ by country, and be different for rail and road traffic. This value should be set as minimum_sighting_distance - defined for each way (lower for low speed track, higher for high speed track). This minumum rules out any obstructions like tress, bridges, etc. I real world, trees would be cut, and bridges built so that the signal can be seen. This minimum should be used to see "behind the corner or above the hill". This would be useful in stations to see ahead of junctions. And a related change in signalling would be nice - if train stops at station, and there is a signal in sight (even if ahead of junction), it will wait for clearance as if the signal is at the platform.

Maximum should be much longer - 1-2 km, but any obstructions (bridges, slopes, corners, tunnels) would stop it. And cab-signalling system could override this to infinity.

I did not know about the inconsistencies about signals on corners. For debugging this it would be nice to be able to show the current range of sight in similar way as for reservations. (maybe green color) ?

Mariculous

When implementing the above algorithm, I don't think we need such a minimum sighting distance as it will be 3 tiles, that means ~250m, just before leaving the first tile, which should be fine.
For drive_by_sight this should be sufficient. For any signal system without repeater signals, people should simply not put signals behind corners, just as in the real world. For repeater signals either standalone or n-aspect combined, sighting distance cut by curves does not really matter anyway, as signals should be placed in a distance that allows trains to stop from max speed in between the repeater and the stop signal.
However, if the min_distance is preferred, it it easy to adjust the algorithm to detect straights only up to the tile in front of the corner instead of one tile ahead (which is technically on a straight line). The most important attribute of the algorithm is consistency, so calculated straights could also be used e.g. to approximate curve radius with splines for better track speed approximation.

About the max sighting distance,this should maybe even be a parameter for signals.
Very early signals had trouble with sighting distances in some situations especially darkness for whatever the reason (e.g. night or bad weather), which for sure consists up to today for any kind of signals but was improved.

Cab signalling does not need (nor does it have afaik) any sighting distance checks at all.

QuoteFor debugging this it would be nice to be able to show the current range of sight in similar way as for reservations. (maybe green color) ?
I already thought about it and my idea was to add sighting distanced of signals to the signal(boxes) overlay.
So when the $ tool is enabled, something like the reservation overlay is dispayed in front of each signal, showing the area from which the signal can be seen. Any signals accidently "hidden" behind a corner, can be detected immediately without watching a train moving along. That sigthing distance overlay could even be color indicated, so green means "maximum distance". The more it turns to red, the smaller is the sighting distance. That could be useful in case there are multiple signals with overlapping distances as one otherwise won't be able to tell the arkers apart.

However, showing trains sighting speed, when in reservation overlay mode, could also be useful.

Vladki

Yeah I like the idea of max_sighting distance being an attribute of signal.  But min sighting distance is useful even if you have repeaters. Think of main signal clearing atfter the train passed the repeater at caution. If it is seen early, train can accelerate again. Perhaps it should be limited to 45 degree bends and S-bends, but not sharp 90 degree corners.

Could you make screenshots about the current problem - where the signal should be placed on corners? I'm getting lost in your descriptions.

Mariculous

I agreee that stop signals behind corners can be a problem, even with repeater signals, when the repeater was passed at caution, however I don't think one should hide signals behind corners in any case.

There are basically three cases:
1. Sighting up to one tile after the corner (image 1)
2. Sighting up to the corner (image2)
3. Sighting up to one tile before the corner (images 3 and 4)

In image 1 and 2 you can see that the train will look one tile after the corner, when it switches from straight to diagonal and one tile before the corner when it switches from diagonal to straight but that's not always the case.
Case 3 is admittedly relatively rare but that is the most critical one. So if you want to to safely place your signals always leave one tie free in between your signal and the corner.
There is yet another strange behavior about sighting distance after curves in image 5, where the train looks only one further tile ahead after passing the curve.

Images are taken when moving in drive_by_sight to better visualize sighting distance but this will also happen in any other working method that uses sighting distance.

Vladki

What is the difference between the track layout at #2 and #3. Why are they different?

Imho #2 is the only logical behavior.

DrSuperGood

Would be nice if one could see the sighting visibility range of a signal when selecting it with info view. This would highlight all tiles of rail which a vehicle can see the signal from while traversing.

jamespetts

Quote from: DrSuperGood on December 21, 2019, 12:46:43 AM
Would be nice if one could see the sighting visibility range of a signal when selecting it with info view. This would highlight all tiles of rail which a vehicle can see the signal from while traversing.

That would indeed be a good feature, although I suspect that it would take some time to implement. If Freahk would like to do this, then that would be splendid.

***

Thank you, incidentally, for the detailed explanation of what is proposed. I understand now the point about gradients: the idea that gradient changes are what should count does make sense.

I agree with Feahk that minimum sighting distances per signal do not make sense. The three tile minimum does have some merit to it, too. The screenshots illustrate the inconsistency issue well.

Freahk - if you would like to code something to deal with all of these issues, that would be most useful. Thank you for working on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

#2 and #3 is exactly the same just a few seconds later. It's just to demonstrate the train did see the straight except for the last tile and will slow down instead of extending sighting distance.

QuoteFreahk - if you would like to code something to deal with all of these issues, that would be most useful. Thank you for working on this.
I just started a transportfever mod but well, christmas hollidays in university will give some free time :D

jamespetts

Quote from: Freahk on December 21, 2019, 03:00:27 AM
#2 and #3 is exactly the same just a few seconds later. It's just to demonstrate the train did see the straight except for the last tile and will slow down instead of extending sighting distance.
I just started a transportfever mod but well, christmas hollidays in university will give some free time :D

Christmas holidays are a wonderful thing!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Related question - how do the slopes affect signal visibility now?
I was surprised to find out that signals just a tile after uphill are visible, and signals after downhill slope are not.
Could be observed on stephenson siemens game on turningford - gosish line
Downhill on  these places: (576,288); (567,240); (580,145) - trains (class 312) slow down, but uphill at (580,169) goes full speed. I would expect quite the opposite