Hey Piotr,
I've been having problems with the two most recent builds of TSRE. With both versions, the performance has dropped significantly since 6958, which is what I've stuck with. I have one scene I'm working on, with only 800 objects in the tile. With TSRE 6958, the scene uses about 400 megs of physical memory. If I load the same scene with TSRE 6970 or 6971, the physical memory jumps to about 8 Gigabytes and the tool becomes almost unusable. You can't move around the scene, as it seems to be stuck loading constantly. It's almost like there is some kind of runaway process or memory leak. Maybe there is a pre-requisite file I need which I don't have?
Any ideas?
Cheers,
Jason
Perfomrance issues with version 6970 and 6971
I am using v0.697 and have my route loaded. I am on a tile with 5594 objects on it. I have looked at "Task Manager" and it says that TSRE is using 26% of CPU and 222MB of memory.
Google Chrome is using 511MB of memory.
I am not sure if this is the way to assess resource usage. I can say that my computer is quite old, I recently got a new Graphics Card GT1030 but the rest of it must be 8 to 10 years old, it was not "top of the range" even then, CPU i5-2320 3GHz
Garry
Google Chrome is using 511MB of memory.
I am not sure if this is the way to assess resource usage. I can say that my computer is quite old, I recently got a new Graphics Card GT1030 but the rest of it must be 8 to 10 years old, it was not "top of the range" even then, CPU i5-2320 3GHz
Garry
Yes, it sounds like a memory leak. Check TSRE version 0.6963:
http://www.elvastower.com/forums/index. ... v06963exe/
Warning: installation method for this version is different.
Try to find what is causing memory leak. Try using other routes, remove .w files etc.
Hi Pitor,
It seems to be most apparent on the routes with dense forest objects. The whole application grinds to a halt while It tries to load the contents of the tile. While a given tile might only be 800 objects, it would contain dense forest objects. One the routes I have which have little to no forest objects, performance or memory consumption isn't an issue. I'm no programming expert, but is there any chance the rendering of the forest objects isn't being instanced and instead hogging memory? See attached image.
Thanks,
Jason
It seems to be most apparent on the routes with dense forest objects. The whole application grinds to a halt while It tries to load the contents of the tile. While a given tile might only be 800 objects, it would contain dense forest objects. One the routes I have which have little to no forest objects, performance or memory consumption isn't an issue. I'm no programming expert, but is there any chance the rendering of the forest objects isn't being instanced and instead hogging memory? See attached image.
- TSRE_memory.png (2.68 MiB) Viewed 9982 times
Jason
I made a dense forest but don't see anything wrong.
Could you send me the route with this bug?
Could you send me the route with this bug?
Hi Piotr,
I've sent you an email to your GMAIL address with a download link. The route i sent actually has few forest objects, and it has the same issue as one other I am developing. TSRE loads an enormous amount of data to memory, and it just keeps increasing to the point where the editor becomes unusable.
Cheers,
Jason
I've sent you an email to your GMAIL address with a download link. The route i sent actually has few forest objects, and it has the same issue as one other I am developing. TSRE loads an enormous amount of data to memory, and it just keeps increasing to the point where the editor becomes unusable.
Cheers,
Jason
Good news. I can confirm that there is a critical bug.
I will try to fix it as soon as possible.
I will try to fix it as soon as possible.
Ok. I know what is causing this bug.
1. Open Rails uses .dds textures if they exist even if shape file or terrain file requires .ace texture.
2. I've implemented this feature in TSRE long time ago.
3. Some months ago I noticed that TSRE always load new .dds texture for each request instead of using already loaded texture because requested texture was .ace but loaded was .dds. It caused huge memory usage.
4. So, I fixed this problem in TSRE 0.696 by renaming texture ID name after loading it first time from .dds to .ace. This solved the bug, because next request could use texture already existing in memory.
5. But there is a problem with your route now. You are using .dds file names directly in terrain files. I didn't know that this solution was possible in Open Rails. Now with each texture request, TSRE is loading new .dds texture because it can't find texture ID with .dds extension, because it is always replaced to .ace after first request. So, it cause huge memory usage, because terrain has 256 patches and it means 256 texture loads for each tile.
I will try to fix it as soon as possible.
1. Open Rails uses .dds textures if they exist even if shape file or terrain file requires .ace texture.
2. I've implemented this feature in TSRE long time ago.
3. Some months ago I noticed that TSRE always load new .dds texture for each request instead of using already loaded texture because requested texture was .ace but loaded was .dds. It caused huge memory usage.
4. So, I fixed this problem in TSRE 0.696 by renaming texture ID name after loading it first time from .dds to .ace. This solved the bug, because next request could use texture already existing in memory.
5. But there is a problem with your route now. You are using .dds file names directly in terrain files. I didn't know that this solution was possible in Open Rails. Now with each texture request, TSRE is loading new .dds texture because it can't find texture ID with .dds extension, because it is always replaced to .ace after first request. So, it cause huge memory usage, because terrain has 256 patches and it means 256 texture loads for each tile.
I will try to fix it as soon as possible.