Bumping this, because this thread mainly about testing the limits of the game's graphics engine.
I just did some more quick testing. I had a game save of AoS Blue Streak with plenty of city/industry development on it, and a full rail network running 234 trains. As I said over in the Death Trap thread, I tested replacing all locos with the 2-6-4T Double Header, which has a verts count around 40% higher than the PopTop H10 Mikado, and a tris count around 90% higher, and has 5 LOD's like the default model. I then picked a train that had a good long run through a range of stuff and followed it.
Frame rates varied wildly. At one point going as low as 17, and at other times getting up around 100. Chicago seemed to generate higher frame rates than the rest of the run to St. Louis. After checking out things and thinking about it, I suspect this may be down to the absence of trees in the Chicago area. It doesn't seem to be affected by the number of trains on screen at close range, since Chicago was often full of them and frame rates were always at least 70.
The low point of 17 fps occurred with rain, and when crossing the river to St. Louis. That area is also chock full of trees. I think the extra eye candy involved in all of that is what made the difference.
I also noticed that although frame rates were normal for at given area at night, having the moon come up just after sunset knocked the frame rate back quite a bit. It would lose an easy 20 fps while the moon was rising and the sky colour was changing, and then go back to normal once night had set in fully.
Another weird thing I noticed, and it was totally repeatable, was that
frame rate was affected by the direction the camera was facing. With the camera locked onto a train, the frame rate was highest when the camera was pointing in the train's direction of travel.
Turning the view so the camera faced the rear of the train always resulted in an immediate and significant drop in frame rate. I was watching the frame rate go up and down like a yo-yo just by repeatedly changing the direction of view.
Ok, so all of this is with 2-6-4T doubles. I then changed it to all H10 Mikado Doubles, which obviously have a verts and tris count twice that of the default H10. These were the early development version of the double H10, not the version in the post just above. The difference is that the early version has 5 LOD's, and the latest (lazy) version doesn't.
Anyway, frame rates didn't seem to be much different. I didn't see it go as low as 17, but then this time around I didn't get the combination of rain and the river crossing. Lowest rate was around 21 or so. Highest was still in Chicago, and still up around 100.
Ok, next test: change the whole roster to default single H10 Mikados, and immediately halve the number of loco verts and tris on screen.
Not a lot of difference, AFAICT. Frame rate was still low sometimes, and still high in Chicago. The overall frame rate (across the whole run) between all H10 Doubles (2,500 verts and 1,700 tris) was maybe 10% different to the frame rate with all default H10 singles (1,250 verts and 850 tris). With all 2-6-4T Double it was in the same range, as you'd expect. It was still affected by moonrise, and it was still affected by the direction the camera was facing.
Although the H10 has around 50% more verts than the 2-6-4T it only has around 5% more tris. This figure may be more important than the verts count (
see Best Answer here), since frame rates seem to be very close with either model running. I will also go through the H10 and 2-6-4T models and check for the number of separate objects (ie: draw calls). That could be handy for comparison with other custom models. Basically, more separate objects = worse performance for same number of tris. And sometimes, more verts can =
better performance for same number of tris (because if you split a position into two verts it can save the gfx card having to do it).
I did try dropping tree density from 100% down to the slider's minimum of 40%. That gave some improvement in frame rate, but not a huge amount. It'd be interesting to test a map with no trees at all, and then the same map with lots of trees along the route. It'd also be good to test the same route with different weather conditions and time of day locked in.
I should also test swapping between the default H10 and my A1 Berkshire. This would be useful because since the Berkshire was built before we could use Blender, it has exactly the same numbers of verts and tris as the default H10, but it doesn't have 5 LOD's to reduce gfx loading at long range. Like all locos that customised the body mesh during the pre-Blender-export-script period, it only has the top LOD.
Short version is that AFAICT at the moment the loco poly count has some effect, but the frame rate is affected by a lot more than the poly count** of the locos, or the number of locos on screen, and these other factors seem to make more of a difference.
**(meaning number of tris, which aren't really polygons as such even though that's what every script kiddy wants to call them
)
I never saw or adjusted any of those settings. I will now have to experiment if I can get the game to stop freezing with some different settings.
I did do a good bit of modeling for it for a friend of mine who was doing a lot of of route development, before finally uninstalling it.
