[SetiRich]

I run a few routes that in their day were 'memory hogs' However, back then, a good sized machine was 6 or 8 gig. Today, I have two machines that are GE 64 gig. I'd really love to have the detailed 3D experience that current video stuff has to offer...in ORTS.

I guess the most desired feature is being able to fill up the yards. Its annoying when passing through yards that seems quite small, such as 8 to 15 tracks, that most of them are empty, or if you want to put stuff in them, its limited to many tracks of non-functional 'scenery objects'.

I've searched this site for various strings I thought would capture the essence of what I'm looking for, but nothing seems to pop out. Any ideas for what the issues are with (development of) larger memory capability and what is required for such an animal?

Thanks,

Rich

Got all my shots! I'm ( or should be ) FREE....

[vince]

In the PRR-East v2' activity 'Senator Vincent' I filled every yard from New Jersey to Washington DC with runable static consists and have over 100 AI traffic trains running.

My system specs:
Date/time = 3/4/2021 8:51:44 PM (2021-03-05 04:51:44Z)
BIOS = V1.11 (American Megatrends Inc.)
Processor = Intel® Core™ i5-4430 CPU @ 3.00GHz (4 threads, 4 cores, 3.0 GHz) (CPU Internal L2 1024 KB) (CPU Internal L1 256 KB) (CPU Internal L3 6144 KB)
Memory = 7.9 GB
Video = NVIDIA GeForce GT 1030 (2.0 GB RAM) (nvlddmkm 27.21.14.5671)
Display = \\.\DISPLAY1 (1920 x 1080, 32-bit, primary, 0 x 0)
Sound = High Definition Audio Device (hdaudio 10.0.19041.264)
Sound = NVIDIA High Definition Audio (nvhda64v 1.3.38.35)
Disk = C: (Local Fixed Disk, NTFS, 930.5 GB, 773.3 GB free)
Disk = D: (CD-ROM Disc, )
Disk = E: (Local Fixed Disk, NTFS, 238.5 GB, 53.1 GB free)
Disk = F: (Local Fixed Disk, NTFS, 931.5 GB, 587.6 GB free)
Disk = G: (Local Fixed Disk, NTFS, 1862.4 GB, 732.4 GB free)
Disk = H: (Local Fixed Disk, NTFS, 1023.9 GB, 926.2 GB free)
Disk = W: (Local Fixed Disk, NTFS, 298.0 GB, 269.2 GB free)
OS = Microsoft Windows 10 Pro 64-bit (10.0.19042)
Runtimes = 2.0.50727 SP2 3.0 SP2 3.5 SP1 4 Client 4 Full 4.0 Client
Runtime = 4.0.30319.42000 (32bit)
\\.\DISPLAY1 = NVIDIA GeForce GT 1030
--------------------------------------------------------------------------------

I don't know if Open Rails uses more than 4 Gig of RAM but my system runs any routes I've just fine.

Regards,
vince

[superheatedsteam]

If you are interested in observing the memory usage of a process I would suggest the VMMap program. https://docs.microso...downloads/vmmap

[vince]

 superheatedsteam, on 12 March 2021 - 04:29 PM, said:

If you are interested in observing the memory usage of a process I would suggest the VMMap program. https://docs.microso...downloads/vmmap

Open Rails can do that and display it on the F5 HUD Debug Screen.

regards,
vince

[Genma Saotome]

On the last page of the f5 tab display there is a piece of data labeled primitives, which I understand to be a proxy for drawcalls. In high object routes that number will be pretty high and at some number that varies from machine to machine it will climb high enough to drop fps below 60. From that point on it's pretty much a straight line relationship between high primitive count and low fps. IOW in most cases memory isn't a factor.

Once fps drop below your satisfaction the only thing I know an end user can do is to turn on Instancing (on one of the initial menu tabs). You might get a few percent improvement. After that it's reducing rolling stock..

IIRC there are a few simple static objects over at TS.com that represent strings of cars for a yard. You might look for them too.

[James Ross]

 SetiRich, on 12 March 2021 - 01:29 PM, said:

I run a few routes that in their day were 'memory hogs' However, back then, a good sized machine was 6 or 8 gig. Today, I have two machines that are GE 64 gig. I'd really love to have the detailed 3D experience that current video stuff has to offer...in ORTS.

Open Rails can currently run as 32bit only, which means 2GB on 32bit operating systems (hopefully rare now!) or 4GB on 64bit operating systems.

Our graphics library XNA was one component that was limiting us to 32bit, but that is resolved now we have finally switched to MonoGame. However, we haven't yet switched to 64bit because there may be other issues and it might not even be desirable for performance in some cases, so there's work for us to do there.

However, the XNA -> MonoGame switch does have some immediately useful benefits for memory usage: in XNA, all graphics resources (textures, models, shaders, etc.) existed in both Open Rails's memory (RAM) and graphics card memory (VRAM). This is not the case in MonoGame, where these resources only exist in VRAM, saving RAM within Open Rails for other things.

A quick comparison of a moderately activity at start: 504 MB RAM in 1.3.1 (Stable Version) and 386 MB RAM in X1.3.1-323 (Testing Version), a 23% saving.

We can and should look to validate that the memory used in Open Rails us useful and correct, too, because there may be other savings to be had.