Object/RouteViewer Out of Memory

I've noticed when working on objects and routes, after a certain period of time when you refresh the viewers it starts to gradually unload all the textures on the object or route until it eventually crashes. It also gives error messages shown here. I've been using the latest nightly build whenever possible but it has happened when I have used the 1.6 and 1.7 stable versions too. I don't think it's much of a problem at all but are there some things that I can do to reduce the times it does this?

It shouldn't be doing that

Will try and take a look tomorrow and see if I can find anything obvious, just need to find a giant object. (I've never seen this or any major memory growth)

I forgot to mention it happens after quite a long period of time, though the shortest time I've recorded it to happen is around 30-40 mins but that was with a route. I'm not sure if it's to do with how long the viewer is open for

I can see a slight uptick in memory when something is reloaded, but that then drops back again after a minute or so, when the underlying .Net garbage collector runs.
I think this is a combination of massive object / route and a slight inherant lag in .Net garbage collection routines.

I've pushed a somewhat speculative fix into today's build which may help things a little, not sure on that front. Fundamentally though, I'm not sure I can do anything much here.

Tried the new build out today. Left a detailed route on the routeviewer for sometime and nothing happened. So I guess whatever you changed must have worked. Thanks 

Not sure about that, but still.....

(The change made *only* affects reloads)

Keeping the thing open I can't see would do anything at all. Can test that in a bit.

I must have spoken too soon because it happened again. Still using the current build. Is there a limited number of refreshes that the viewer can do? I didn't record it but I believe I must have refreshed the viewer at least 50 times.

This topic remember me when I tried to make a 400km route. I just have 4GB of RAM, and I think OpenBVE render the whole route with the proper limit distance of view where the other objects remain invisible but keeps there on memory.

But the surprise was the route use single objects for railway structure (no complex object structure library), when the train approach more to the end of the 400km. The consumption of RAM is less, looks like the game when is at the end of the route dispose objects. It will be a nice idea that in can work on both directions.

The problem still exist for me and the others in the latest version of OpenBVE(v1.7.1.8, and also tested nightly build). When reloading/unloading objects, the memory did not get freed. This happens in all Windows Operating System, no matter the size of the texture, Windows 7 or Windows 10. User who have higher VRAM would probably not notice on object viewer, but it is very visible when using RouteViewer. This is also the reason I am using v1.7.0.3 on Object Viewer and Route Viewer.

The main issue should now be hopefully be fixed from the current build onwards:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2020-08-17.zip

400km routes will likely work better with more recent versions of the sim (After 1.7.1.0) but it's not really been optimized for these.

Tried out objectviewer today but the errors still occur. It doesn't seem to crash but it does seem to unload even more textures with a single press of F5 than before. When all the textures of the model appear to unload it seems to try and load some textures back onto the model

SP1900 wrote:Tried out objectviewer today but the errors still occur. It doesn't seem to crash but it does seem to unload even more textures with a single press of F5 than before. When all the textures of the model appear to unload it seems to try and load some textures back onto the model

I can't reproduce at all. There was definitely an issue introduced with the new renderer, which has been fixed, but you must be seeing something different....

Loaded a random HK train with over 150mb of textures and tried refreshng a good 70 times.
GPU memory usage stayed constant at 26% and C# heap size went up all of 76kb


Can you share an object which triggers this for you so I can refresh a few times in the debugger and see what that does, as well as digging into the structure?

It could be a ram issue. It could be that Leezer has 16gb of 32gb ram and perhaps SP1900 has 8 or 12gb ram. That could also be a cause.

I have a low end 2gb ram Intel celeron n3350 and I have the same issue. But it could be a hardware issue thanks to alterations to the game or perhaps its something to do with the resolution of the textures. I myself experience the same issue but not as often as maybe other say which is odd

Whilst I've got 32gb this can't be the issue.

For legacy reasons, openBVE can't address more than 2gb of RAM & I'm monitoring exactly whats in use whilst testing.
It's got to be going somewhere, and the most likely cause I can think of at the minute is an object (likely animated) doing something that my test subject isn't, whether thats a texture shift or what I don't know at the minute. To rule that out, I need to test an object that causes this for someone else

Well the recent class 465 by SR BVE, by the looks of it SP1900's train he displayed and the class 350 funnily enough.

During the development the class 465 caused the problem to happen numerous times. It's not a particularly detailed model but during the building process it kept unloading its textures. 
The 465 can be found here: https://sites.google.com/view/sr-bve/downloads/trains

It also happened with this building object which I made for the Paris metro route currently in development: https://drive.google.com/file/d/1KtQOYf3-F_u2E3PpJ0_JkCmYTahPOfZZ/view?usp=sharing

My way of building is a pretty inefficient one; every modification I make like adding a new face or a new texture or positioning a vertex or a part of the model, I refresh, even if it's just one face or one vertex that needs positioning, every tiny modification I will press F5 to see whether I did it correctly or not. 

I'm not sure if it's just a viewing problem, maybe try making small modifications to an object or a train model and after each small change, refresh it. Sometimes if I come back after a short break the model will unload its textures after the first refresh. So could there be something in the background that causes it to happen?

This happens regardless of whether the new renderer or the old renderer is used

Still can't reproduce anything

I've tried reloading the 465 over 70 times, no difference.
Next test was to combine *everything from the 465 into a single file, delete most of it & then start adding back. No leak.
Also tried bouncing between about 20 different exteriors. Again no leaks.

Haven't got much in the way of ideas at the minute.

It may be different depending on the amount of memory and GPU, so why not write each verification environment?

I am verifying in the following environment:
OS: Windows 10 64bit
CPU: Intel Core i5-10210U
RAM: 8GB
GPU: Intel UHD Graphics
VRAM: 3.9GB
Viewer's resolution: 960x600

A similar issue has been raised on GitHub.
https://github.com/leezer3/OpenBVE/issues/507
I think we need to make sure that it is the same as the issue raised here.
Can you follow the issue steps to reproduce the issue with the latest nightly build?

With the latest nightly build, in my environment no memory leak occurs any of the steps.

Good thought.

Main dev box:
OS: Windows 10 64-bit
CPU: Ryzen 3600
RAM: 32gb
GPU: Nvidia 1060
VRAM: 6gb
Viewer Res: 800x600

Will try the laptop later (haven't tested the most recent build, but did test on it when first reported), which is the following:
OS: Windows 7 64-bit
CPU: i5-2520m
RAM: 12gb
GPU: Intel HD graphics
VRAM: 768mb (iirc)
Viewer Res: 800x600

Can also try a couple of VMs with Linux variants and possibly a Mac.

Here's what I use:

OS: Windows 10 64-bit
CPU: i5-7300HQ
RAM: 16GB
GPU: Intel HD Graphics 630 or NVIDIA GeForce GTX 1050
VRAM: 128mb (Intel Graphics), 1.97GB (GTX 1050)
Viewer res: 960 x 600

I don't generally track the build-up so it seems to happen at random. Noticed the person on GitHub used a very detailed train for their test. For me it happens even with objects as simple as a building found on a route. In my previous comment, I have attached a link to the said building that caused the error to happen. Still unsure whether it's the changes I make to the object rather than just pressing the refresh button a load of times. What if you make changes to the model before each time you press refresh. That's how I've managed to encounter the error. I don't have any problems when no changes are made to the model. At some point maybe try building a large object but after every small modification made e.g. adding a face or a texture, you refresh the viewer.

Sorry to bring up an old issue but it seems that this exact same problem has returned in the 12/11/21 nightly build

I still can't reproduce this properly.
Is it just leaking memory, or are you seeing the white issue above?

Animated GIF support was introduced in the 12/11 build, and I've found a leak when using these as a background texture, but it didn't fundamentally change anything else....

I've made a slight change which could help, but I'm shooting blindly here.
It's expected that the memory use won't go down immediately after hitting reload- This is just the way that the .Net GC works internally (It'll try and cache things- Try opening a route, closing the program and then re-opening it on a slow disk- You'll find it loads faster)

I have not checked for memory leaking but I have the same unloading texture problem and exact same error as described in the first post. The objects causing this do not use animated .gif textures at all.