[disc]

 charland, on 09 September 2014 - 08:34 AM, said:

Hi James and disc,

OK, I did find the checkbox for Large Adress Aware and that cured the problem, bumping the available RAM to 4 GB. I did notice something interesting using the graphs, so I took some pictures along the way. After loading the heaviest tiles and then traveling through what should have been easy rural scenery, the game still held on to the heavy Bellows Falls tiles for seven miles before deleting them from the memory.
Paul :-)

2000 object and 8000+ draw calls? that means average 4 draw call per object, which isn't too optimal :) i see nearly the same on every msts routes.

However you should check "Use model instancing" to at experimental, it may lower the drawcall count, and the cpu usage.

[charland]

Hi disc,

Have no idea what Use model instancing means but I'll give it a try!

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.

Paul :-)

[RTP]

Reduce the amount of smoke in your loco.

Is a memory killer.

Regards.

[James Ross]

 charland, on 09 September 2014 - 08:34 AM, said:

OK, I did find the checkbox for Large Adress Aware and that cured the problem, bumping the available RAM to 4 GB. I did notice something interesting using the graphs, so I took some pictures along the way. After loading the heaviest tiles and then traveling through what should have been easy rural scenery, the game still held on to the heavy Bellows Falls tiles for seven miles before deleting them from the memory.

Thanks for trying things; the tiles are kept for as long as they're needed for the set view distance and only discarded at the next tile boundary. Each time you cross a boundary, the game checks what new tiles need to be loaded and what old tiles to discard. Your viewing distance is set to 5.3km so it's quite possible to still have them loaded 7 miles (~11km) down the track, depending on how much the track is not a straight line, where the boundaries are exactly, etc..

There are a variety of things we do poorly with respect to memory usage of scenery, such as keeping all LODs loaded (including GPU memory), which would probably help a lot for higher viewing distances.

[charland]

Hi James,

Thanks, I'm just figuring that out as I go and it's making a lot of sense. I took disc' suggestion and checked the 'use model instance' and the memory usage went up from a max of 1976 to 2042 but where it was loading the heaviest tile and causing the earlier crashes that started this thread, it was actually smoother.

RTP... not my locomotives, just using them for testing while building the route!

Paul :-)

[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.