[disc]

charland, on 09 September 2014 - 09:45 AM, said:

There is just the one tile with 2250 objects, the rest are 1000 objects or less. Just happened that all of Bellows Falls and North Walpole ended up on one tile.

2000 objects aren't much, what is: too much draw calls needed to draw those objects. As you can see on shape-material-texture ratio: in average, each shape have four materials or textures in on this route. To draw each texture or material needs extra operations from CPU, which is slows the games down (any game, not just openrails).
That's why when making a 3d shape, the optimal for gaming is to use as few texture files/materials as possible, even by using bigger combined textures for multiple objects, instead of smaller separate texture files.

This is why the "Use model instancing" option made the game run faster, because that makes the game draw multiple instances of the same object draw just once and copy them instead of drawing it as many times as it appears in the view. But there are more techniques that can lower the cpu usage (and make the game run even more faster), that need as few materials/textures as possible.

[charland]

Thanks for the explanation disc, I think I used a bit of both methods when I was constructing the buildings for Bellows Falls. For the very most part the building use one or two large ace files with the each side of the building in that one file but they may also include a couple of common small files to things like the chimney and foundation. I also pushed the limit for the tile by grouping several buildings all as one object until I was near 1700 polygons in the object (12 to 16 houses all as one object).

Paul :-)

[disc]

charland, on 10 September 2014 - 06:28 AM, said:

Thanks for the explanation disc, I think I used a bit of both methods when I was constructing the buildings for Bellows Falls. For the very most part the building use one or two large ace files with the each side of the building in that one file but they may also include a couple of common small files to things like the chimney and foundation. I also pushed the limit for the tile by grouping several buildings all as one object until I was near 1700 polygons in the object (12 to 16 houses all as one object).

Paul :-)

Grouping to one object is good too, but the most important is to group the textures. For most of the scenery objects, it's easy to 1-1 shape-texture ratio, for frequently used ones (like trees, bushes), multple shape's textures can fit in a single 2048*2048 texture. (Even a 60k poly high detailed locomotive is possible to use 3 textures for exterior model, though one frome these textures is 4096*4096).

If you group the objects, but not the textures, the game will need the same amount of draw calls to draw them as if you didn't group them. So if you group 16 object to 1 object that use 16 textures, that will be 16 draw calls to draw it, just like if you had 16 object that use overall 16 textures. But if you group that 16 texture to one, and group the shape to 1 object, that will be 1 drawcall to draw them.
However drawcall batching (which is not yet present in OR, but probably will in the future), does the object grouping for you(while you can independently move the single objects) in realtime IF these objects using the the same textures.

[disc]

I've tried to find out what is causing the stuttering, by turning on and off all of the settings, even by lowering the view distance to 500m and disabling shadows, so by making sure that none of the cpu cores have usage close to 100% usage (real quadcore cpu). But the stuttering still there... so it seems every small action (however it maybe not so small, but a cpu usage spike, but the ingame process graphs are smoothed) of loader process makes the game stop for shorter or longer time... just i don't know what does it loads constantly, while the neighbouring tiles are loaded already... even i seeing that when starting a new game, the loader uses one core at 100% in the first seconds, then drops to 0%, then without touching anything few seconds later starts to load again, then pause then again...
The stuttering happens on default msts routes too, however only happen at new tile load, when loader process works.

[James Ross]

disc, on 10 September 2014 - 03:05 PM, said:

I've tried to find out what is causing the stuttering, by turning on and off all of the settings, even by lowering the view distance to 500m and disabling shadows, so by making sure that none of the cpu cores have usage close to 100% usage (real quadcore cpu). But the stuttering still there... so it seems every small action (however it maybe not so small, but a cpu usage spike, but the ingame process graphs are smoothed) of loader process makes the game stop for shorter or longer time... just i don't know what does it loads constantly, while the neighbouring tiles are loaded already... even i seeing that when starting a new game, the loader uses one core at 100% in the first seconds, then drops to 0%, then without touching anything few seconds later starts to load again, then pause then again...
The stuttering happens on default msts routes too, however only happen at new tile load, when loader process works.

Do the pauses correlate with the GC chart (small purple spikes, just below the memory graph)? Loading often causes a clump of GCs and if they are full collections (the spike goes all the way up) the whole process gets paused for a portion of the GC. (You can get a log of GC times from some of the .NET-capable performance tools.) Another possibility is we're loading something from disk from the render or updater processes by mistake.

I might try making the process monitoring be per-frame but I seem to remember that it has a certain amount of overhead in collecting the data.

[disc]

In stuttering time the GC graph has spikes (mostly at loading time), and valleys which are rapidly following each other.

[James Ross]

disc, on 11 September 2014 - 01:43 AM, said:

In stuttering time the GC graph has spikes (mostly at loading time), and valleys which are rapidly following each other.
Open Rails 2014-09-10 11-41-00.png

Hmm, that's a very noisy GC graph. I don't think I've seen anything like that before. Mine rarely gets anywhere close to that - it usually goes a dozen frames or more with no GCs at all, where as yours has generation 0 collections pretty much every frame. The FPS data suggests a very unstable frame rate, as you'd expect with stuttering.

What's it like with everything turned off on an MSTS in-box route? I get nearly nothing on the GC graph (literally less than a dozen GCs across the entire chart, typically) and that's with everything on. I wonder what's causing this high GC activity.

[gpz]

Isn't the unloading makes work to GC? Maybe unloading content should be smoothed a bit for not doing a whole tile in a single moment.

[disc]

Here is screenshot with a default route, the FPS is locked at 60, but there are constant GC spikes here too.


And the GPU usage never goes above 60%, nor on default or on heavily populated routes like above.

[James Ross]

gpz, on 11 September 2014 - 02:00 AM, said:

Isn't the unloading makes work to GC? Maybe unloading content should be smoothed a bit for not doing a whole tile in a single moment.

Unloading causes less GC activity than loading. Loading creates many, many temporary objects while processing the data before it settles down, unloading discards a much smaller amount. GCs are triggered by allocation (so trigger much more during loading) and their performance scales with the amount of garbage they're removing (which is high during loading). Unloading isn't innocent but I've measured it and loading is way worse.

[James Ross]

disc, on 11 September 2014 - 02:07 AM, said:

Here is screenshot with a default route, the FPS is locked at 60, but there are constant GC spikes here too.
Open Rails 2014-09-11 12-05-22.png

And the GPU usage never goes above 60%, nor on default or on heavily populated routes like above.

Hmm, curious. Locked to 60 FPS on a default route, I have so little GC activity it is basically meaningless. Your FPS seems stable here but I guess that's because it's locked to v-sync. I'll have to check this out on my system again in case something's changed since I last observed it.

[disc]

When i disable vsync, i get 93 fps, but the frame time is stable there.
Isn't there a tool that can be used for profiling .net applications (cpu usage of, methods, memory accesses).

[James Ross]

disc, on 11 September 2014 - 02:20 AM, said:

When i disable vsync, i get 93 fps, but the frame time is stable there.
Isn't there a tool that can be used for profiling .net applications (cpu usage of, methods, memory accesses).

There's a few, what do you actually want to measure though? You can't possibly measure memory access but you can trace method calls, memory usage, CPU usage, GPU calls/usage, file and other OS access, trace GC and JIT and probably some other things. (Example tools are dotTrace Performance/Memory, XPerf, Windows Performance Recorder/Viewer, PerfView.)

[disc]

James Ross, on 11 September 2014 - 02:30 AM, said:

There's a few, what do you actually want to measure though? You can't possibly measure memory access but you can trace method calls, memory usage, CPU usage, GPU calls/usage, file and other OS access, trace GC and JIT and probably some other things. (Example tools are dotTrace Performance/Memory, XPerf, Windows Performance Recorder/Viewer, PerfView.)

I was just curious what the game does in runtime, especially what causing that the sound thread is using sometimes 70% cpu, and sometimes just 10% while, no audible differences in sounds. So i installed the free, opensource "SlimTune" profiler, and i saw that the sound process spends 60% of its cpu time with the track sounds, 40% left for any other sounds, which look weird. So i removed all tracksounds (16), and the sound process cpu usage dropped from 70% to 30%. Of course this isn't connected to stuttering, it was just curiosity.

And now i see, that the sms setting for this route have serious overkill settings with lots of active sounds to active to 500 metres and more, and a lot of them have really unrealistic distance to volume settings. (funny thing that i helped configuring sounds for railworks/ts and the most of sounds got deactivated at 300 metres, and that was fairly enough)

[gpz]

Unfortunately handling of track sounds is a mess currently, and it is highly suboptimal for giant routes (like Alföld). I haven't even tried to modify it, since it would need a big rewrite.