[edwardk]

The biggest mistake in this situation was to try to come up with a set of numbers that I believe would work on all computers. This is not always the right direction to go. One item I must mention is that the precipitation system that is creating problems is not that different from what was utilized before. They both take up memory whether you use precipitation or not. With this in mind, I added 3 drop down selections under the experimental tab. These selections would allow the user to set up the precipitation box size that would work on his system. With this new set up, there will be no distinction between non-LAA and LAA so if you choose higher settings w/o using LAA, you will run into the same memory issues. The default settings are quite close to the settings that are used for 16bit graphic devices so if you want to conserve memory, don't make any changes. I will upload the new executables which will still be based on X3190 once I am finished.


James,

This direction had to be made. If this is something you object to, then let me know since the only option left would be to reverse the fix.

Edward K.

[disc]

edwardk, on 05 July 2015 - 08:19 PM, said:

Using X3190, I am uploading 2 executables. The LAA file needs to be tested. For those who have been experiencing any issues, and this is including the GPU load, please test this this to see if there is any improvement.

Edward K.

Now it seems it doesn't use much gpu, i don't see fps drop.

[James Ross]

edwardk, on 07 July 2015 - 04:25 AM, said:

This direction had to be made. If this is something you object to, then let me know since the only option left would be to reverse the fix.

I don't really like it but for now it's okay. We can come back to it later and figure out what's going on then.

[edwardk]

At one point, the precipitation process was 32bit capable, but at the time it was missing an important part that would allow it to work with 16bit systems. Changes were made and up to this point, OR was strictly running in 16bit. There was a post where someone mentioned why the snow was falling in an odd manner around small hills. This was the case because at 16bit, the max height can only be 43 meters. This inspired me to look into making changes which is where we are now. The unfortunate part is that my work is centered around what was already in place. The precipitation which is essentially the particle system is known to take up resources. If there is another way to make it efficient, it is definitely beyond me. This leads to my final fix. The only option was to allow the user to choose the precipitation box size. The options are Precipitation box height, Precipitation box width, and Precipitation box length.

Precipitation box height default value is 100 meters and the max is 300 meters. There is no reason to go above the max value.

Precipitation box width default value is 500 meters and the max is 1000 meters.

Precipitation box length default value is 500 meters and the max is 2000 meters.

The reason the last 2 items have such a high value is to allow weather options for those who do not necessarily drive the train from the cab. Since there are now options, depending upon how you use OR, there should be no more out of memory messages. I do have to add that since there is no distinction between non-LAA and LAA, it is up to you to know what settings are in use and what mode you are using. The default settings are very much the same to the 16bit settings with the exception of the height which was raised to 100 meters which means the memory being used is not that much different. Test this and let me know how it is working out. The executables are based on X3190.

Edward K.

Attached File(s)

•  X3190_Test.zip (1.35MB)
  Number of downloads: 153

[edwardk]

James Ross, on 07 July 2015 - 11:05 AM, said:

I don't really like it but for now it's okay. We can come back to it later and figure out what's going on then.

Thanks for the reply. What I have learned is that the particle system is known to take up resources. With this in mind, changes for efficiency would require a bit more intimate knowledge. Besides, if you look at the simulators on the market, my personal favorite being Euro Truck Simulator 2. There are many options given when it comes to graphics. If its not a menu option, its a change involving the ini file that would require the person to understand what he is changing.

Edward K.

[ChrisD]

@edwardk

New zip file downloaded and tested OK

GPU load is back to X3181 levels. :bigboss:

Thank You for making the improved precipitation selectable.

This way everyboby is happy. :pleasantry:

A question for the people in the know.

I know OR is kept at 32 bit for now, but is it possible to port part of it, f.eks. the weather engine, to 64 bits?
This way I can offer You at least 12 extra Gigs for improved Weather. :D Just a thought.

My programming skils dates back to CP/M so I do not know enough about the subject, but if OR can run several threads spreading along several cores, why not three 32 Bit threads and one 64 bit?

ChrisD

[James Ross]

ChrisD, on 08 July 2015 - 09:07 AM, said:

I know OR is kept at 32 bit for now, but is it possible to port part of it, f.eks. the weather engine, to 64 bits?
This way I can offer You at least 12 extra Gigs for improved Weather. :bigboss: Just a thought.

No, that is a process level thing, but more importantly, it is not the bitness of Open Rails which is the problem right now - the problem now is that even modest increases in number of particles and the use of 32bit (rather than 16bit) indexes seems to cause big problems on some, but not all, systems. The most intense option is only using 50-60MB of system RAM plus the same in GPU RAM. It's not clear whether it is the type of index buffer or number of particles which is the problem.

[edwardk]

James Ross, on 08 July 2015 - 11:35 AM, said:

No, that is a process level thing, but more importantly, it is not the bitness of Open Rails which is the problem right now - the problem now is that even modest increases in number of particles and the use of 32bit (rather than 16bit) indexes seems to cause big problems on some, but not all, systems. The most intense option is only using 50-60MB of system RAM plus the same in GPU RAM. It's not clear whether it is the type of index buffer or number of particles which is the problem.

James,

As of DirectX 10, there were changes made that made certain processes between the cpu and the video card more efficient. What we are experiencing under DirectX 9 is the result of the way it works. It puts the burden on the drivers to do the job and this could very well be why this issue is taking place.

Edward K.

[James Ross]

edwardk, on 08 July 2015 - 12:30 PM, said:

As of DirectX 10, there were changes made that made certain processes between the cpu and the video card more efficient. What we are experiencing under DirectX 9 is the result of the way it works. It puts the burden on the drivers to do the job and this could very well be why this issue is taking place.

No, this is completely incorrect. GPU load is how much work the graphics is having to do after all the data is transferred.

[ChrisD]

Hi.

Having dealt with the Improved Precipitation feature, I was still left with the occational CTD.

Having run X3181 and X3191-Test several times, I have found the culprit.

It seems that I/O Exception Errors like this one:


System.IO.FileLoadException: c:\msts-cz-321t\routes\trat 321\textures\aviap.ace ---> System.OutOfMemoryException: Insufficient memory to continue the execution of the program.


are there in both versions, and OR is dealing with these errors without crashing.


Studying all these logfiles I ended up finding a different Error:


Error: System.Runtime.InteropServices.SEHException: External component has thrown an exception.


This error is only there occational in X3191-Test, but never in X3181.

Here is the complete text:


Error: System.Runtime.InteropServices.SEHException: External component has thrown an exception.
at new[](UInt32 )
at Microsoft.Xna.Framework.Graphics.VertexBuffer.CreateBuffer(UInt32 dwSize, UInt32 usage, _D3DPOOL pool)
at Microsoft.Xna.Framework.Graphics.VertexBuffer..ctor(GraphicsDevice graphicsDevice, Type vertexType, Int32 elementCount, BufferUsage usage)
at ORTS.Viewer3D.TerrainPrimitive.GetVertexBuffer(Single& averageElevation)
at ORTS.Viewer3D.TerrainPrimitive..ctor(Viewer viewer, TileManager tileManager, Tile tile, Int32 x, Int32 z)
at ORTS.Viewer3D.TerrainTile..ctor(Viewer viewer, TileManager tileManager, Tile tile)
at ORTS.Viewer3D.TerrainViewer.<>c__DisplayClass8.<Load>b__1(Tile tile)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.<UnionIterator>d__81`1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at ORTS.Viewer3D.TerrainViewer.Load()
at ORTS.Viewer3D.World.Load()
at ORTS.Viewer3D.Viewer.Load()
at ORTS.Processes.GameStateViewer3D.Load()
at ORTS.Processes.LoaderProcess.Load()
at ORTS.Processes.LoaderProcess.DoLoad()
at ORTS.Processes.LoaderProcess.LoaderThread()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()


OR does not survive this Error.


JR, can You make something out of this?

ChrisD