Reducing or increasing track sections per tile

[AdamsRadial]

Does anyone know if there is an advantage to keeping the number of track sections to a minimum? For example, instead of having 10 x 100m straights in a line, having 5 x 200m straights?

I had been assuming that there must be a processor or file system load the more sections there are, but having reduced the number of track sections in a sample tile I can't say I can see any difference. I also found that when sloping track to match the DEM'ed landscape, long sections were harder to get the ground to conform to the track, so I've reverted to a backup with all the short pieces rather than make some scenic embankment sections.

Interested to hear if anybody has carried out some more objective experiments than I have in this area.

[jbilton]

Hi
I've never done much track laying, however there is a performance hit when you approach a busy junction in the game.
Now whether this is due to the number of pieces or maybe points, I'm not sure.
I would agree logically a single shape should load quicker.
Having said that a row of identical shapes would also load relatively quickly.
Cheers
Jon

[3DTrains]

Not much of a hit from models or textures, but more from the number of paths the sim needs to calculate, which is why complex yards (lots of turnouts) with few tracks are more intensive than simple yards with more track (but fewer turnouts).

[jbilton]

Hi
Something I thought of earlier, but forgot to post, is that UK finescale track shapes seem to hit the game harder than default track.
Possibly because they are more complicated shapes.
A man to ask would be Kerr of Making Tracks.
The section around Stratford on MTs GE originally was very sticky, but he managed to make it run smoothly.
Cheers
Jon

[AdamsRadial]

Jon, I hadn't thought about the possibility of MSTS caching successive identical shapes, it might reduce the file processing time. However, even the processing to determine if the next shape is the same as the one already read, and if so, to use the cached version, is all extra work that might increase the game loading.

I am using UKfinescale, and as an extreme example of what I am asking about, I wonder what would a stretch of track be like if it were laid with 200 1m straight sections, instead of 1 200m straight?

As far as I can see, the only valid reasons for having shorter sections of track are when the gradient is being gently varied at the start or end of a transition, or when a long piece of track crossed a tile boundary and is causing an end-no-end problem.

[jbilton]

Hi
It certainly wouldn't help with the total object count on a tile.
The two stickiest areas I know of are Crewe on TM (Default track)and Southampton on DC (UK Finescale).
I believe Dave Corfield has looked at these on numerous occassions, but never really found the problem.
The route that never ran for me was C2N , version 5, and around Sydney.
Cheers
Jon

[terrycunliffe]

The fewer the track sections, the fewer the objects that the sim needs to load. Also results in a much smaller .w file.

I am convinced that MSTS instability is caused by a combination of tile objects and the corresponding.w file size.

Just be wary about using long track sections that cut across 2 (or more) tile boundaries

[BrianB]

.............I am convinced that MSTS instability is caused by a combination of tile objects and the corresponding.w file size..............

I'd fully agree with that!!!

With reference to Jon's comment above, about problems 'running around the Sydney area' - unfortunately the trackwork around the Sydney/Darling Harbour/Redfern/Eveleigh area is very complicated in real life, and as a result pushes MSTS to its limits. Peter found that there were not enough varieties of X-Tracks points combinations to suit the Sydney area layout, and so had to resort to LOTS (and I do mean LOTS) of Dynamic track sections to fill in all the gaps.

The main problem here - if you look at a typical .w file, most track entries are only a couple of lines long in the 'code', but look at a Dynamic Track entry, and they are HUGE - typically three times the size of a 'standard' track entry. So, when you have tiles with complicated trackwork using lots of Dynamic track, they all add up very fast!!!

When Peter passed CTN over to me to do the scenery around the Sydney area, I found that the four 'key' tiles in the area had already about 70-85% of the file size capacity taken up with track and interactive entries, which left little for scenery. I found that as I started to detail the scenery, the tiles kept 'crashing' repeatedly - over a period of about a week detailing these areas, I had in excess of 100 tile crashes. Each time I had to resort to backups to reinstate the work, but it was all a lot of hit-and-miss with the scenery. I just kept at it until I got an acceptable balance of appearance versus performance. I can tell you I was VERY frustrated by the end of the week.

At first I thought it was simply the total number of objects (over 1000 on each tile), but what I did find was a physical limit on how big a tile could be in file size - around 750kb - I noticed that all the tiles that kept crashing were over 750kb in size, so I did some pruning and kept them to a maximum of about 740kb. Originally I had created heaps of individual custom buildings for most of the Sydney area, and once I found the tile size limit, I went back into TSM and started to combine many scenery objects - typically I could take say 4-5 separate models and combine them into a single object (also taking into account the maximum number of polys in the combined model), this helped to cut the size of the .w file down as there was now only one entry instead of 4 or 5 entries, as well as reducing the object count slightly. This increased the stability a bit, but use of the 'standard' MSTS soon found that having several tiles over 1000 objects and at around 740kb all loading together 'over-whelmed' MSTS and caused it to crash, due to MSTS inherent memory limitations, especially when running highly detailed stock.

By experience, Peter and I found that the only way to get 'reliable' running around the Sydney area was to use MSTS Bin with its better memory handling, along with ensuring that Consists used in this area used lower poly stock rather than highly detailed stock which consumed more memory.

So, yes, it is a combination of total tile objects, but more importantly tile file size.

Hope this gives a bit more insight to why intensive routes can have running problems

Regards, Brian Bere-Streeter

[AdamsRadial]

Thanks for the comments, everyone, they have confirmed what my instincts told me. I was particularly interested in BrianB's remarks about dynamic tracks with Xtracks, and I ought to have a look and see if UKFinescale does the same thing, since I have used Dynatrax in a few places where I hadn't got the time or patience to get the right sections to close up a loop.

[terrycunliffe]

Certainly the BIN patch allows you to still safely add objects where a vanilla msts install would 'bust' the tile.
However using the 'jump' technique to an unpopulated tile prior to saving will extend a tiles 'stability' quite substantially, even on a standard install.

I concur with Brians comments re Dynamic track.
Complicated trackwork can be difficult to get right, so I tend to use lots of dynamic track 'straight' sections. Once I've got the trackwork I want, I then go back and replace all the Dynamic with X track pieces. Even if it takes two or three different sections to replace one dynamic piece, the resultant file size is still smaller.

[ARG706]

Certainly the BIN patch allows you to still safely add objects where a vanilla msts install would 'bust' the tile.
However using the 'jump' technique to an unpopulated tile prior to saving will extend a tiles 'stability' quite substantially, even on a standard install.

I would not be pushing a tile beyond its inbuilt limits. You will find some objects will begin to not load whether you are in the sim or the RE. I would prefer if a message came up telling me the tile is at its limits rather than happily saving then finding out the hard way later on

[longbow]

If I recall correctly, a Dynatrax w.file entry is the same size as a single track piece. It's thus more efficient size wise than the Dynamic track section it replaces, and more efficent too than using multiple standard track sections to get the same shape. In my experience using Dynatrax you can reduce the track section count in a large station tile by perhaps 20%.

[GSX1400]

Here's a dynatrak entry. . .

Dyntrack (
UiD ( 1261 )
TrackSections (
TrackSection (
SectionCurve ( 0 ) 40812 33.84 0
)
TrackSection (
SectionCurve ( 1 ) 40814 -0.35 1010.32
)
TrackSection (
SectionCurve ( 0 ) 4294967295 0 0
)
TrackSection (
SectionCurve ( 1 ) 4294967295 0 0
)
TrackSection (
SectionCurve ( 0 ) 4294967295 0 0
)
)
SectionIdx ( 40274 )
Elevation ( 0 )
CollideFlags ( 551 )
StaticFlags ( 00100000 )
Position ( -961.567 36.405 -6.73716 )
QDirection ( 0 -0.465933 0 0.88482 )
VDbId ( 4294967294 )
StaticDetailLevel ( 0 )
)
and here's a Dyntrax converted entry (for a different piece as I haven't converted the one above yet)

TrackObj (
UiD ( 30 )
SectionIdx ( 40208 )
Elevation ( 0 )
CollideFlags ( 527 )
FileName ( "..\\..\\routes\\Devizes\\shapes\\DynaTrax-40208.s" )
StaticFlags ( 00200180 )
Position ( -559.135 36.405 429.2 )
QDirection ( 0 -0.223687 0 0.974661 )
VDbId ( 4294967294 )
)

Hope this is of use