Elvas Tower: Cabin day / night view in tunnel - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Cabin day / night view in tunnel Rate Topic: -----

#11 User is offline   QJ-6811 

  • Conductor
  • Group: Status: Active Member
  • Posts: 385
  • Joined: 27-December 15
  • Gender:Male
  • Simulator:MSTS / Open Rails
  • Country:

Posted 07 May 2019 - 06:32 AM

Hello Jan,

A lot checked. First tried a 100% new route, just 4x 50mstrt + 2x 100mRndTun + 2x 150mstrt.
In summary, you get night view in the tunnel sections (also above ground) or if you are underground, even with 'no tunnel sections'. OK, no news, but there can be two "trigger points". (terrain and tunnel section)
I tried to get it wrong, but the night view remained good and in <xx> .TDB the ID remained at '234'. (RndTun 100m). OK.

Return to the route. In summary: the tunnels 3, 7 and 8 with the problems as well as the others have the IDs as examples 22073 (A2t100mstrtRndTun), 22083 (A2t500r10dRndTun), etc. These IDs are also in the <xx> .TDB and these iDs are in the tsection.dat with attribute "tunnel". So far (if I have not misunderstood) all this is correct.
The tunnel sections have been modified via TSRE and 'EDIT', referred to the same shape-file name in another diretory. (due to modified .ACE). but this is no different than in the example of the Val_de_travers single track tunnels.

Because you gave this example, I remembered that one of the 8 tunnels between "Bole and Noiraique" also sometimes stayed in day view.
A test drive from Bole to Noiraique and back, all 8 tunnels OK. A test drive from Noiraique to Bole and back, now only 'forward' the second tunnel at Bole fault .... :unknw: (so again dependent on starting direction ... ?!?). As per your example, all tunnel sections are here in <xx> .TDB at "120", so with a flag "tunnel" in tsection.dat. In fact, I think this should be good.
(a bit surprised that all tunnel sections have ID 120, regardless of the track section type. Anyway, it's a "tunnel" and not a regular track)

Thanks for all the help and information, I learned a lot from it. :D And it could indeed have been the problem as you indicate.

What is 'in my head' now is that again today it turned out that the start direction determines whether it goes right or wrong. (?). If indeed (just like with the sound regions) the trigger point of the train is in a different place, then maybe "terrain" and "tunnel section" trigger point may be the problem, perhaps too close together or something ... OK, if I have time again, try further .. (first rest and beer .... :) )

Regards / Roger

#12 User is offline   Kapitaen13 

  • Hostler
  • Group: Status: Active Member
  • Posts: 80
  • Joined: 05-April 19
  • Gender:Male
  • Simulator:MSTS
  • Country:

Posted 07 May 2019 - 07:43 AM

Hello Roger, well cheers. :cheers3:

After I read your whole story in your Zip archive yesterday I remembered something else.
During the task tests for the Val de Travers the Cab changes in the TGV were very negative. Sometimes they work, sometimes not. Once when changing from night to day the whole cab disappeared - as well as at "Shift-1".
This made me take a closer look at the Cabview of the TGV. I noticed that all textures were 4096x4096 pixels and with every change all three textures have to be exchanged. Since we were still building for the MSTS and not for the OpenRails, I reduced these .ace's to 1024x1024 pixels, because I thought the whole thing was a performance problem.
This fixed the problem, which is very similar to yours. But I can't say anything negative about the performance in OpenRails yet.
I'm sure you'll find the solution.

Greetings, Jan

Translated with www.DeepL.com/Translator

#13 User is offline   QJ-6811 

  • Conductor
  • Group: Status: Active Member
  • Posts: 385
  • Joined: 27-December 15
  • Gender:Male
  • Simulator:MSTS / Open Rails
  • Country:

Posted 09 May 2019 - 07:07 AM

Update ... :) Yesterday and today a lot of testing, but most notable was the test with test runs from different starting positions, partly through [START] or [RESUME]. As an appendix an Excel sheet, I think it indicates enough how “spooky” the result is… .. :ko2: Yes, of course I know that if I start from [START] (from zero) this can be different than via [RESUME], especially if you have changed something in the meantime. But with these tests 100% certainly nothing has been changed, not via TSRE or copying, etc. Most notably the fact that at one starting point now suddenly tunnel 5 + 6 gives problems, which for the rest is always good …….

OK, With this it is "proven" that the World-file itself is not the problem, but after some puzzling it became clear that the complaints are still influenced by the World-file boundary lines. (such as difference of starting point before or in the world file of the tunnel in question, etc.).

OK, after all this, the xx.tdb adjusted for the first time, with the idea of giving a tunnel "no tunnel feature". Did not have any influence, but once again it became clear that OR also still does not respond to terrain height ... (IOW, it is not a "double trigger problem").

As is sometimes said, the surprise is in the end ... Once an attempt to set the "distance view" to 3Km, suddenly everything okay? OK, rebuilt to 5km, 7km, etc. It appears that up to 8Km goes well, 8.5Km or higher gives the above errors…. (hummmm).

Then the first reaction will be, >8.5km gives too high PC loading, memory usage, etc. Unfortunately, even at 10KM the 60FPS remains (after all terrain is almost empty), CPU something like 24% and 2.9Mb maximum memory. I now noticed through HUD (see example image) that when a world-file boundary is crossed a "burst" almost always occurs. So what triggers the "Tunnel night view" error ???

As an appendix also an OR dump of "8000 meters" and "8500 meters" distance view, but in my opinion no significant differences or limits. Except often the 100% in the "loading sounds" (I suppose the World-file borderlines) but this also happens with lower distance values.

Well, my ideas have run out ... I hope someone has a good idea or maybe sees a clue in the OR dump, or how you can better trace this? Or is this really a bug in OR?

Still a break again. The DMU can now go back to the workshop for maintenance. (me too… :) )






#14 User is offline   QJ-6811 

  • Conductor
  • Group: Status: Active Member
  • Posts: 385
  • Joined: 27-December 15
  • Gender:Male
  • Simulator:MSTS / Open Rails
  • Country:

Posted 14 May 2019 - 03:12 AM

Started this topic and ended it .... My ideas are gone and I don't see any other sugestions anymore.
With some final tests last Sunday the World-Files tested, or rather the World-file areas.

In summary, the problem "no CAB night view in tunnels" arises in my case with a distance view> 8000 meters. OR no longer responds to a tunnel section or the intersection of the terrain. You will also notice this with Camera-view 2 and 3, as in the examples below. IOW, if you are in front of your train with camera-view 2 during the ride, you go through the mountain and do not "jump" back to your cabin view as usual.
Tested the entire 30Km route, went from "above ground" to "underground" every time and tested all World areas.
Conclusion: various World areas are OK, various not. (almost "alternately" right and wrong). So if a 'bad' world area has a tunnel, you will notice that you will not get a night view. (all other things such as objects, etc. are fortunately going well!).
Furthermore, I think it is not an error in the World file or Tiles file, because the situation of a "right or wrong" World area can change depending on your starting point on the route.

OK, so my preliminary "final conclusion" is that loading in OR the numbers (too many ...?) of world files or Tiles files causes this phenomenon, although I don't see any indication. Perhaps by priority that these 'tunnel triggers' are cut if the data becomes too much? Still noticed that the "CAB Night view" problems are over with a distance view <8000 meters and the Camera-2 and 3 react 'normal' again with a slightly lower distance view.

However, one point remains the most incomprehensible to me. If you use a 10 km distance view as an example and you are driving ahead, you will get this phenomenon. OK, but why if you drive "backwards" from startpoint, the same entire 30km route and therefore also all World files and Tiles files need to be loaded, everything will go well ???? :unknw:


OK, positive point is that as far as I can now summarize everything, it is not "corrupt data" of the route and that after a week of searching I can continue to build the route! :) If it is a loading process (timing process) reasons in OR (or PC?) with amount of data, I hope it will be resolved in the future with an SSD. (?)

Example Camera view 2 for the train
Attached Image: brug-voor_tunnel-7.jpg
Attached Image: Tunnel-7 inside cam-2.jpg

Example Camera view 2 "from above ground to underground"
Attached Image: Tunnel-8 outside.jpg
Attached Image: Tunnel-8 underground.jpg



@Jan, or other "Val_de_Travers" drivers. The second tunnel from Bole appears to have been buried by objects, not by the terrain. Distance view had no effect here, but OR also does not respond to the tunnel sections? After creating a tunnel in a tunnel (...… :D ), so buried under the objects (rock walls), everything seems to work well, even with a 10Km view!

#15 User is offline   Kapitaen13 

  • Hostler
  • Group: Status: Active Member
  • Posts: 80
  • Joined: 05-April 19
  • Gender:Male
  • Simulator:MSTS
  • Country:

Posted 15 May 2019 - 06:48 AM

My Val de Travers has highly textured distance mountains.
I don't know why I should increase the visibility above 2000m.

Greetings, Jan

https://up.picr.de/35760913fx.jpg

#16 User is offline   QJ-6811 

  • Conductor
  • Group: Status: Active Member
  • Posts: 385
  • Joined: 27-December 15
  • Gender:Male
  • Simulator:MSTS / Open Rails
  • Country:

Posted 15 May 2019 - 09:23 AM

View PostKapitaen13, on 15 May 2019 - 06:48 AM, said:

My Val de Travers has highly textured distance mountains.
I don't know why I should increase the visibility above 2000m.

Greetings, Jan



just to create a wonderful world en use what OR can bring. :cheers3:

Attached Image: Open Rails 2018-08-24 09-40-15.jpg
Attached Image: Open Rails 2018-08-25 09-48-11.jpg
Attached Image: Open Rails 2018-08-25 10-05-08.jpg
Attached Image: Open Rails 2018-12-19 06-35-31.jpg
Attached Image: Open Rails 2018-12-19 10-08-47.jpg


By the way, I see that your distance mountains are slightly different? Has there been an update?

Regards, Roger

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users