Would this work? (to minimize frame-rate hiccups)

We have probably all seen this effect - frame rates are good in low-poly areas, then as the train approaches a densely decorated town, you get stuttering or even a momentary lock-up, possibly followed by some slower or jerky performance in the town itself.

I'm thinking that the initial stuttering is caused by the flood of new objects being loaded from the hard drive. After that, once you're in the town area, the frame rate would be more related to how well the graphics card can render the number of polygons.

Would it prevent the initial "hiccups" if all the scenery objects used in the town were introduced more gradually as the train approaches the town? The idea is to scatter examples of every house over an area about 500-1500m from the edge of town. By the time the town itself is visible, all the objects in it should be already loaded and available in memory. Would that reduce the stutter, or is my theory completely off?
 
I believe the 'hiccups' are more caused by strain on the GPU, trying to draw all the different polygons, and redrawing them as you travel through the 'space.' As a general rule, simulations such as Trainz and flight simulators really tax your system because of this. The only real solution I know of is to upgrade your video, but that runs into the wallet pretty hard. Thus you must strike a chord between performance and visual quality. Consider using lower-poly models. Might some splines be any better than individual buildings? I usually create rural areas so I wouldn't know about that specifically. To answer your question, your theory may work. One thing you could do is defrag your HD regularly, so the files you access most frequently are easiest for your HD to access.

Tim
 
We have probably all seen this effect - frame rates are good in low-poly areas, then as the train approaches a densely decorated town, you get stuttering or even a momentary lock-up, possibly followed by some slower or jerky performance in the town itself.

I'm thinking that the initial stuttering is caused by the flood of new objects being loaded from the hard drive. After that, once you're in the town area, the frame rate would be more related to how well the graphics card can render the number of polygons.

Would it prevent the initial "hiccups" if all the scenery objects used in the town were introduced more gradually as the train approaches the town? The idea is to scatter examples of every house over an area about 500-1500m from the edge of town. By the time the town itself is visible, all the objects in it should be already loaded and available in memory. Would that reduce the stutter, or is my theory completely off?

I thought of this a long time ago,

Being far from an expert on how to make it happen
i chose to upgrade to 2Gb of RAM instead.

It sure sounds feasible to me.

Torana. :)
 
This theory does work up to the point where you've maxed out your memory. When you start swapping with the hard drive it ceases to be useful. It also won't benefit you if you switch from train to train. You have to steadily progress from one end to another until all the items are loaded in memory. I have even sunk buildings below the surface in rural areas to ease the transition to the city. I'm not sure if THAT works though, seeing as the building is not actually displayed.

Ed
 
We have probably all seen this effect - frame rates are good in low-poly areas, then as the train approaches a densely decorated town, you get stuttering or even a momentary lock-up, possibly followed by some slower or jerky performance in the town itself.

I'm thinking that the initial stuttering is caused by the flood of new objects being loaded from the hard drive. After that, once you're in the town area, the frame rate would be more related to how well the graphics card can render the number of polygons.

Would it prevent the initial "hiccups" if all the scenery objects used in the town were introduced more gradually as the train approaches the town? The idea is to scatter examples of every house over an area about 500-1500m from the edge of town. By the time the town itself is visible, all the objects in it should be already loaded and available in memory. Would that reduce the stutter, or is my theory completely off?

You have two problems the first is to get the item from the hard drive into Trainz the second to get the textures into the graphic card. Adding memory so Trainz can keep things in memory helps both on the graphics card and on the cpu. Trainz normally isn't bottlenecked on the hard drive but introducing things early helps avoid a sudden rush.

Cheerio John
 
I've had this problem myself in designing my layouts and I worked out a few simple rules, by experimenting and also by looking at others' maps that worked smoothly. Perhaps the best example is the "Wadalbavale to Karrah Bay" map in TRS2004.

The rules are these:

1. If it's not visible from the in-cab cameras, it doesn't exist.
2. Every new different object I place costs ten bucks from my wallet.
3. Every new instance of an existing object I place costs a dollar.

What this means is that you only place objects that are visible from the in-cab cameras on a loco when you drive past, and you use as few different object models as possible. I know from experience that the temptation is to build a complete town with houses, roads, streetlamps, stoplights, trees, bushes, fences and the whole box and dice, for miles from the tracks. DON'T DO THIS.

First and most important, don't go overboard using loads of different buildings. I generally restrict myself to no more than three or four different house models ($30-$40), two to three different shop models ($20 - $30), and two or three factory models ($20-$30), and repeat them over the whole town. The fewer different objects you have, the less there is to load into memory. So a town with 150 houses all the same model will display much faster than a town with just 50 houses using 10 different house models. Do the same with trees - every house has the same tree type. Using this "cost model" will make you aware of how many different objects you're using, and make you minimise them effectively.

So, to design your town, place all your detailed stuff next to the tracks first. That includes your shops, factories, houses, along with road splines, yard fences, streetlights, garden flowers and trees etc - ONLY ALONG THE TRACKS, nowhere else. Now, zoom in as close as possible and follow the track with the right mouse button held down, as if you were driving a train. Look for gaps between your trackside buildings through which other more distant buildings would be visible, and note these gaps. Here, you can place extra buildings (of the same type you've placed next to the track to reduce memory usage) to fill in. Finally, any distant hillsides visible from the cab that have houses on them, have only low-poly houses used, no road splines or other detail at all. Use the grey "asphalt" textures creatively with a small brush to create the illusion of roads etc.

The art of map design - in any game, not just Trainz - is to create the illusion of there being more than there actually is. Poly counts matter, so if you can get away with using a surface texture or a flat one-poly "billboard" object, do so. Keep solid high-detail objects for trackside only, and use only low-poly ones for further away. (In your cost model, flat "billboard" type objects are 25% of full price for a new object, so a new flat low-poly model only costs $2.50 to add, and 25c for each one you place.) Also, instead of covering a distant hillside with trees, use the "forest" textures on the landscape to create the illusion of trees. (This has the added advantage of making your distant hills seem bigger and more distant than they really are too! Turn up the fog a notch or two as well to enhance this illusion.)

Remember also that you see a LOT more in Surveyor than you do in Driver - in Driver, you're concentrating on driving the train, not floating about the map checking out the scenery. So be mean - really mean - with your object placement. Think about what a driver will see from a train, not what it looks like in Surveyor. Run-test your map LOTS during development - the "Quick Drive" (Ctrl-F2) feature was placed in Surveyor for a reason. It does take practice, time, patience and skill - but remember, it's all about "smoke and mirrors". If you follow these basic principles of minimalisation, it pays dividends when you come to play the game! ;)
 
Well thanks everybody. I got a bit more than I bargained for with this one!

Mystikan, thanks for the time spent with your reply, everything you mentioned certainly applies in general. I guess my question was one I might ask after I've followed all those guidelines and I'm working with the hardware I have.

So let's assume I've done what I can in that regard, but I'm still wanting to improve the hiccup as my train approaches a more densely decorated area in the layout.

The fact that "150 houses all the same model will display much faster than a town with just 50 houses using 10 different models" seems to be a well-accepted concept. It actually supports the notion that reading from the hard drive can be the bottleneck. After all, once all the houses are loaded, the number of polygons will be roughly the same, whether the houses are from one or many different assets.

And what Euphod said about the memory limit, I'm sure is true. If a layout is so dense that it forces file swapping, then performance will be bad even after all the objects have been loaded. I don't think I'm anywhere near that limit with the layout I'm making (once I'm in the town area, I'm still getting frame rates of over 40/second). It's just the initial hiccup that bothers me.

It seems to me that this is worth a try, but what's missing is a controlled test to see if the idea has legs. I'll grab FRAPS and do some experiments...
:wave:
 
While you're experimenting, try adding all or some of these lines to your trainzoptions.txt file. I have found that this combination smoothes out loading of resources on my system. It may drop overall frame rate but I have less jerks around hi poly areas.

-ResourceMemory=1024<--half of your total of RAM memory, I have 2 gigs
-keepallresources=1
-framestoaverage=8
-arealimit=400 <--\
-sectionlimit=12<--These two seem tied together. Increase or decrease both.

Good luck.

William
 
If you do want to spread out the loading of objects, it's possible to put them underground if having them load overground, but early would be intrusive in the route.
 
tommy/wreeder

I should be in a position to do some testing in the next day or so. I was planning on burying the assets, but wasn't sure if that was valid - it seems that it is, so that's a step forward. Thanks, I will factor in all your suggestions.

keepallresources=1 will be interesting setting to try because my layout is huge at 1256 boards and I'm using Trainz Tuner to give me a 3.5 - 4.0km lookout radius. I hope my cache can handle it!

As a side note, on the default setting (keepallresources=0) I've been getting 40-45fps most of the time. Being a desert, most of the landscape is devoid of objects and I have been relying solely on groundtextures for visual impact. It's often said that using lots of groundtextures and rotating them gives a serious hit to frame rates. I don't see that at all, even in this extreme case of a large map and large lookout distance. It's objects and polygons that ruin frame rates IMHO.
 
First results

Trainz Tuner settings

Max ground draw distance = 4100 metres
Max scenery draw distance = 2500 metres

Trainzoptions settings

resourcememory = 1600 MB (from 2GB RAM)
keepallresources = 0 (ie. not included in the setttings)
zfar = 4150 metres

Test setup

Baseline test

A train starts in open country with almost no scenery objects around and is about 4km away from an object-dense town. It moves in a straight line towards the town under AI control. Passes through 2 tunnels close to the town before emerging and stopping within the town. The run takes almost 8 minutes.

Dispersed scenery test

Conditions as above except that 1 instance of every house used has been placed in an area about 2 - 2.5 km before the town, so that the train will see those objects first.

Results

I used FRAPS to log the frame rate and calculate an average for several runs of the 2 tests described.

Baseline scenery = 27.5, 27.1, 26.4, 26.2 fps

Dispersed scenery = 26.4, 25.3, 31.0 fps

Here's how the frame rates varied during the last run of each scenario. I've tried to annotate the graph with what was happening during the run....

frameratetestyi1.jpg


My observations

I just happened to have graphed the two runs with the biggest difference in average frame rate (26.2 vs. 31). This unfortunately gives a misleading impression that the dispersed scenery was better than the baseline. In general it wasn't better and I think you can see that in the other data I collected.

At about the 3min-40sec mark in both scenarios, the "caching" bar came up 4 times and there was noticeable stuttering until it was finished caching. In other words, dispersing the scenery didn't improve this, much to my disappointment.

I found it interesting that even while all that stuttering was happening, the frame rates reported by FRAPS didn't really drop.

Also interesting is the rather low frame rate whenever the train (and the attached camera) went into a tunnel, but it immediately soared as the train emerged and gave the highest rate while the train was actually in the town. Not what I was expecting at all.

I can't explain any of this, but having tried it, I don't see much, if any, advantage in pre-dispersing scenery objects. So much for theories!

One thing I haven't tried yet was to use the keepallresources setting in trainzoptions.txt I guess I should give that a go, but these results don't exactly fill me with hope.

:(
 
Can you clarify on keepallresources? Does this determine whether objects will be kept in memory? IF yes, is "0" off and "1" on?

Nice research, I hope you continue.
Ed
 
Dinorius_Redundicus,

whow! Surprise all over! Exactly the opposite to expect. I love your research and its strange results. Mythsbuster! Keep us posted when you have more results and perhaps explanations.
 
Final results

@ Euphod - yep you got it. Trainzobjectz describes keepallresources like this;

"Default 0 (off). If set to 1 (on) the majority of resources will be kept in memory after being used. This will result in smoother framerates (less 'stutter') and less caching. This will also increase memory usage and may reduce overall performance, especially on low-end machines."

So that is the theory. Now for what actually happens...

Tests and conditions

Exactly the same as above, except that in trainzoptions.txt I now have the setting keepallresources = 1

Results

Average frame rates for the 8 minute runs were;

Baseline scenery = 26.5, 26.4 fps

Dispersed scenery = 26.4, 26.4 fps

This is how the 2 runs highlighted looked over time...

frameratetestkeepallresqm3.jpg


Practically identical.

Comparing these 2 runs with each other and with the previous results, I think I'm in a position now to claim boldly that using keepallresources and/or pre-dispersing the scenery makes no significant difference to caching, visual stuttering, average frame rates or how frame rates vary over time.

Can't explain any of it. The way Trainz and/or computer graphics work seem to be more complex than I ever thought. It's just disappointing that none of these seemingly logical ideas led to any tangible improvements when actually measured.

Just a side point occurred to me while doing these tests - I've seen claims that TRS2006 or Trainz Classics are 1-2fps better than TRS2004. I think such claims should be viewed with extreme skepticism. You get this type of variation even between repeat runs on TRS2004. In any case, it's an imperceptible difference.
 
@ Euphod - yep you got it. Trainzobjectz describes keepallresources like this;

"Default 0 (off). If set to 1 (on) the majority of resources will be kept in memory after being used. This will result in smoother framerates (less 'stutter') and less caching. This will also increase memory usage and may reduce overall performance, especially on low-end machines."

So that is the theory. Now for what actually happens...

Tests and conditions

Exactly the same as above, except that in trainzoptions.txt I now have the setting keepallresources = 1

Results

Average frame rates for the 8 minute runs were;

Baseline scenery = 26.5, 26.4 fps

Dispersed scenery = 26.4, 26.4 fps

This is how the 2 runs highlighted looked over time...



Practically identical.

Comparing these 2 runs with each other and with the previous results, I think I'm in a position now to claim boldly that using keepallresources and/or pre-dispersing the scenery makes no significant difference to caching, visual stuttering, average frame rates or how frame rates vary over time.

Can't explain any of it. The way Trainz and/or computer graphics work seem to be more complex than I ever thought. It's just disappointing that none of these seemingly logical ideas led to any tangible improvements when actually measured.

Just a side point occurred to me while doing these tests - I've seen claims that TRS2006 or Trainz Classics are 1-2fps better than TRS2004. I think such claims should be viewed with extreme skepticism. You get this type of variation even between repeat runs on TRS2004. In any case, it's an imperceptible difference.

If you use the jetlog method of measuring frame rates they seem to be more consistent.

Unfortunately it doesn't work or different sections unless some one can come up with a marker in the jetlog.

Cheerio John
 
The jetlog method would work if each section was driven seperately. The idea of putting buildings down before reaching the city seems OK as usually towns don't begin and end abrubtly anyway. As I'm running on a minimum specs computer these ideas are a lot of help. Mostly I'm lucky to get an average 10fpm. The roads in TC seem to eat a lot computer power so anyadvantage it may have in framerate would be negated by that. A 2006 route in TC dropped noticeably in performance and the only reason I could see was the heavy drain from the roads. Another factor to improve frame rate is to cut down on the number of different spline types. I cut the type of roads to 3 types and that boosted it. Also did the same with fences. Used tree groups instead of individual trees were I could.
 
Well I'm not sure Jetlog is the answer. The caching and stuttering were still visible no matter what frame rates were reported and regardless of what I did with scenery. This isn't something that depends on the frame-rate tool.
 
Nismit

What a stroke of luck! As it turns out, I am a human, so 25fps should be OK for me!:)

I will try your trainzoptions settings. Can you please confirm that you meant vsync to be 4 (and not 40)? Otherwise, how do I make use of the 40ms frame time that you calculated?

You may be right about my resource memory being too high (1600MB in a 2GB system) because I'm getting a random crash-to-desktop in one part of my layout and it might be associated with that. I had it set at 1600 because WinXP seemed to be using about 250MB which I thought would leave me 1750MB to play with.

Thanks very much for sharing your wisdom.

Dean
 
Last edited:
Back
Top