[Gary54]

I realize that the Out of Memory issue has been addressed before but I thought I might bring it up again as it appears that it happening with more frequency...at least in my case. For the past six weeks or so, I have been running Austin Yoder's Horseshoe Curve route with OR. This has entailed making a number of activities that have included moderate numbers of AI trains in order to test signals and general train behavior with OR. While the route does push the resource limit, I have been more than pleased with the results. While there has been the occasional OutOfMemory crash, these were few and far between. However, this seems to have changed recently (I am using X1781; some issues started around X1770).

Basically, the problem is that I am unable to get past some route locations, even when there are no AI trains running and I have Distant Mountains unchecked, viewing distance set at 3000m, World Object Density = 5, automatic tuning at 30 FPS, and dynamic shadows unchecked. For what it's worth, FPS remains quite high (sometimes > 100) just before the crashes to desktop occur.

I have attached two logs, each one representing failure at a given set of settings. I really have little understanding of these reports; however, it is apparent that there are numerous "Insufficient memory to continue" problems associated with various terrtex\mosaic ace files.

I'm not sure how to classify this problem. Could it be an issue related to OR or perhaps a route problem?

Thanks for any thoughts on this.

Gary

Attached File(s)

•  OpenRailsLog B.txt (174.46K)
  Number of downloads: 177
•  OpenRailsLog A.txt (179.75K)
  Number of downloads: 166

[captain_bazza]

Hi'ya Gary,

You need to supply the team with your system specs, please. As much info as you have about it will help enormously.

Cheers Bazza

[Gary54]

Sorry about that, Bazza, and thanks for getting back to me. We are running an AMD Phenom II X4 975 Processor, 3.60 GHz, 8.00 GB RAM, 64-bit OS, and Windows 7 Home. OR is running from the same drive as is MSTS.

Hope this helps.

Gary

[Gary54]

I failed to provide information regarding the video card. I'm using the NVIDIA GeForce GTX 460 v2.

Gary

[James Ross]

Gary54, on 28 September 2013 - 05:27 PM, said:

However, this seems to have changed recently (I am using X1781; some issues started around X1770).

It would be useful if you know the last version it worked in and first it didn't - at least as far as versions you've run - to narrow down the issue.

For example, X.1757 had a rewrite of much of the terrain handling code and it is quite likely it has changed which and when tiles and bits of terrain are loaded and drawn.

There's also a bug that existed from X.1738 through X.1777 with headlight data that could sometimes consume a lot of memory.

[Gary54]

I have to admit that I have not been using OR long enough to develop a sense of history regarding its behavior. However, I have had some time to try a few things relative to the System.OutOfMemory problem that initiated this thread with. I should point out that I have been using X1781 for much of this but have noticed similar behavior with X1788. The area of the route that has been problematic is its most heavily sceniced part (it's not uncommon to see textureless truck traffic on the nearby streets). As a result, I decided to set the "Automatically tune settings to keep performance level" at 30. This was followed by the System.OutOfMemory crashes at one location on the route that prompted me to start this thread. At some point (while using X1781), I reduced the number of AI trains to one (a manageable value)and decided to uncheck the above-cited option. This combined with unchecking the "Distant mountains" option allowed me to get past the previous crash point (reported on in my initial post) without problem. I should add that frame rates were never really a problem, so I suspect that there was no need for me to use the option.

One other point - throughout much of this time (and even after things were working reasonably well), activating the Quick Save option caused OR to freeze. Half the time, the save worked - the other half there was no record.

In sum, it appears that this behavior can be chalked up to a memory loss in an area that taxes system memory. The most important observation may be the fact that terrain problems were more of an issue when using the "Automatically tune settings to keep performance level" option. I couldn't even begin to offer an explanation for this.

Gary

[gpz]

Gary54, on 29 September 2013 - 04:29 PM, said:

At some point (while using X1781), I reduced the number of AI trains to one (a manageable value)and decided to uncheck the above-cited option. This combined with unchecking the "Distant mountains" option allowed me to get past the previous crash point (reported on in my initial post) without problem.

I think the most helpful would be if you could test which of the three options allowed you to get past of the crowded area. I mean, you might only disable one option of the three at a time. If that doesn't help, enable it again, and disable an other one. And so on. This would help localizing the area in the code the problem is with.

[James Ross]

Gary54, on 29 September 2013 - 04:29 PM, said:

In sum, it appears that this behavior can be chalked up to a memory loss in an area that taxes system memory. The most important observation may be the fact that terrain problems were more of an issue when using the "Automatically tune settings to keep performance level" option. I couldn't even begin to offer an explanation for this.

If you're getting good FPS, i.e. above the target set, the viewing distance will be increased. It sounds quite possible that the viewing distance was beyond the 3000m you manually set, which would indeed make for more memory pressure. This is something that the performance tuner does not yet take in to account. :rofl2:

[Gary54]

Very interesting comment. As it turns out, I was doing two things that may have conflicted. First, I was setting the automatic tuning option to 30 FPS at the same time I was setting the viewing distance to as low as 2500 m. As I approached the problem area, I noticed that FPS values > 60 FPS, going as high as 100 FPS. This is when OR suffered the memory crashes

In response to gpz; I have been able to isolate the issue to running with the automatic tuning option checked while having the viewing distance et at 3000 m or less. I can now get through that area using both X1781 and X1788 by unchecking the automatic tuning option and the distant mountains.

[James Ross]

Gary54, on 30 September 2013 - 06:39 AM, said:

Very interesting comment. As it turns out, I was doing two things that may have conflicted. First, I was setting the automatic tuning option to 30 FPS at the same time I was setting the viewing distance to as low as 2500 m. As I approached the problem area, I noticed that FPS values > 60 FPS, going as high as 100 FPS. This is when OR suffered the memory crashes

They do not exactly conflict; rather, the viewing distance starts off at whatever you've manually set (e.g. 2500m) and is then dynamically adjusted while the game is running, based on the current FPS. If you press Shift-F5 to switch to the DEBUG INFORMATION page of the HUD, the "Camera" line's last-but-one value is the current viewing distance (for reference, the values are: TileX, TileZ, X, Y, Z, terrain altitude, viewing distance, low-resolution viewing distance).

It's possible that the tuner cannot cope with a target as low as 30 FPS whilst you are getting 60-100, or, more likely, it simply tunes the viewing distance all the way to the maximum allowed value of 10km and that is too much (perhaps far too much) scenery to be loaded at once, in this part of the route.

For now, I'd suggest turning off the performance tuner, but I would like to add enough smarts to it to avoid this problem in the future.