[markus_GE]

Experiments continued: shadows stay ok, even with half shadow map count (compared to MSTS, shadows MUST always be better), with viewing distance at default 2000m I now also get about 23fps on the intensive 1st street yard on the Surfliner2, at 3000m it´s still around 19, wich I actually can put up with - don´t like, but life always is compromises :sign_thanks:
Maybe will continue to experiment: If anyone´s interested in the findings, I´ll post them, just let me know!

Other question, concerning...

James Ross, on 30 April 2013 - 11:23 AM, said:

While performance for experimental features is not ignored, it must be considered a lower priority than for non-experimental features, so it might be that fixing this is not done soon if they turn out to be the culprit.

Not actually concerning the experimental features, but hte X-releases: Since the last stable release I experienced an average drop of about some 80fps - are there any efforts in the stables to improve performance over the Xs? Just as I got alittle interseted in this.

[James Ross]

Performance is always a concern, though I suspect most people don't spend all that much time looking in to it. I do when I get the chance but it's not simple in a program like OR. :sign_thanks: I don't think I've seen anyone else have the same level of drop as you, though, so it's not clear if we've just messed something up or if it's a problem tied to something in your setup or hardware.

[markus_GE]

Well, maybe we´ll see with the coming releases - I myself do some simple programming (mangament utilities for e.g. the custom screens I´ve made for MSTS; written in FreeBASIC) and sometimes the compiler just fails to do it "right" - I then go end search for, but can´t find anyy problems and a new compile magically resolves it...
However, are you (generally) interested in any further findings?

[James Ross]

More data is always better IMHO. :sign_thanks:

What might be really interesting, if you don't mind taking the time to do it, is figuring out exactly which versions have the drops. Then we can at least see what code changes were made, in case something is known to slow it down, or unexpectedly does so.

To do this, find two versions with a big difference in FPS (when using the same settings). Then pick a version about half-way between the two and see what FPS it gets. If it is close to either of the starting two versions, you can then say that the change is within the first half or second half of the revisions. You can then repeat this, each time cutting the range in half, until you have measured two consecutive versions and found the change. (This is a "binary search".)

[markus_GE]

Every version listed above is an official one, and I do only (except for one example, which I never really tried) have official experimentals installed. Also, I listed only those, that had a change of min. fps to the previous ones, so each one not listed has about the same as the one listed before it - think this is the data you asked for (if +/- 2 or 3 fps don´t matter)

Additionally I can only state, the latest official left me at about 130 fpsin Whitefish Yard, or around 70 fps in LA 1st Street.

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