HD Terrain - practical number of baseboards

[fjbicrf]

Greetings,

Has anyone figured out what the practical number of baseboards is for an HD route?

What about for 5m........ I read somewhere in the forum where a user had a route that was over 10,000 baseboards at 5m resolution that they said ran like a dream.

Please let me know.

Fred Bray

 

[JCitron]

I don't think there is a practical limit because that limit is based on the capabilities of your computer. A superpowered rig will be able to load huge routes done in 5m or HD terrain without too much of a hiccup while less powerful machines will struggle. This has always been the case with Trainz.

 

[fjbicrf]

John,

Thanks for the info. I am planning a large route and at 5m, it would be done in one entire route. At HD resolution, I would probably split it into two routes and use iPortals to connect them.

Fred Bray

 

[FootplatePhil]

Note that their is a size limit on CDP files. When I convert my large route to HD I can no longer export it to CDP. The route is about 500kms in length. I've not counted the number of boards, but it would be in the hundreds.

 

[JCitron]

Note that their is a size limit on CDP files. When I convert my large route to HD I can no longer export it to CDP. The route is about 500kms in length. I've not counted the number of boards, but it would be in the hundreds.

But there's more than just baseboards that make a large route. There is the mapfile.gnd which is by far the largest of the files in addition to all the others that contain information pertaining to the route. The difference today is the mapfile.gnd is still the largest but the other files have been broken into chunks of a few hundred KB at the most. When it all adds up, it can be quite large. For my large personal route, with about 320 km of mainline if driven end-to-end, it weighs in at 376 MB. The mapfile.gnd is around 1 MB with all the others adding up to the rest. This route is made up of a combination of 5 m and 10 m grid bits and pieces and has been built over the past 19 years or so.

The practical limit though is I agree, something to consider. The maximum size a CDP file can be is 2 GB to be readable directly into Content Manager. Using a third-party utility CDP Explorer by PEV, larger files can be read and the contents extracted for install, but without that there are errors when attempting to do so without it.

The other thing to consider with a larger route, taking this from my experience, is AI driver and interactive industry setup. With a large route, this task becomes no longer fun by the time the end is reached because of the work needed to work this out when setting up routes, and configuring queues for industries.

This process doesn't count troubleshooting the session afterwards and dealing with the other AI issues. I've noticed that with huge routes, the AI gets dumber and dumber as time goes on during the operation. This is probably due to all of what needs to be tracked all over the very large route.

With that said, I've been splitting up my large routes into smaller chunks and using i-Portals to join them together. The session setup is far easier with the smaller route and the AI don't become stupid sooner, or at least I haven't noticed yet.

 

[JCitron]

John,

Thanks for the info. I am planning a large route and at 5m, it would be done in one entire route. At HD resolution, I would probably split it into two routes and use iPortals to connect them.

Fred Bray

You may want to split the route apart anyway for operational reasons. See my post above.

 

[fjbicrf]

You may want to split the route apart anyway for operational reasons. See my post above.

John,

Yep, that's a great idea. I've noticed that too about AI.

Fred Bray

 

[capdiamont]

But there's more than just baseboards that make a large route. There is the mapfile.gnd which is by far the largest of the files in addition to all the others that contain information pertaining to the route. The difference today is the mapfile.gnd is still the largest but the other files have been broken into chunks of a few hundred KB at the most. When it all adds up, it can be quite large. For my large personal route, with about 320 km of mainline if driven end-to-end, it weighs in at 376 MB. The mapfile.gnd is around 1 MB with all the others adding up to the rest. This route is made up of a combination of 5 m and 10 m grid bits and pieces and has been built over the past 19 years or so.

If I may, mapfile.gnd used to be one file for the route, however later versions of Trainz broke up this file in to baseboard chunks. The default single baseboard when making a new route would generate mapfile_0_0.gnd for 5/10m grid. This is made up of height values using floating point format, but only using three bytes in most cases. HD Terrain changes the format a lot, due to needing compression, also adding texture references, and adds two additional mapfiles per baseboard. I think the mayflies were broken per baseboard to allow easier memory management when loading baseboards in and out of memory. TransDEM generates the single mapfile.gnd type routes.

 

[JCitron]

If I may, mapfile.gnd used to be one file for the route, however later versions of Trainz broke up this file in to baseboard chunks. The default single baseboard when making a new route would generate mapfile_0_0.gnd for 5/10m grid. This is made up of height values using floating point format, but only using three bytes in most cases. HD Terrain changes the format a lot, due to needing compression, also adding texture references, and adds two additional mapfiles per baseboard. I think the mayflies were broken per baseboard to allow easier memory management when loading baseboards in and out of memory. TransDEM generates the single mapfile.gnd type routes.

That's an interesting observation. The multiple map files I think are the slices used by the program instead of the huge single mapfile. TransDEM is still using the old format because N3V won't give Dr. Ziegler updated file information. With the multiple slices, this is even more of a reason to upgrade to SSDs if possible.