[James Ross]

Ah, I see. Thanks, useful to know the skipped ones are the same as the previous one.

[disc]

Do the developers though about converting some performance critical part of OR to native? (as i heard .net have a feature for this, called "native images". Maybe it would speed up the game.
But still, i think the best solution for performance problems would be the draw call batching/ or new 3d engine. It's clearly vistible from the examples above, that always the render thread limits the overall performance of the game.

[James Ross]

disc, on 01 May 2013 - 07:07 AM, said:

Do the developers though about converting some performance critical part of OR to native? (as i heard .net have a feature for this, called "native images". Maybe it would speed up the game.

Yes, it is one of many options. However, a large portion of Open Rails's rendering time (which you correctly note below is often the limiting factor) is spent in native calls already. Almost all native execution time is spent in the draw calls and related calls in to XNA (which then calls DirectX directly). It's not completely clear how much of the time is spent in interop (the work needed for .NET to call native) and how much is in DirectX and the graphics drivers, but I believe it is actually weighted towards the latter.

It is because of this that I don't believe replacing any part of the rendering pipeline with native versions will, in itself, make a worthwhile difference in performance. However, if anyone has actual data regarding this, I'd certainly be interested in seeing it.

We have, though, been looking at newer versions of XNA (i.e. 4.0) and alternatives (e.g. ANX) as well as non-XNA-like solutions (e.g. SharpDX) to see if the performance of the calls is a factor of the CLR (.NET) version, XNA version, XNA vs. alternatives or intrinsic to DirectX.

disc, on 01 May 2013 - 07:07 AM, said:

But still, i think the best solution for performance problems would be the draw call batching/ or new 3d engine. It's clearly vistible from the examples above, that always the render thread limits the overall performance of the game.

Some of the ways the engine appears to work is due to MSTS's poorly thought-out content, i.e. shapes will regularly use a whole swathe of different textures that could have - if anyone had been bothered - been turned in to a single texture atlas (or maybe two, for alpha blended and opaque). Unless we, in OR, dynamically do texture atlasing (which isn't going to be much fun) the way these MSTS shapes are drawn in so many bits is mostly fixed.

Regarding "draw call batching", there's some confusion of what this phrase means, it seems. One definition is just about the order draw calls are done: Open Rails already puts all the draw calls for the same material (texture + state) together and only initialises the shader once, so it satisfies this definition already. On the other hand, if you mean something more like "display lists" (as I think OpenGL calls them) or "command buffers" (as DirectX calls them), where by the application makes only 1 call, that's another story. I am very interested in any ability to do display lists/command buffers. I have not seen anything intrinsic to XNA for doing them, though, but there are things that might be interesting to try, like Parallel Rendering with DirectX Command Buffers.

[markus_GE]

Wow, I never thought this thread would turn out that "abstract" :)

Here are my further findings during experimenting (mostly registry stuff for "unofficial" settings): ShadowAllShapes enabled (I forgot to mention above, that I always have it enabled) I get at First Street Yard, LA, on the Surfliner2...

• ~19 fps, if: ShadowMapBlur 1, ShadowMapCount 4, ShadowMapResolution 1024 (all the default settings)
• ~28 fps, if: ShadowMapBlur 0, ShadowMapCount 2, ShadowMapResolution 1024 (however, this turns out to look "like the southern end of a northbound husky", as Genma Saotome once called an ugly steam engine :) )
• ~ 26fps, if: ShadowMapBlur 0, ShadowMapCount 2, ShadowMapResolution 2048 (looks a bit better)
• ~ 25 fps, if: ShadowMapBlur 0, ShadowMapCount 3, ShadowMapResolution 1024 (about same as above)
• ~ 24 fps, if: ShadowMapBlur 0, ShadowMapCount 3, ShadowMapResolution 2048 (looks again a bit better, is the compromise I now found)

For all of these I used ShadowAllShapes 1, Viewing distance 3000m, DM 50km, SE 3, min length 50m, wire on (although none to show), show trainlights & precipitation. The latter ones, including all from SE on, were always the same during all test I mentioned within this thread.

[disc]

James Ross, on 01 May 2013 - 07:39 AM, said:

Some of the ways the engine appears to work is due to MSTS's poorly thought-out content, i.e. shapes will regularly use a whole swathe of different textures that could have - if anyone had been bothered - been turned in to a single texture atlas (or maybe two, for alpha blended and opaque). Unless we, in OR, dynamically do texture atlasing (which isn't going to be much fun) the way these MSTS shapes are drawn in so many bits is mostly fixed.

Of course a lot is depending on the content, but if there are 1000 identical trees in the view for example, and if those could be drawn by a single draw call, that would make a big difference.


About the tests: I thought that ShadowMapCount is controls shadow map "LODs", so if 4 is set and 2048*2048 shadowmapResolution is set, then there will be a 2048x2048 map for the closest objects, 1024x1024 for more distant, 512 even more distant, and 256x256 for the most distant objects. So lowering this would cause performance impact, but the opposite happens. So what is is that ShadowMapCount?

[markus_GE]

disc, on 01 May 2013 - 11:33 AM, said:

About the tests: I thought that ShadowMapCount is controls shadow map "LODs", so if 4 is set and 2048*2048 shadowmapResolution is set, then there will be a 2048x2048 map for the closest objects, 1024x1024 for more distant, 512 even more distant, and 256x256 for the most distant objects. So lowering this would cause performance impact, but the opposite happens. So what is is that ShadowMapCount?

I also thought so at first, but then, why not try, and look what it did :) And yes, I would also like to know that (obviously forgot to add it in the post above...)

[James Ross]

disc, on 01 May 2013 - 11:33 AM, said:

About the tests: I thought that ShadowMapCount is controls shadow map "LODs", so if 4 is set and 2048*2048 shadowmapResolution is set, then there will be a 2048x2048 map for the closest objects, 1024x1024 for more distant, 512 even more distant, and 256x256 for the most distant objects. So lowering this would cause performance impact, but the opposite happens. So what is is that ShadowMapCount?

That's not quite how it works; it generates each shadow map at the same resolution (e.g. 1024x1024) but each subsequent one covers a much larger area from the camera. Reducing the number of shadow maps should increase performance, as should lowering their resolution.

[markus_GE]

Yeah, that´s also what I experienced - however, it´s just suitable for finetuning performance VS graphics, like I did. It doesn´t really affect framerates, far less that the ShadowMapBlur option. What for is that actually inplemented? I personally think, with it turned of the shadows look much more realistic..

[James Ross]

markus1996, on 02 May 2013 - 12:06 PM, said:

Yeah, that´s also what I experienced - however, it´s just suitable for finetuning performance VS graphics, like I did. It doesn´t really affect framerates, far less that the ShadowMapBlur option. What for is that actually inplemented? I personally think, with it turned of the shadows look much more realistic..

The blurring is, I believe (it was a while ago that I implemented this) to soften the edges of the shadows to avoid sharp jaggy edges. I'm not really sure what the difference looks like in the game today though...

[disc]

James Ross, on 02 May 2013 - 01:05 PM, said:

The blurring is, I believe (it was a while ago that I implemented this) to soften the edges of the shadows to avoid sharp jaggy edges. I'm not really sure what the difference looks like in the game today though...

it's still needed for that reason, however it blurs too much. 1024 or above the shadowmaps aren't so jaggy. so blur intensity could be reduced.

[markus_GE]

At the 2048 resolution I´m using now (3 shadow maps), it´s alsoo acceptable without blur - if you don´t zoom in zo half a metre :sweatingbullets:

[Metro4001]

I hate to bump an old thread but whooooo, OR framerates have definitely taken a dive. I don't understand the rhyme or reason for it. I'm running an activity on the Scenic Sub 2.0 and the framerates range from 1-70, but average about 40. OR doesn't seem to like vegetation near the tracks at all. I can go through certain areas and the framerates are fairly good and go through seemingly identical areas and the framerates drop to the teens, or worse. AI trains don't have any bearing on this. I look at the memory usage on my graphics card and it's about 900 out of 2500mb. It's a GTX570. Any tips?

[spud]

Just for comparison I ran the same scenerio with v1251 and v1605 with nothing different or changed and there is a 50% drop in FPS between the two versions.
:furiousPC:

[copperpen]

I too have just run a comparison on one activity using 1265 and X1614 using the same standard starting view. In both cases the FPS steadied on 150, so no FPS drop here.

[markus_GE]

As I somewhere above was requested to do so, would you mind telling what your render and updater process values are like like? (in F5 hud press shift + F5 as many times, until you see the values)

Cheers, Markus