FPS Cost of different object and settings?

Ok, so I go mad sometimes building missions and then a few days later I'm pulling what hair I have left out of my bald head trying to figure out where all my FPS went!?

I spent about 2 hours yesterday playing with my graphics settings before I decided to make a baseline mission(just a mission with one aircraft taking off of the airfield I was using. Nothing else.. And of course my FPS were good. So, it's my mission!! What did I do?...

After some testing.. copying the mission, and changing the clouds, wind, ToD, I started deleting Static Objects and Fire/Smoke Effects. All this helped a 'little'. But once I started deleting some AI moving ground/air objects I got more significant improvements. And then AI Ships...

So, I'm wondering if anyone had done any testing of what the FPS COST is of different objects/settings? And how do you manage the FPS? Do you 'spawn' in new ground objects with Triggers when certain enemies get destroyed?

What's your method of keeping a mission FPS playable? :music_whistling:

I guess the first question would be about your particular system specs in relation to the number of units you're running. Your system is clearly very capable with loads of RAM and a great graphics card.

I recall back in the older days that smoke used to crush FPS no matter what card you had so if you had a lot of units getting blown up things would really slow down. I think they fixed that somewhat... but it's been awhile.

I would certainly look at late activating units if they're not needed throughout... Large groups of AI pathfinding are sure to bog down processes especially if your system is older- which it isn't in your case but if you're talking hundreds of units it may still factor into it.

If you're using static objects- particularly aircraft I'd recommend using the lower detail models where you're able to... for example on my carriers I use the high detail model for those aircraft that are front and center but those in the background I use lower detail models.

But yes- to answer your question specifically where possible I'd definitely late activate units based on triggers set on previous units being either destroyed or at least partly destroyed (ie: 4 of 5 vehicles destroyed- for example.) I can't remember the condition off the top of my head but I think "Group Alive Less Than" would work so a random vehicle doesn't go into hiding under a tree and stall out the rest of your mission.

Thanks for the reply ENO.

I have about 9 enemy columns with about 10 vehicles each on the roads. And about 15 tanks in a battle on each side, so about 30 in all. And about 4 enemy flights of 2 and the same friendly flights. Also had a carrier group.

I deleted about 6 of the enemy ground columns and 3 of the flights. And the carrier group and went from ~15fps to ~35fps.

I also tried deleting the 6 Fire/Smoke effects that I had in the city and that didn't help much.

How do you tell which Static Models are lower detail? Just by looking at them? Or is there some other way?

Well frankly I don’t know if they’ll make that much of a difference- the high res aircraft are the ones available as modules- but it doesn’t sound like that’s where your problem lies.

90 vehicles in columns on roads following waypoints while 30 tanks duke it out is, as you already know, probably a big part of the issue. I wouldn’t delete the content outright but would see if it’s practical to late activate them.

Additionally sometimes you can create a cacophony using fewer vehicles and making them invincible for a certain amount of time... then use a trigger to turn off invincibility... if you just want to create a scene then sometimes there are ways to put some AA guns down and have them fire at points on the ground. Unfortunately I can’t remember how I did that originally but wow it was awesome. I’ll need to figure that out again.

I guess the real question though- what are you trying to achieve? I shouldn’t be offering solutions if I don’t even know your objective. So what’s the goal?

For large missions, turning off AI for ground units until they are relevant can help you out. Use PART OF COALITION IN ZONE or UNIT INSIDE ZONE to detect when players enter the area.

Generally speaking =

Nothing -> static object -> stationary live AI -> live AI with routes.

Ground units with lengthy routes are especially costly.

To reduce CPU load, I try to turn off stuff that is transparent to the player/observer like Fee suggests. For example, turn off ground unit AI and explosions when players are outside the observable battle zone. Also late activate air units until actually relevant to the mission scenario. Another good tip is to place one unit of each late-activated type at some remote location on the map and set it to uncontrolled or no fuel. This loads the object into memory at mission start and prevents a graphics stutter when the group type is first activated.

You can also "simulate" action beyond the player's visual observation to save CPU cycles. for example, instead of programing an AI SEAD flight, simulate the SEAD event by scheduling voice files and SAM unit explosions/destructions.

To reduce CPU load, I try to turn off stuff that is transparent to the player/observer like Fee suggests. For example, turn off ground unit AI and explosions when players are outside the observable battle zone. Also late activate air units until actually relevant to the mission scenario. Another good tip is to place one unit of each late-activated type at some remote location on the map and set it to uncontrolled or no fuel. This loads the object into memory at mission start and prevents a graphics stutter when the group type is first activated.

 

 

You can also "simulate" action beyond the player's visual observation to save CPU cycles. for example, instead of programing an AI SEAD flight, simulate the SEAD event by scheduling voice files and SAM unit explosions/destructions.

Love these ideas. Habu I remember you made one of my favourite missions of all time...

Thanks for the great suggestions.

Do any of you have a sample mission that shows how to do these things? I know how to do some of them. And I am sure with some research I can figure out the rest. But a good sample is always a great place to start learning.

Cheers!

What feefifofum said. Bearing in mind you cannot quantify this on a FPS basis, there's too many variables, so you test.

Statics are "cost free". This is your lettuce and salad, textures are minimal.

Unit count is significant but vastly depends on what the units are doing and especially what they are "detecting" in terms of the two coalitions and their detection methods. At various times there have also been performance bugs on specific unit types.

Radar units detect a lot and it's a multiplicative effect of radar versus all the things it can possibly 'see', multiplied by the amount of radars. There's more than radars, there is RWR, IRST, visual, IR detection methods, but you get the drift, each unit detects each other unit via one or more sensors.

AI actions build on top of the unit count to multiply again. If the AI is something that will take action and perform an AI routine such as an engagement, then it can have a huge effect. Plane combat happily adds "20%" of your CPU right from the off. Set a 4 vs 4 combat with missiles flying and watch the CPU. it's hefty CPU usage.

Moving units comes in two parts of CPU thievery. Part 1 is route calculation if it is given in realtime by a player or a script, ie, the route calculation occurred mid mission. The loinger the route, the more the burst processing. Not as bad as it used to be, but click a road route running across Caucasus and watch the delay. Part2 is a server side movement sending the network traffic or updating the units positions. This can have a greater bearing with Exports turned on such as Tacview.

On servers there is added network for all these actions down to Network throughput which increases per client. Thus a lot of things moving is multiplied by the clients connected. Each client has to be informed of each unit, right? I never tested that moving and not moving per client is a different effect, it's possible, depending on the network code, but i'm not inclined to test it. It certainly melts servers when many move at once, that is for sure.

Finally don't underestimate the clients added FPS loss from the module and terrain processing. yes it is irrelevant to mission design, but its adde don after, so it needs to be considered. Both graphics and pure CPU are involved together, but it's a significant amount. Things like loading textures on slow disk, new textures arriving, smoke and explosions are pretty costly, depending on the client spec. Some modules are very cheap on CPU. I usually test with a TF51. I wouldn't want to load in with an F-14 to test a mission, for sure.

You can see a lot of Server versus client CPU differences fairly instantly by switching the FPS on and swapping from F10 map to cockpit. Where did my 120FPS go?

You can save some CPU by creating a DS on another core. It will eventually settle down to 600MB memory or so, but takes some time. Running that will remove the client FPS/CPU effect from the game engine on the same thread. It's also more stable. That way you will use just local network updates ontop of your client cockpit CPU which is much less than the AI when it kicks off.

The texture loading is fixed now, you can see textures from units being preloaded in the dcs.log and the burst of a new client texture or missile or spawn is greatly reduced. ED should have celebrated that optimisation harder but they didn't for some reason, it's only understood by very few people on the forums.

Turning AI on and off is all well and good but it's not a solution that works universally. IF you have a bunch of units in a very localised place and theres no expectations of a player seeing them, i'd ask why they were there anyway. If the player is due to see them in time, then he;ll get whatever AI CPU burst was due to him arriving when he is overhead, so there's no benefit and he had best be prepared. If you have TWO or more such areas and there are multiple players with no particular agenda (ie sandbox), I'd say you were building up a shitstorm, because if it's worth turning off one set of AI then how would you cope with two or more anyway? This is a single player only optimisation mostly and works best there.

For multiplayer people often refer to the "AI Bubble" as in, what other games do when the player is not looking (smoke and mirrors). It's not suited for DCS where we have no easy way to allow limited AI battles to be emulated (ie 5 tanks versus 5 is emulated but not simulated) It's possible, but is so complex to bother with. For an MP bubble, you will need to process each players position and stop AI beyond it, which is quite possible until you think of the vast ranges optical and radar and other systems work in. You cannot simply disable AI planes at 100nm because you can still see them. For ground units only you can still detect sams by RWR for 100nm+. Then how do you deal with other AI planes crossing these bubbles? Or datalinks? You pretty quickly arrive at the position you will need to emulate interactions between simulated actions - No. You can't emulate half of the ground units that have no radars and not the ones that do. Or you have 100nm bubbles around players all moving around a 400nm map? It's not a scalable solution and only works if the player and AI movement is tightly controlled or prohibited in certain places.

To reduce CPU load, I try to turn off stuff that is transparent to the player/observer like Fee suggests. For example, turn off ground unit AI and explosions when players are outside the observable battle zone. Also late activate air units until actually relevant to the mission scenario. Another good tip is to place one unit of each late-activated type at some remote location on the map and set it to uncontrolled or no fuel. This loads the object into memory at mission start and prevents a graphics stutter when the group type is first activated.

 

 

You can also "simulate" action beyond the player's visual observation to save CPU cycles. for example, instead of programing an AI SEAD flight, simulate the SEAD event by scheduling voice files and SAM unit explosions/destructions.