AI traffic framerates?

sniper297

Coconut God
What's the secret to getting AI traffic that doesn't tank the framerates?

74456820.jpg


43836723.jpg


The only difference between these two scenes is that in the second one, somewhere out of sight a bunch of AI trains are running. I understand that processing the instructions and movement of AI traffic in the background is going to use CPU cycles and memory, but THAT much of a performance hit?! Is it better to add many many more portals and have the AI trains running shorter distances, or reduce the number of portals spawning AI trains and have them run back and forth or around in circles for longer time periods? Anyone done a study on performance issues for AI trains? Longer shorter slower faster, or is the only way to set up complicated triggers that only spawn trains when the player is nearby?
 
If your framerate is affected by AI trains it,s simply down to the number of AI trains running around at the same time. You could reduce the number of AI trains by increasing the portal emergence time or you could go into options to increase your performance by reducing the draw distance and graphics and seeing if that helps. I think thats the 2 easiest options you could try.
 
Last edited:
On my dualcore 2.4ghz, 4gb memory system the bottleneck is CPU cycles with normal activity, not heavy AI. My video memory in my nVidia 240 512mb video card runs only around 375 mb used with 45% to 50% GPU usage. Thus the CPU 75% leaves little headroom.

Once you reach the aggregate 75% CPU area you are effectively entering a zone where competition from the various queues and their processing becomes and issue. Direct Memory Access (DMA) is probably being hammered. I have not kept up with the harware versus software architecture but it seems to me that despite the alleged multiple channels of DMA there may be some degraded performance above 75% of overall CPU. Then you get what is possibly the real issue is that one core is carrying more load than the other so that at 75% overall may be 85%, or more, in one core. Obviously that is a problem.

Trainz probably does not offload as much of the video pre-processing to the GPU on the video card as the unmentionable product. There frame-rates are not outstanding but the GPU is maxed with moderate CPU usage. The opposite of Trainz.

Using Kentucky-III, with possibly up to 150 objects in view at once, I have to limit viewing to 1500M for smooth performance running a single AI. Other sliders are at max.
 
Yeah, that's what I mean - in both screenshots the quality sliders are all turned down to "YUCK!" with the visibility at 2000 meters. In the second screenshot there are no other trains visible, in fact no AI trains within a 2000 meter radius, so they shouldn't have that much of an impact. The "unmentionable product" can't run enough AI trains to actually test something like this, but I did have as many as 35 running at a time in MSTS. Before BIN MSTS used to throw out zillions of "failed to create SMS object" errors if you ran for over an hour without saving and reloading, because it didn't do a very good job of releasing RAM either, but it didn't affect the framerates THAT much.

Back to the drawing board I suspect, gonna try really short paths with lots of spawn and destination portals, and really long winding paths, see if there's a difference. It's always something, can never get really GOOD AI traffic without some kind of compromises. :'(
 
A long, long time ago when I made the sessions for a route that involved many AI trains, I adopted the theory that any AI traffic the user could not see from his/her train was a waste. I tried to use sidings and portals to remove, and if not remove, then halt the AI traffic ASAP after interacting with the user. I continue to use this method and it serves me well.
 
Yeah, that's the last resort, finding some kind of tutorial on CPC Emit Train on Trigger Thingamajigger. Trouble is I got five lines here, two double track, two quad track, one triple track, and with the "freestyle" activity theme there's no way to know where the player will be when, or even which loco he'll be driving. So even if I can figure out how to make the triggers work I'll need a bucket full of them.
 
with the "freestyle" activity theme there's no way to know where the player will be when, or even which loco he'll be driving. So even if I can figure out how to make the triggers work I'll need a bucket full of them.

I understand. The sessions I made were fairly straight forward and I was able to run each one ad nauseum until I had the timing correct. I was so sick of the route after that nightmare, I rarely played it again.
 
One of the things I've done when there are lots of AI drivers in the area, is to slow down the speed of the trains. This has helped quite a bit with the performance.

Most of the time, in urban areas, the trains will be running slower anyway due to yards and junctions. With the trains running slower, the computer has a chance to process the information without pushing the CPU too hard at once. This gives the program, and the hardware a chance to clear the queues as they fill up.

The other thing that helps too is to stagger the running of the AI even by a few seconds. This keeps the AI queues from fill up too much at once. This method is particularly helpful at start-up when all the AI drivers want to run all at once from the start.

John
 
The other thing that helps too is to stagger the running of the AI even by a few seconds. This keeps the AI queues from fill up too much at once. This method is particularly helpful at start-up when all the AI drivers want to run all at once from the start.

John

Yes, I remember using many "Wait For" commands...
 
Hello to all,

I have noticed on my current system, that running AI trains from one point to another is great, but the main problem is when a train is emited from a portal, then I get a slight stuttering and a performance hit, no matter were I am on the map, and I also see the egg timer appear in place of the arrow.

The thing is, the smaller the train being emited from the portal, the less stutter appears.

I have also noticed, that when I am driving a train, and I am approaching an AI train coming towards me in the opposite direction, then I get a slight stutter before the train comes into sight and also as it passes.

The above is what I have experienced on a low to mid machine, however, I am getting a new up to date and improved system next week, so I will let you know how I get on with that.

At the bottom of my post is my current system specs...

Hope the above helps

Joe Airtime
 
Last edited:
IIRC TPR's Scenario system used to keep track of non-visible AI traffic out-of-game, leaving only visible traffic to bog down the system. It never got used a lot because compared to a session it was pretty complex to set up and I may be wrong, but pretty sure their system got broken by The Company around TS09.

Proves it can be done though, and it might be worth scratching around TPR because I think I recall someone working on getting it un-broken...

Andy ;)
 
Yet another rule added to too many rules already, but if it works - and most importantly if it was uploaded to the DLS so nobody had to hunt for it - then it might be worth the trouble. No solution for moving AI trains yet, but the loose consist problem has a solution now;

http://forums.auran.com/trainz/showpost.php?p=833967&postcount=13

Irritating part is that wulf9 wrote the original "sleep" script for TRS2004. Which means this problem existed long before I stumbled over it, why haven't the developers done something by now? It runs okay on nuclear powered turbocharged Alienware so no need to do more efficient coding?
 
I wonder if the size of the AI train is the issue. How much juice is allocated to 50 cars versus 5 multiplied by the number of on-track AI trains. Some of these programs also spend resources on "pending" AI things so they can smooth out the jump in resource usage when an AI actually appears.

In Flight Simulator even invisible AI is a big hit.
 
Back
Top