Performance of OR

[kox]

I've been using ShadowAllShapes setting since v645, and i'm curious if it's disabled, what determines that an object casts shadows or not? I see a route where the catenary cast shadows, locomotives too, and the buildings. But the foliage, and signal posts aren't.

If it's enabled it looks very nice, however there are some shadows that should not be. But if i disable, it's dramatically lowers the draw calls and so the cpu usage and rises fps. It seems the limiting factor of the FPS in this game (and games like this(open area games)) will be the draw calls, and the single core performance of the cpu. Will be any improvement on this? Draw call batching, or some technique to lower the draw call count, or threaded rendering? Is OR using occlusion culling for objects?

[twpol]

The determining factor for shadowing, in the default configuration, is from the MSTS Route Editor's option for shadows; although it has a choice of shadow shapes, in Open Rails they are all rendered as full, realistic shadows. If no shadow is selected in the MSTS Route Editor, no shadow is drawn in Open Rails. There are some special cases, like forests (which don't render any shadow by default), and rolling stock (which always renders a shadow) but the rest of the scenery is determined by the MSTS Route Editor option.

[twpol]

Oh, and to the draw calls - yes, we're always looking at potential ways to reduce them or other GPU calls and data.

We have threaded culling (Updater Process does culling, Render Process does drawing), but no threading of the rendering itself (that's a complex topic!) or occlusion culling (doesn't apply much to open area games, TBF). Lots to look at and try out though.

[kox]

After some testing i see that shadowing eats a lots of video memory bandwidth. (not 100% usage at any cpu processes, only 60% usage of gpu, while the fps is still lower in 2048 shadow map size than in 1024, which probably means vram bandwidth limit).

[twpol]

Yeah, dynamic shadows involve a) a lot more draw calls (everything with a shadow is drawn at least twice, maybe thrice) and b) VRAM storage of (by default) four 1024x1024 textures. These textures should never be transferred off the GPU, though, but it certainly is hard work doing shadows.

[kox]

The threads have sometimes strange behavior. I've enabled vsync, as i use OR not just for testing, but i replaced MSTS with it, so my fps is capped at 60.
It seems if the load on render thread is lowered (reached the 60 fps), same time the update thread load rises. An example:
I've waiting at the station (not real station just a stop with a platform, one track and that's all) of a branch line with a DMU consist with 2 powered and 2 non powered units, no AI trains in activity just static consists, while the updater process is at 90% cpu usage, the render process is at 60%, and the sound process is at 24%. Not the sound process too.
While on same route on a 3 tracked mainline, with 1 electric loco and 6 wagons at 120 km/h, and several AI trains roaming in activity, the updater process is at 30-40%, and the sound is at 3-5%. Why are these huge differences at different parts of the route?

I still noticing "micro stuttering" in game however much better than it was in 0.7, but I noticing heavy stuttering at tile loadings, the lack of cpu cores are can't be problem i'm not running other cpu intensive applications, and i have quad core cpu.

I wish i could help coding OR, but i don't have experience at 3d engine coding, (only physics, and train control system coding for railworks in lua script, and enterprise system coding in java).

[twpol]

The threads have sometimes strange behavior. I've enabled vsync, as i use OR not just for testing, but i replaced MSTS with it, so my fps is capped at 60.
It seems if the load on render thread is lowered (reached the 60 fps), same time the update thread load rises. An example:
I've waiting at the station (not real station just a stop with a platform, one track and that's all) of a branch line with a DMU consist with 2 powered and 2 non powered units, no AI trains in activity just static consists, while the updater process is at 90% cpu usage, the render process is at 60%, and the sound process is at 24%. Not the sound process too.
While on same route on a 3 tracked mainline, with 1 electric loco and 6 wagons at 120 km/h, and several AI trains roaming in activity, the updater process is at 30-40%, and the sound is at 3-5%. Why are these huge differences at different parts of the route?

This could be down to the current, temporary signalling - which can get quite CPU intensive depending on the exact location of trains and their paths down the line. What was the render process doing at this point, too? If it is in the 90s, it could be that it is limiting the speed things are running.

I still noticing "micro stuttering" in game however much better than it was in 0.7, but I noticing heavy stuttering at tile loadings, the lack of cpu cores are can't be problem i'm not running other cpu intensive applications, and i have quad core cpu.

The issue at tile loads is a problem with getting things loaded into the GPU completely before continuing; i.e. when the GPU driver says it has finished loaded something, it actually has only finished loading it into RAM - not VRAM - and if you then immediately try and use it to draw something, it stalls for a few milliseconds while to transfer from RAM to VRAM completes. I have so far been unable to find a reasonable way to force this wait to occur during the load, but I am still looking.

[kox]

This could be down to the current, temporary signalling - which can get quite CPU intensive depending on the exact location of trains and their paths down the line. What was the render process doing at this point, too? If it is in the 90s, it could be that it is limiting the speed things are running.

As i wrote, the render process was at 60%-70% this time. More cpu intensive on a single tracked branch line, with only one moving train (player), than on a triple tracked mainline with 3-4 AI trains too?

[twpol]

More cpu intensive on a single tracked branch line, with only one moving train (player), than on a triple tracked mainline with 3-4 AI trains too?

Can be, it depends much more on the length of track it has to scan IIRC - so if the signals are far apart, it may need to process more track sections. In any case, it's only a stop-gap until the replacement code is fully stabilised.

[eric]

Interesting... is OR smart enough to stop looking beyond a certain distance? Thinking of situations where a route and/or a branch is not signaled. I noticed a huge drop in framerates on an unsignaled route in development. I'd been in the 40's, and am now in the 15-20's.

[twpol]

Interesting... is OR smart enough to stop looking beyond a certain distance? Thinking of situations where a route and/or a branch is not signaled. I noticed a huge drop in framerates on an unsignaled route in development. I'd been in the 40's, and am now in the 15-20's.

I'm not 100% sure on the current code; it stops after it has found the expected number of signals along the path (the number in sigcfg.dat IIRC) but otherwise I don't know if it gives up after a certain distance. The new code doesn't care about the track nodes themselves, however, only the track circuits (sections between signals), so doesn't have any issues with long distances between signals or unsignalled sections/lines.