Merging Routes and Resulting load on PC

Driver_Col

Active member
I need some opinions please re the ramifications of merging Routes because I have successfully joined my Badger-Tanglefoot and Tristyn Routes so can have substantial GWR/Western Region operations as well as substantial LMS/Midland Region operations with a rather nice section of shared trackwork. In the future,I see no major problem to now add my Billinton Route to the Tristyn side (giving an SR/Southern Region link) as well as my (adapted) Rosworth Vale Route to the Badger-Tanglefoot side (giving an LNER/Eastern Region link).

Theoretically it sounds like my perfect layout as I can cover everything however, there is the computer to consider .. and this is where your thoughts would be appreciated. To complete just the initial merger of Tristyn and Badger-Tanglefoot and overhaul it for TRS19 was/is a lot of work. That is obviously multiplied by adding the other two Regions. i.e. to do everything will be a huge investment of time. The question is ... can it be handled by a reasonable PC?



My understanding (perhaps rather simplistic), is that a computer (when running Trainz) is working primarily to produce the onscreen imaging, with other resources processing anything else within the preset visual distance. i.e. If my pc is set to process up to 8000m, is it doing anything at all for assets outside that range? Putting that in more direct terms, if my pc can process comfortably my Routes on their current settings, is there any limitation as to how big the Route can grow?



I am pretty sure that I am missing some key knowledge .... which is where you "guys" come in! Thoughts? Regards to all. Colin.
 
I'm not sure you are, its not the size of the route that really governs how Trainz is displayed on the screen but the capability of the GPU, the viewing range and the amount of detail displayed within that viewing range determined by how you have set the sliders and the number of assets (particularly different assets) you have deployed within that visual area. Reasonable CPU, memory and hard drive/SSD performance all help but its the GPU that is doing the majority of the work displaying your animated creation on the screen.

By reducing the amount of detail being displayed and the speed of change will provide a smoother more satisfying viewing experience while increasing the levels of detail and animation will likely reduce that experience, unfortunately without a top end GPU its a compromise which the majority of us tend to face. What I have found is that as my creations have grown so has the time they take to initially load to edit or drive. Start jumping around any creation large or small and subject to the above criteria the graphics will take a time to settle.

Should you decide to merge routes together may I suggest that you insert a number of blank base boards between the route before merging to provide a working space to enables track, terrain etc. to be smoothly connected/contoured together. Peter
 
I'm not sure you are, its not the size of the route that really governs how Trainz is displayed on the screen but the capability of the GPU, the viewing range and the amount of detail displayed within that viewing range determined by how you have set the sliders and the number of assets (particularly different assets) you have deployed within that visual area. Reasonable CPU, memory and hard drive/SSD performance all help but its the GPU that is doing the majority of the work displaying your animated creation on the screen.

By reducing the amount of detail being displayed and the speed of change will provide a smoother more satisfying viewing experience while increasing the levels of detail and animation will likely reduce that experience, unfortunately without a top end GPU its a compromise which the majority of us tend to face. What I have found is that as my creations have grown so has the time they take to initially load to edit or drive. Start jumping around any creation large or small and subject to the above criteria the graphics will take a time to settle.

Should you decide to merge routes together may I suggest that you insert a number of blank base boards between the route before merging to provide a working space to enables track, terrain etc. to be smoothly connected/contoured together. Peter
Thanks for your response Peter. At the risk of simply paraphrasing what you wrote ... are you saying that the size of the Route can be pretty much infinite as long as all the settings are relative to the PC, and the only time it may be an issue is if you start hopping around the route (say, jumping from one train to another)? Regards. Colin.
 
Thanks for your response Peter. At the risk of simply paraphrasing what you wrote ... are you saying that the size of the Route can be pretty much infinite as long as all the settings are relative to the PC, and the only time it may be an issue is if you start hopping around the route (say, jumping from one train to another)? Regards. Colin.


I seem to recall there is an upper limit to the number of baseboards but it is fairly high and I doubt you'll run into it.

Cheerio John
 
The N3V answer was it depends on your Hardware, there is no actual limit. And as now routes / boards are streamed, there isn't the same overhead as there was when loading all the baseboards at once, there is no longer a large mapfile.gnd file to load just a heck of a lot of small files that equate to it.

I have a DEM of the whole of North Wales and it loaded that OK, no scenery or anything, just the map overlay, just to see if at the time Transdem and TANE could handle it. Obviously one would not be using all of it for a route or routes so what you can't see from track gets removed.
 
There are also non-N3V commands and rules and probably other assets that were written back when there were not thousands of baseboards, junctions, etc. They are beginning to show failure for various reasons, including time-outs. Build empires at your own peril :cool:.
 
The N3V answer was it depends on your Hardware, there is no actual limit. And as now routes / boards are streamed, there isn't the same overhead as there was when loading all the baseboards at once, there is no longer a large mapfile.gnd file to load just a heck of a lot of small files that equate to it.

I have a DEM of the whole of North Wales and it loaded that OK, no scenery or anything, just the map overlay, just to see if at the time Transdem and TANE could handle it. Obviously one would not be using all of it for a route or routes so what you can't see from track gets removed.
Thanks Malc. Your input in these matters is always appreciated. Regards. Colin.
 
There are also non-N3V commands and rules and probably other assets that were written back when there were not thousands of baseboards, junctions, etc. They are beginning to show failure for various reasons, including time-outs. Build empires at your own peril :cool:.
Thx for your thoughts, but I was not anticipating an empire per se ... just joining four of my Routes together and not only being able to enjoy them, but making them feasible for other Trainzers to use them if they so wish. All my questioning is simply to answer my question to myself ... "This is a huge time commitment. Is it worth it?" I haven't got that answer yet. Regards. Colin.
 
You could always leave the separate routes un-merged, and run via iPortals from one large route, to another separate large route

Sometimes when the merged GND file is too large, the route will no longer save as a CDP, or is too large to upload to the DLS
 
Last edited:
You could always leave the separate routes un-merged, and run via iPortals from one large route, to another separate large route

Sometimes when the merged GND file is too large, the route will no longer save as a CDP, or is too large to upload to the DLS
If I merged all four Routes, the end result would be in the 125 to 150MB range. Merging them into one provides opportunities for interactions between SR & GWR, GWR and LMS, and LMS and LNER. I really don't see the Portal idea really filling that objective.b Regards. Colin.
 
That does not seem so big, or so bad, when it gets like 750mb to 1gb things can get iffy

I was was speaking of iPortals, not Portals, as iPortals can spawn trains in a secondly opened route
 
Last edited:
Thanks guys. It sounds like it is a doable project, and as I already have Badger Tanglefoot and Tristyn District merged, I'll probably complete that combination first. Regards. Colin.
 
From experience, if you keep your route size well under 2GB you'll be fine. Anything over that is quite sketchy and will crash everything to the desktop. I found this out the hard way recently while importing some data from TransDEM. The TransDEM route, roughly edited but not fully trimmed down, was about 2GB and TRS19 dropped immediately to the desktop. This route was quite huge and I don't know what I was thinking at the time. In the end I ended up deleting a good hunk and kept the other for a nice route I've just started.
 
From experience, if you keep your route size well under 2GB you'll be fine. Anything over that is quite sketchy and will crash everything to the desktop. I found this out the hard way recently while importing some data from TransDEM. The TransDEM route, roughly edited but not fully trimmed down, was about 2GB and TRS19 dropped immediately to the desktop. This route was quite huge and I don't know what I was thinking at the time. In the end I ended up deleting a good hunk and kept the other for a nice route I've just started.
Thank you John for sharing that. It's reassuring to know that I will be well under that size! Regards. Colin.
 
Back
Top