Extremely Slow Rendering of Roads and Tracks in TRS2022 Build 122411 on Large Routes

John, you're the second post I've seen about HD routes increasing to 2TB. That's huge!
It must be down to the number of baseboards I guess.
With those sort of sizes I wouldn't have the space to convert my route.
 
I have also found that this Build 122411 has broken the Script for the Disney Epcot Monorail Station no longer works for loading and unloading Passengers.
119450 the Scripts were working perfectly. Also no options in the ? to add Passengers to the Station.
 
I just upgraded my current large 10m Grid route (a WIP) to HD. It went from 180MB to 835MB - about a 5x increase. In the current retail Trainz Plus build 122411 there is no visible slow down in the rendering of road, track or any other splines in the HD version.

I have all performance settings at their maximum.

I have performed several trial Upgrades to HD on many smaller and a few larger routes, all with 10m grids which should show the largest size increase, and all have resulted in file size increases of around 5x. While not wanting to cast any "doubts" on claims made here, I am "puzzled" by some of the figures quoted.

A file size increase from 350MB to 2TB is roughly 5700x (1TB = 1,000,000MB). If it is correct then something very unusual must be going on.
A 5x increase from 350MB would result in a file of 1750MB - close(??) to 2GB.
 
Last edited:
I just upgraded my current large 10m Grid route (a WIP) to HD. It went from 180MB to 835MB - about a 5x increase. In the current retail Trainz Plus build 122411 there is no visible slow down in the rendering of road, track or any other splines in the HD version.

I have all performance settings at their maximum.

I have performed several trial Upgrades to HD on many smaller and a few larger routes, all with 10m grids which should show the largest size increase, and all have resulted in file size increases of around 5x. While not wanting to cast any "doubts" on claims made here, I am "puzzled" by some of the figures quoted.

A file size increase from 350MB to 2TB is roughly 5700x (1TB = 1,000,000MB). If it is correct then something very unusual must be going on.
A 5x increase from 350MB would result in a file of 1750MB - close(??) to 2GB.
As I mentioned in post #20, when I converted the massive UMR route to the HD format it ended up being 2.562 GB Which is 4.4 times as big as the 10m version available on the DLS. Something is dreadfully wrong if a 500 MB route ends up being 1.2 TB in size. I have converted about 20 routes now to the HD format and none of them has exceeded being over 5.6 in size over the 10m version.

Now if we could only save in the cdp format routes in the 2 to 3 GB's that would be a step in the right direction. HD is probably the future for Trainz so the size restrictions need to be addressed.
 
A file size increase from 350MB to 2TB is roughly 5700x (1TB = 1,000,000MB). If it is correct then something very unusual must be going on.
A 5x increase from 350MB would result in a file of 1750MB - close(??) to 2GB.
My thoughts exactly Peter. Something is wrong here. I am very reluctant to even try an upgrade to HD for fear of running out of disk space.

I would guess that most new build PCs don't come with more than 2TB of disk space unless upgraded.

We need some clarification here from N3V surely?

Regards,

John
 
In a previous update to Trainz Plus, a few months back prior to the release of HD terrain, the compression level used when .cdp files were saved was significantly increased. From memory the files became about 50% smaller (give or take). I do not know how much further this option could be taken, if at all.

I am impressed with the HD Terrain system, certainly with the screenshots that I have seen of HD Terrain examples and, combined with PBR ground textures, I believe that it will deliver the "greater realism" that has been demanded by so many users over the years. However, it does look like a lot more effort will be needed by route creators for HD to realise this potential.

The move from TRS12 to T:ANE required a significant upgrade in user technology from 32 to 64 bit. If you wanted to use T:ANE and later versions you had to have a 64 bit system. N3V recently announced that they are investigating introducing ray tracing technology into Trainz which, if it occurs (and this means more "greater realism"), then another significant technology upgrade will be needed. HD terrain, certainly on large routes, may require another technology upgrade for many users.

None of these upgrades are cheap. But if you are purchasing a new computer I very much doubt that you can still find a new 32 bit system on the market, Terabyte on-board storage devices (HDD or SSD) are now "standard" and more systems are now appearing with ray-tracing GPUs (my latest laptop came with an Nvidia RTX as its only option).

The use of HD Terrain is not compulsory, unlike the hardware change needed to move from TRS12 to T:ANE and, potentially, to a future ray-tracing Trainz version.

In the meanwhile, I intend to start developing HD routes but small ones only. Exactly how small will depend on the learning curve and the effort required.

My thoughts.
 
Last edited:
There is nothing wrong with the file sizes being increased, as HD Terrain has a lot more information and this space needed to support it. It isn’t required that you use S2.0 or HD Terrain.
 
If I remember correctly, compression increase concerned .tzarc files, not .cdp.
I don't use tzarc files but I did notice a significant reduction in the size of saved .cdp files after that particular update. There must be, I presume, a connection between tzarc and cdp.

HD Terrain has a lot more information and this space needed to support it. It isn’t required that you use S2.0 or HD Terrain.

HD terrain has about 1600x the data per 10m grid than the 10m resolution (according to a post some time back by Zec). Without the increase in the compression level the .cdp (or the .tzarc) files would have been even more impossible to manage.
 
Maybe it's time to move beyond the venerable .cdp file and stick with the .tzarc format. N3V would need to create an importer because importing a .tzarc now requires a DBR to add the asset(s) to the database. This same importer could be used for restoring backups as well.

The reason for going to .tzarc is that file format appears to support much larger files than the 2.0 GB limit of .cdp files. A quick look at the packages folder shows some asset packages as large as 5.1 GB. They would still need to maintain .cdp file support due to backwards compatibility on a read-only basis.
 
Back
Top