[Lindsayts]

James Ross, on 09 April 2013 - 08:48 AM, said:

I'm not 100% sure, but I don't think we can do this directly from Visual Studio - at least not for the Express editions without the C++ compiler toolchain.

In general, though, there should be no side effects, but remember the configuration may not be supported by the CLR so there could always be issues. It can't hurt to try, anyway.

However, in this case, the VM is only getting up to ~1100MB so the likelihood of it making any difference here is slim.



Although we detect the VRAM, we make no use of this in our loading patterns currently. We load everything in the "tile space" (current tile and the 8 around it) and that's it.

There is nothing in OR (or should certainly not be!) that unloads/loads things based on viewing direction. If there is, it's a bug. That does make the video a little puzzling. I believe I have seen reports that ATI cards are more aggressive at unloading "unused" VRAM and are known to often have lots of stuttering when rotating the camera in open-world style games (I've personally seen it with World of Warcraft and it's pretty bad sometimes). While that may not be everything going on here, I'd suspect it of not helping.

If you haven't already, make sure you're on the latest graphics card drivers too, just in case. :p

Hmmmmmmmmmmmmmmmm........... , I will have to give this a test on both my systems. I have long had the feeling that the NVidia card (One system has a NVidia GTX560SOC the other a Radeon 5870) does a good deal better job on OR than the the 5870. As you mentioned "stuttering" is a major problem with the radeon. I will check this though, i have not run the NVidia system much recently as the fans in the case keep giving problems and have yet to fix this issue.

[jtr1962]

disc, on 08 April 2013 - 01:27 PM, said:

Hi

On some routes at very populated areas (lot of models and textures) i noticing continuous heavy stuttering in OR, while there is more than 1 gbytes of free ram available. It seems that if i turn the camera behind, the game unloads everything that can be seen at the front so when i turn back, it loads it again, and vice versa every time while i see that loading thread starts working too. While these happens the memory usage (according to the game's debug informations) is above 1100 mbytes, but never exceeds 1200mbytes. That's why it seems to mee, there is a limit at 1200mbytes, and the game unloads thinks when the camera turned away, to fit in this limit.

I have the same problem. Basically, the train moves in a jerky motion similar to a slideshow even though the HUD shows framerates in the 30s or 40s. I don't know how much this helps but I've been able to isolate what causes the problem. Whenever I notice this behavior one of the driving aids is on (usually the track monitor, but the other overlay type aids also cause it). If I turn all of the driving aids off, the behavior goes away. Interestingly, if I hit alt-enter to go into window mode, the problem goes away also, even with the driving aids still on. The HUD display, which is just text, doesn't cause this problem. Neither does any other info display which uses only text.

My system specs are Asus A85-F2A85-V PRO motherboard, A10-5800K APU (with built-in HD7660D graphics), 16 GB of DDR3-1600 RAM, Windows 7 Ultimate 64-bit O/S. I have the latest set of Catalyst drivers.

On a side note, I'm back into trainsimming after updating my system last year. My prior system couldn't run the latest releases of OR well so I took an extended hiatus from it. If there's anything I can do to resume helping the development team I would be glad to.

[Buttercup]

Log from CTD involving memory.

 OpenRailsLog.zip (5.33K)
Number of downloads: 225

[James Ross]

jtr1962, on 11 April 2013 - 09:31 PM, said:

Whenever I notice this behavior one of the driving aids is on (usually the track monitor, but the other overlay type aids also cause it). If I turn all of the driving aids off, the behavior goes away. Interestingly, if I hit alt-enter to go into window mode, the problem goes away also, even with the driving aids still on. The HUD display, which is just text, doesn't cause this problem. Neither does any other info display which uses only text.

Do you have the "Use glass on in-game windows" option enabled? There's a potential for that to cause issues like this, so try turning it off.

[Lindsayts]

I have just done some observations on the stuttering, The system is.....

MB ASUS P6X58D Premium
CPU i7 940
Ram 12 gig at default clock (1066mhz)
GPU Gigabyte Radeon HD 7870

The route was the Bernina Bahn.

I found the stuttering consistently started occuring above 3200 render primitives (at around 72fps). The amount of memory displayed or the number of objects loaded did not have anything like the same close relationship with the stuttering.

The highest number of render primtives was around 4800 this was at around 47fps, badly stuttering.

If one pointed the camera in a different direction where the scene was not as cluttered one would see the same amount of memory in use the same objects loaded but the render primitives would be way down and no stuttering.

The 2 gig of ram or the more powerfull GPU card (the previous card was a 5870) made not a bit of difference so one assumes its the render thread getting overloaded (its running at 99%). Would it be worthwhile considering splitting the terrain rendering (this would be the largest single item rendered) on to a different thread? Or in fact splitteing the rendering thread so 2 processor can be used (Note 1).

Note, While I have as yet to extensively test it an NVidia GTX 570 does similiarly stutter in the same places on this route, so it does not appear to a particular brand problem. I will put up the results of a test with that system in the next few days.

Note 1, If this is done one will have to watch the memory bus is not being overlaoded, this was a design problem of SMP systems pointed out as far back as the late 1980's, ie that in an SMP system it was possible for a single cpu to flood the memory bus.

Lindsay

[jtr1962]

James Ross, on 18 April 2013 - 12:58 PM, said:

Do you have the "Use glass on in-game windows" option enabled? There's a potential for that to cause issues like this, so try turning it off.

I tried it both ways with the same result. It doesn't happen all the time, just mainly in areas with dense scenery.

[ChrisD]

jtr1962, on 19 April 2013 - 01:39 AM, said:

I tried it both ways with the same result. It doesn't happen all the time, just mainly in areas with dense scenery.

I do not have the Bernina Bahn, but using a couple of other Routes, I have used GPU-Z to log the load on the graphics card.

My finding is, that when the stutter takes place, GPU load is 100% according to the GPU-Z Log.

Loader percentage goes up at these moments as well.

Trying out a less powerful Graphics Card, shows more instances of GPU-load at 100% according to GPU-Z.

I will try to make OR Log the Render, Update and loader percentages, to see if there is a coincidense with the GPU-Z log.

My keenest wish right now, is a more powerful Graphics Card with the new PCI-E 3.0 interface.

When we have nailed it down, we can ask the OR Team to look into this, but I think we need more knowledge about the nature of this problem.

Last but not least, this is beta code and there may be some debugging code built in, that increases load.

This will not be there in the release version.

I think OR has come a long way already, and I am sure that the OR Team wil take care of the problem in due time. :sign_thanks:

Happy Railroading.

ChrisD

[disc]

Lindsayts, on 18 April 2013 - 02:15 PM, said:

The 2 gig of ram or the more powerfull GPU card (the previous card was a 5870) made not a bit of difference so one assumes its the render thread getting overloaded (its running at 99%). Would it be worthwhile considering splitting the terrain rendering (this would be the largest single item rendered) on to a different thread? Or in fact splitteing the rendering thread so 2 processor can be used (Note 1).

overloaded render thread alone doesn't cause stuttering, but steady low fps.
By the way, it's not possible to split rendering thread to more threads, if it would then this problem wouldn't appear in every open world games :sign_thanks:
Same happens with TS2013 (for example i have there max 30 fps, while the gpu usage is at 50%, and it's caused by the same problem. Too many objects to be drawn, and the one cpu core is limiting the render thread), or in Arma series, Flight simulators, everywhere where is a big open world is rendered.
That's why an i7 is absolutely useless above i5 in games, and same applies on amd FX 8xxx vs 4xxx. Because of these limitation the open world games run better on fewer but faster cpu cores, than on more, but slower cores.
I heard directx 11 have support for multithreaded rendering, but isn't too good in reality. In directx9 which is used by OR, multithreaded rendering absolutely not supported.
The number of the draw calls, and so the overload of render thread could be lowered mostly by the route editors and the object modelers by making routes and models by considering that each individual nodes need a seperate draw call, so use 1 material for one objects, and combine objects and materials as it's possible (for example if you want to place a forest, use one single forest object instead of many seperate tree objects.
Another thing that can make it better, is draw call batching by the 3d engine, but that's not a simple task, and it have it's limitations.

Bernina bahn is the worst example if we look at the draw call efficiency. On some parts i even see 9000 render primitives, which is extremely high.

This is why every route editors, and 3d modelers should read this: http://wiki.uktrains...n?pageId=426074

(PCI express is 3.0 has nothing to do with performance, it's a marketing BS. In reality, even the fastest dual gpu video cards are VERY far from reaching the limits of 2.0...)

[PA1930]

Hello everyone.
I didn't want to create a different topic as I'm thinking this question could be posted here.
Truth to be said, I don't understand so much about computers and graphic cards even less...
So I'd like to ask the following question that I'm guessing it could be posted here:
Is it possible that, on my computer, MSTS seams to run fine on a very decorated route, while on Open Rails it barely moves? I use MSTS with the "-mem:1024" option and it seams to be a good thing for my current PC. I am aware it is not the best PC (its even a laptop, I'm guessing it sort of makes things worse... From what I can tell, my PC's processor is an Intel Core 2 Duo with 2.4Ghz, and I have 3GB of RAM memory. The graphics card should be an "Mobile Intel 965 Express Chipset Family". I was told it is nothing so special, but I somehow have had TS 2013 working a bit faster than Open Rails (don't ask me how... I have had the graphics in the minimum quality).
Though is it normal for OR to be slower than MSTS? I was always told that OR should work faster than MSTS...