Spoiler - Standedge Tunnel Bug Fix (proposals)

Discussion in 'Troubleshooting' started by synthetic.angel, Sep 8, 2019.

  1. synthetic.angel

    synthetic.angel Well-Known Member

    Joined:
    Aug 27, 2019
    Messages:
    1,484
    Likes Received:
    2,265
    The glorious NTP route is marred by one of its stand-out features - the Standedge Tunnel. There is a draw distance issue in this tunnel that needs to be resolved, because it totally breaks the immersion (where the natural focal point is the end of the tunnel), and breaks the belief that you are in a tunnel (even though you are actually in a continuous tunnel). This issue is discussed in this thread, for example:

    https://forums.dovetailgames.com/threads/pinocchio’s-nose.18060/#post-92944

    What is actually happening in this tunnel is that you are seeing the all-white netherworld, at the edge of two tiles ahead of you (or just over one tile ahead if you are approaching the tile boundary). When you cross the tile boundary the tunnel appears to get smaller again, because your view of the netherworld suddenly advances by one whole tile (a large distance, as discussed below).

    You can see this from a different angle in the attached two pictures (look at the size of the "ring" at the very end of the tunnel, as pictured):

    Standedge Close Tile.jpg

    Standedge Far Tile.jpg

    You can also see that these images were taken with a framerate at 60fps. There is no appreciable load on the processor, because there is nothing much outside of the tunnel (except at the ends). It's "just" a draw distance issue.

    If the processor draws everything in neighbouring tiles there is x9 stuff to draw (there are 8 tiles around you, normally - in a completely open world). If you can see two tiles ahead, then x25 tiles need to be drawn, and x49 for three tiles ahead, and x81 for five, etc. I would normally suggest increasing the draw distance, by doubling it, to remove the bug, but even if you could do this, this could make things quite complex and slow at the tunnel ends... (maybe..., or maybe not, because a railway line is not a completely open world....).

    If Standedge Tunnel is built to scale, then the model is 4806m long (in real world units). I walked down the tunnel (which has a floor, unlike the LIRR Penn tunnel...) to take a closer look. It is made from 12 sections of straight tunnel, 11 of which are about 425m long, and one that is 120m long (at the Greenfield end). Each section join is surrounded by a pair of tunnel portals, which hide the join (maybe), and probably contain scripted objects that communicate messages across the tile boundary. I wanted to test the bug, to see if it was a rendering or performance issue - it isn't, as it's a hard set draw distance limit problem.

    Proposed Solutions:
    1. Preferably, the draw distance, for the inner ten tile sections could be increased. If the draw distance is increased to five tiles (2125m) for the inner six tiles, and four tiles (1700m) for the pair that surround these, and three tiles (1675m) for the pair that surround the inner eight tiles, then this could fix the issue. The extra load on the processor would be minimal because there are not 80 tiles surrounding these central tunnel sections - it's built through a void space. I don't know if this is possible with DTG's set-up (but it should be, I think).

    2. If you can't change the draw distance for individual tiles (as above), then you could take a "smoke and mirrors" approach. On MSB, the builder has filled the long tunnel with a sort of mist. This could work on NTP.

    3. Or you could have "curtains" at each of the fake nine to eleven inner tunnel portals. These curtains would be black (or 80% black transparent, or gradient black, or a mixture) when they are in the distance, but when the curtain detects that you (or your camera) is within 10m, the curtain becomes transparent so that you then see the curtain that is 425 ahead of you, and you can pass through it when it is transparent without knowing it.

    4. There are other solutions that are "mirror" based - similar to the curtain, but with an image projected onto it (or transmitted from it), where that image is taken from sets of cameras in the tunnel, on the other side of the curtain, that are looking at the curtain ahead. (So that you can see the tunnel portal slowing increasing in size as you pass through each tile). This requires a lot of work.... (calculations of POV and perspective), but it could work. It's complex though, because this is a two way tunnel, and every new bit of rolling stock would have to be coded in. (It would be very fun to do, if you had the time and inclination....).

    5. Some combination of the above solutions.

    CONCLUSION
    This is worth fixing. The MSB fog/mist solution is quite nice - maybe just use that? But, if you (DTG) want a solution to the long tunnel problem, and you fix it now, then it can be re-used as a solution on future routes. It is worth fixing this.

    ASIDE: It would be nice if this tunnel had other internal features, such as the many adits and cross tunnels to the other two Standedge rail tunnels and the canal tunnel, plus some escape holes, storage spaces, leaking drips, etc. Not essential... but nice. But it's only worth it if the locos are given some light sources (from the headcode/markers or from the cab itself).
     
    Last edited: Sep 8, 2019
    • Like Like x 4
  2. InspectorTiger

    InspectorTiger Well-Known Member

    Joined:
    Jan 24, 2019
    Messages:
    147
    Likes Received:
    265
    Ah, that's very interesting! I've always wondered why that was.

    Nice analysis, thank you.
     
  3. synthetic.angel

    synthetic.angel Well-Known Member

    Joined:
    Aug 27, 2019
    Messages:
    1,484
    Likes Received:
    2,265
    I revisited MSB recently, and I have now realised that on a sunny day, that there isn't any "mist/fog" in the MSB tunnels. These tunnels are very well built though - they don't seem to suffer from the same fake portal problems. But they are also not a straight 4800m long...
     
  4. ARuscoe

    ARuscoe Well-Known Member

    Joined:
    Apr 9, 2018
    Messages:
    10,832
    Likes Received:
    10,482
    If you can see two tiles ahead, then x25 tiles need to be drawn, and x49 for three tiles ahead, and x81 for five, etc.
    Is this accurate, or does this depend on seeing the same on all sides and behind as well as in front?
    I'm not sure how many tiles to the side or behind remain in memory at any one time
     
  5. synthetic.angel

    synthetic.angel Well-Known Member

    Joined:
    Aug 27, 2019
    Messages:
    1,484
    Likes Received:
    2,265
    It depends how you set it up. I was just giving the general case for a completely open world. If you set the draw distance to five tiles, and your camera can turn around (quickly), then you need to have the stuff that was behind you in memory. If you are coding one of those forward VR roller coaster games that do not have a rear view, then you can have zero tiles behind you in memory. If you have strong limitations on camera rotation speed (say, a tank game), then you can afford to dump stuff behind you out of memory, and re-load it as needed.

    If you are in a train cab, then you can run the risk that the player won't look back, maybe. But TSW has free cameras on top of the character camera view as a key feature, so I don't think that is an answer.

    In a tunnel, which is built across, say 12 tiles, the middle ten will not have any tiles to the side. So you can ramp up the draw distance (I think - depends how it was set up).

    I will be posting some more detail here on Standedge in the coming days. I am also looking again at the Penn Tunnel, which has some structural flaws. That tunnel is also built under the Long Island City complex - something that I hadn't previously realised, so an increase in draw distance in that tunnel would lag the tunnel. But there might be other solutions available there. I reckon it would still take two days to fix that one though - even just to patch up the anomalies I found there.
     
  6. ARuscoe

    ARuscoe Well-Known Member

    Joined:
    Apr 9, 2018
    Messages:
    10,832
    Likes Received:
    10,482
    I would work on the principle of 3 steps forward, 1 step back and 1 that you're in (or two forward, five forward whatever) hence asking.
    Also wouldn't necessarily need so much width when working on a ribbon principle, so even with five tiles loading forward (as a save on disk lag in the current tile) you would only need a corridor three tiles wide by seven tiles long

    I'm not sure the tile loading is written so that this changes depending on the dynamics of where the consist is, so it probably is still loading those tiles even if they're essentially empty, hence the white space
     
  7. Jez

    Jez Well-Known Member

    Joined:
    May 8, 2019
    Messages:
    545
    Likes Received:
    643
    My workaround is to have a comfort break and/or make a brew at Standedge to avoid looking at the weird white dot. :)
     
  8. synthetic.angel

    synthetic.angel Well-Known Member

    Joined:
    Aug 27, 2019
    Messages:
    1,484
    Likes Received:
    2,265
    So... I think that there should be a hard-set limit for the tile which is effectively the streaming distance (depending on set-up). But there is also draw distance limit for the user, or the user's camera. If the user's camera is at the front of the consist, say, in the cab of the loco, then that is the distance that people experience.

    More generally.... what you do with draw distance and LOD depends on what the expected game mechanics and interactions are, how densely packed the scenery artefacts are on the tile, how complex the artefacts are in terms of polygon count, the resolution of the textures, how many NURBS are used (less polygons, but more processing for curve calculations), the amount of physics and lighting effects (including bounce back lighting with the latest UE...!), what the content of the surrounding tiles is likely to be...and.... the size of the tile(s)..... etc...

    Games use all sorts of tricks in layout design to hide the lag of stuff loading in the background, by using maze walls, etc., so by the time you get there, everything has loaded in. With TSW, the design decisions are much easier, because TSW seeks to replicate a real world location, so they just have to optimise for constraints.

    Rather than discuss at length....to give an idea of the variation of game styles deployed on UE, here is a link:
    https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games
     
  9. synthetic.angel

    synthetic.angel Well-Known Member

    Joined:
    Aug 27, 2019
    Messages:
    1,484
    Likes Received:
    2,265
    So, purely on the off-chance that the designer for Standedge Tunnel reads this, I thought I'd wrap up with some (minor) detailed observations on this Tunnel. Given the design, I think this tunnel was built starting from the NE (Marsden) end and finishing at the SW. But I walked it starting from the SW (Greenfield) end. I observed 12 sections, the first being approximately 120m long (let's call it S1), followed by eleven sections of 425m length (S2-S12, running SW to NE). The left side is therefore the "North" side.

    S2/S3 boundary - missing footing on the LHS at the S3 end (leaks a view to the netherworld)
    S5/S6 boundary - miscoloured footings on both sides at the S6 end
    S6 - reference point MP 16-1/4
    S6/S7 boundary - point where the view behind to the SW portal is lost and turns into netherworld (so, five tiles behind)
    S7 - ambient light changes and precedes the player's camera
    S8/S9 boundary - misplaced footing on the LHS at the S8 end
    S10 - reference point M60 signal
    S11 - approximately 360m in, the view of the NE tunnel portal changes from netherworld to the real view on the tile beyond S12

    So, for the interest of ARuscoe it would appear to me that:

    - five tiles behind are kept in memory (in this case)
    - the draw call for tiles ahead is made when you are about 80m away from the tile boundary ahead
    - the draw call gives you a view of 80m + 425m + 425m = 1030m (so I'd guess 1000m, in real world units), and a minimum view of about 80m + 425m = 505m (guess 500m, in real world units)

    I don't know if the tiles use a 1:1 scale, but (purely as a guess), I think it is probably 1.6:1 (because this is a handy conversion for imperial/metric). Pure guess though.... ;-)

    Anyway - it occurred to me that there is another solution to the original problem, as discussed in my OP. And that would be to put all of the tunnel tiles into landscaped tiles (I think they are in "empty" tiles at the moment, or at a very high Z...),and permanently set the daylight to night, for those inner tiles. This might give some cute tunnel like ambient effects - but it might not... just an idea...

    EDITED: To correct the mathematics.... and infer some tile settings... ;-)
     
    Last edited: Sep 18, 2019
  10. ARuscoe

    ARuscoe Well-Known Member

    Joined:
    Apr 9, 2018
    Messages:
    10,832
    Likes Received:
    10,482
    Except they don't and that's the problem.
    What people want is to be able to look at a photograph of any given location and have the textures, curves and gradients match real world
    I mean even myself who lives 100 yards from a station modelled in TSx has flown over to my gaff to see if it's modelled approximately (which it is)
    I don't know any other type of simulation where people will want it to look good at 100MPH going over junctions and then press a single button to look good at 0MPH and be able to change the angle and view intricate detail, and then another and be doing 100MPH again, all the while tracking your own physics and (even in part only) the physics of the other locos either within range or all across the route (in TSx all locos are in memory all the time unless they're portalled OUT, but they work on a reduced working level. Haven't thought to check in TSW and go look in the cab of an AI and see if the dials are working etc

    So whilst I agree that it SHOULD be a case of loading a few tiles surrounding the player consist it seems that the loading process is either too slow or trying to do detail within view which causes a lot of issues.

    Reminds me of the early internet days when GIFs loaded in swipes...
     
  11. ARuscoe

    ARuscoe Well-Known Member

    Joined:
    Apr 9, 2018
    Messages:
    10,832
    Likes Received:
    10,482
    Just to be a pessimist here... you know you're going to be seeing stars inside tunnels if this happens...
     

Share This Page