Model data to judge ingame performance

[.kju 3245]

An easy one for you guys.

Lets say you make a MOD.

A MOD that is meant for large scale combat with MANY units.

One needs to look a little more in detail into models we agree.

So what information would be useful to now?

P3D

* Size (in bytes)

* Number of LODs

* Number of faces of each LOD (overall face number)

* Model in ODOL format available?

* Shadow LOD details (which`?)

* Geometry LOD details?

Textures:

* Number of textures, resolutions, size of each (in bytes) and total size

* Same for normal maps

What else?

Any other ideas to judge models in terms of performance?

Sincere thanks!

best regards

Q

PS: Scripts don't count. Those would be removed / changed /

optimized anyway.

[armatech 8]

Well you missed one biggie in your list and that's correctly Making the UV maps so that it would not cause St errors in the rpt.

This is the most common issue most  modders do and that's basically from my understanding when a texture is added to a face that has such a small surface that's the Texture cant find where it actually needs to go say for example you have created a box and you open your texture in the UV map editor then you just past the box over your texture with out unwrapping it at all this will cause an ST error and on a dedicated/MP server this will start to cause performance issue for both server and client.

Just my 2 cents

Maybe ST = stretch

[Romolus 0]

Phew, that's one big thing to ask and not really easy to answer

For a whole mod and if you're serious about pushing the boundaries, I doubt that you'll get away with such a simple set of numbers. What you need is some idea of what the engine is capable of in the area that you're interested in. And I fear you only get that by testing it yourself since it doesn't sound like you're content with how things are in ArmA. Therefor also looking at the standard values of ArmA units and terrain won't help much.

Rigging up sample models like spheres or boxes with different polygon counts, number of textures and texture-sizes is easy and quick to do. (Also don't forget the terrain and its objects.) With those you can put together simple missions or scenes like the ones you imagine for your mod and get an idea of how the performance will be.

Every other way to come up with such numbers is pure guesswork in my opinion and you might end up with bad performance anyway if you put it all together in the end, despite the more rigorous checking.

Maybe the engine gets much more taxed by the increased number of units than you would expect and you therefor might have to reduce the taxing in other areas also more than expected. Some things might not tax the engine that much more if used in higher numbers and therefor might not really need to be scaled like others.

A game engine is a complex system of many factors and I wouldn't expect those factors to behave linear in any situation. So testing is the only way to find out how those factors behave for the situation you like to have.

What you need to test the right things is some basic understanding how things work or might work in the engine and the hardware.

What are the different things that the GPU gets fed with and how does it deal with those things? How are the current types of GPUs different in those aspects?

How does the parts you know from the game assets translate into the things that the GPU gets fed with?

This might all sound a bit complicated and maybe a bit too much for just making a mod, but I think that's the only way to get meaningful numbers with the precision that you seem to aim for.

If you don't want to go down that road, I'd say just making sure that a model is generally done well and then doing your tests with the finished model is better than trying to come up with numbers for poly counts and LOD numbers by guesswork that might or might not fit what you want to do.

[Synide 0]

Probably the most significant one would be Sections.

Most likely equivalent terminology for a 'Section' is a 'Drawcall'.

The Biki's definition is a little bland and generalistic.

-> BIS Developer to Insert Verbatim Definition Here <-

Possibly a 'good' method of analyzing the 'performance' of ones own created models would be to insert your 'vehicle' into a specific spot on a map, have it perform a specific thing. Monitor the results using 3D Ripper DX.

Modify your model, retest in the exact same manner as previous test.

What your probably looking most at is Drawcalls.

[.kju 3245]

Thanks a lot to you for your answers so far!

We don't need perfectly precise and exact data here.

Its more about relation. And we have BI ArmA's models as a reference.

So its not such a theoretical question.

More how to aid / support the ingame testing in a simple way.

We are not looking for hard facts, more for indicators.

See the quote for our problems:

Quote[/b] ]I tested out Johnny's Marines last night briefly. While they look good, I believe that they have crap performance compared to other models. I set up a USMC platoon in formation (roughly 40 people) and when looking at the platoon, on a high-end system, 4-8 of the units at the edges of the formation (furthest away) were rendering in the absolute lowest infantry LOD. My framerate was down to 10-15 as well, on Rahmadi, where I would normally get a great framerate.

I have never seen that kind of LOD behavior in ArmA before - I've done the same thing in the past with Hepcat's Marines, and the framerate and LOD was just fine.

Anyone else see this issue?

I recall that the mindset with WGL was to provide things that worked, looked basically correct, but weren't bogged down with unnecessary detail. I would like to see that continue with ACE if at all possible. Johnny's Marines seem to fall onto the side of too much detail at the sake of performance.

[Romolus 0]

I'm afraid, but I think there is no easy way to do this.

For testing, the first thing you have to do is to get familiar to your variables. What I mean by that is that in a game engine there is so much going on, that isn't really apparent by just looking at the screen. So you'll have a hard time doing any meaningful testing at all when you don't know what's going on behind what you see on screen and how you can adjust it.

Testing is worthless in an environment where you don't know the variables.

There is no shortcut or easy way to this.

What you see on screen is a result of a cycle that basically goes like this:

The engine determines what needs to be shown and how, then the engine feeds the GPU with the data it needs to display exactly that. The GPU then tries to render what it gets from the engine. This happens with every frame and the engine takes note about how many frames per second are rendered and adjusts the data it sends to the GPU so that the fps stays in an area that is acceptable for the game.

Now the first thing to understand in this is what kind of things affect how fast the GPU can render somehting. At this stage there are many variables that aren't really apparent from what you see at the screen in ArmA. You get a glimpse of those if you look at the performance analysis tools from nVidia and AMD (nVidia PerfHUD and AMD GPU PerfStudio). Just look at some screenshots of those and you'll see what I mean.

If you have an idea what the numbers mean in those performance analysis tools, then you'll also get a pretty good idea about the reason why some models give you problems on the GPU end.

Then you'll have to know how the data that gets sent to the GPU translates into the game assets that you know, like models, textures and all that. Only then you'll be able to tell what you need to adjust on a specific model to make it work well in your mod.

Maybe your performance analysis tool shows that the GPU is sitting there idle, while you still get bad framerates. Then you'll know that the GPU end is fine and you'll have to look how the engine is dealing with your model. Maybe the amount of AI is keeping the CPU busy and it's therefor not able to send all the data to the GPU in time to ensure a good framerate.

There is just too much different things going on that you'll have a really hard time to get a proper idea of where the problem is only by throwing random models at the engine and seeing how things look at the screen.

The same thing goes for the rest of the mod. It's no use to test in a standard ArmA environment if the idea is to replace every ArmA model including the landscape with your own ones.

Maybe the ArmA terrain taxes the engine and the GPU in a specific way and your own terrain does that different. You'll end up getting different performance when you'll test the same units on your terrain than on ArmA terrain.

The GPU doesn't really care whether those polygons or shaders are from the terrain or some fancy unit. All it knows is that huge pile of data that somehow needs to be put through the pipeline to get rendered.

If your terrain has a different terrain or texture grid, how the models and the textures of your terrain objects differ from the ArmA ones, how the density of the terrain objects differs from the ArmA ones, all that affects performance.

You need a proper testing environment that closely resembles what your aiming for in your final mod in terms of how the engine and the GPU manages it. Otherwise your testing is flawed right from the beginning and doesn't return any meaningful results.

You can't even judge how different your environment will be if you don't know the details of how things affect the engine and the GPU. You won't have any basis for the most simple judgment.

[.kju 3245]

Very true Romolus.

For the big picture we have dedicated testers to tell us their

experience from play testing.

Yet I still believe it could help to have a basic set of values to

look at for a first impression in terms of models.

Of course you need to keep in mind how often this unit is used.

Yet if we talk about the standard infantry models, that one is

probably used most often.

Like we could say we use at max common units that use 1.5

times the resources of the standard ArmA soldier. Or do you

think thats not a reasonable approach?

So we could also turn around the question:

Lets say the system used for this tests can be seen our basic

goal to work with.

Quote[/b] ]How comes that the Johnny's Marines have so bad

performance on his system even with just a few units on the

field - no scripts, no nothing going on?

What is the reason here? It must be found in the model and its

texture use. Right?

[raedor 8]

Probably the most significant one would be Sections.

That's correct.

[Synide 0]

Ok Q, yeah I see what you're getting at... As mentioned, probably you're best/easiest thing to do is just keep an eye on the Number of Sections.

Why, because it 'represents' the 'body of work' that the engine is going to do trying to render the 'thing'.

If you keep your number of sections as low as you can you'll be pretty much doing as much as you can to have optimal performance.

Here's an example. Say you have a square box. There is a round glass port hole in each side and you've decided to be whizzy and have each have different transparent texture & material. So you've got say one texture + material for the steel frame of the box and say 4 different transparent glass textures & materials.

With the above you'd probably end up with say 5-6 Sections.

This would be BAD.

Why, because a 'section' represents a 'body of work' in the context of ArmA and in this case if there are 20 of these boxs, 10 soldiers, some buildings and trees the 'total work' would be the sum of ALL drawcalls/sections that need to be rendered.

To try an make the situation better you have to reduce what represents 'WORK' in ArmA. In this case your model.

Lets say you get your No of Sections for your box down to 2.

The only way you could have achieved that is by saying oh well, bugger I'll just have 1 glass material for all 4 port holes and 1 material for the steel casing. You've still got a box that looks pretty good and it's performance is a number of times better.

Of course you've gotta keep in mind that what defines a 'Section'/'Drawcall'/'Body of Work' is not fully known to the community as it's sort of loosly defined.

But, suffice it to say that the bits you have control over are...

How many texels your model has.

Are the texels optimal.

How many Sections does your model have.

 - Basic rule of thumb for a section is 1 texture = 1 section. But that can increase in certain situations to 2 or 3 sections for a particular texure.

To summarize, if you just aim for keeping No of Sections down and still enough quality to make you happy, then you've probably done as much as you can to produce optimal models.

[norsu 180]

Will binarizing models increase their performance, or just reduce loading times?

I have similar performance problems in my soldiers like in Johny's Marines Q posted about. My soldiers have lower polycounts, lower amount of selections and slightly modified BIS lods. Texture sizes and numbers are also on par with BIS soldiers. Still my soldiers give worse performance when used in greater numbers - up to 10 fps decrease when I have eight men squad passing by my view.

I haven't binarized them yet so is that the trouble maker?

[raedor 8]

From what I know -- and I don't know too much, I'm coder -- bin does only shorten the loading time. But via binarize you can also find bugs in the model...

[Synide 0]

Binarize does basically 3 things...

1. It makes the actual file smaller... so better for distribution.

2. By processing the p3dm to odol it should highlight possible areas that may trouble the engine while rendering your model.

3. The data in the odol model is in a easier form for the engine/shader code to pump it through the pipeline.

[.kju 3245]

Thanks again!

The topic gets more and more interesting:

CameronMcDonald

Quote[/b] ]I'm totally confused. I'm working on some troop models, most of which are lower poly (some ~1000 faces) than the BIS standard troops, with basically very similar LODs, and they use less textures (most use 1 2048x2048 colour and similar _AS and _NOHQs).

Yet, ingame they are way way way way less efficient FPS-wise than the standard BIS models, despite all the above characteristics, especially when in ODOL format.

Why? What am I doing wrong?

EDIT - Plus they use the standard BIS model as a base. Damnation!

source

[Romolus 0]

I have similar performance problems in my soldiers like in Johny's Marines Q posted about. My soldiers have lower polycounts, lower amount of selections and slightly modified BIS lods. Texture sizes and numbers are also on par with BIS soldiers. Still my soldiers give worse performance when used in greater numbers - up to 10 fps decrease when I have eight men squad passing by my view.

See, that's what I mean. Without analyzing what's going on behind the screen, it's hard to say what's happening, even if you kept close to the numbers. That's because those numbers aren't absolute, but by simply applying them as rules, you treat them as such.

Having guidelines for how to reduce the "section" count is fine for optimizing a model, but how does that give you guidelines to decided whether a certain model will fit well in a whole mod?

If a model has a "section" count that's +50% of a regular model, but because of what it displays can't be modeled without an increased "section" count, do you include it in the mod or not?

How do you know what kind of headroom you have in terms of that "section" count?

Do you even know if something else also affects the maximum number of possible "sections" before framerates go down?

How is the trade-off between let's say texture size, polygon count and section count?

Is it better to have a bigger texture or more polygons instead of more sections? How do the numbers work out for such trade-offs?

How many polygons, textures and "sections" are already used by your landscape?

All those numbers are just general guidelines that help you to produce good models, but they don't really help you to judge whether a specific model fits well in your mod or not and they won't help you much with troubleshooting either.

[norsu 180]

I know those numbers aren't absolute. But if BIS used them then they are standard. And I'm running my units on plains of Rahmadi, certainly not too demanding scenery. Maybe someone from BIS knows how to optimize models right for ArmA .

[CameronMcDonald 146]

Yeah, someone should ask Suma if he has any tricks up his sleeves.

[norsu 180]

I asked Suma about this. And while awaiting answer I dediced to look at my model again. I found something interesting that had notable effect on FPS.

BIS' reference MLOD model BISoldier.p3d has only one shadow lod (ShadowVolume 0.000) but all MLOD character models provided by Synide have four shadow lods. These are:

ShadowVolume 0.000 (detailed lod)

ShadowVolume 10.000 (simple lod)

ShadowVolume 1000.000 (same as 0.000)

ShadowVolume 1010.000 (same as 10.000)

I added these to my soldiers and ran a little comparison test. This time my soldiers ran as expected - better than BIS' soldiers.

EDIT: Well it was too early to celebrate . This only helped for small amounts of soldiers. With 32 soldiers on screen the FPS difference was still very steep, 45 vs 71 .

[.kju 3245]

This is very much related to the topic here:

How to fix/merge sections in parts from old models, IE when using old OFP stuff in ArmA

[granQ 293]

Q might i suggest you to summarize the thread (from time to time) and put links and data in the first post. Would make a excellent checklist for current and new modellers.

Being doing addons for several years now, and the section thing was totaly new for me.. so still learning

[raedor 8]

Marek says this, more or less:

One parameter, that matters probably the most to the peformance of ArmA engine is the number of draw primitives (sections) the engine has to handle.

This is the no. 1 most important aspect.

Also, note there's an instancing of models so the engine can compose multiple objects of the same type to just one call and drive it as one direct x primitive.

When creating performance optimized content, note that this factor is really crucial while for example number of polygons in the first LOD or overall quantity of LODs is less important, even size of textures could be less problematic in many cases than the number of sections.

And also:

Certainly sections (draw primitives) is a very important aspect that people usually overlook (partly because it was much less important in OFP DX 7 days...)

BI sample models as released are generally well optimized so using these as reference is not bad idea.

So the priority list should be:

1. Sections

2. Texture size

3. LOD #

4. first LOD face #

... or something like that.

[norsu 180]

Is there anything else that has dramatic effect on performance? My weapon model has following stats:

-2 sections

-5 lods with similar polycounts like in BIM16.p3d

-shadow lods

-simple geometry lod

-View Pilot lod on par with BIM16.p3d

-One 1024x1024 texture + rvmat

-No ST coordinate errors (except for the muzzle proxy)

-Animated bolt, trigger and magazine

Still the model performs much worse than for example BIS M16A4 GL which is more complex model with more sections.

[Panda-PL- 0]

Marek says this, more or less:[.....]

So the conclusion is: If I have a weapon pack and certain elements are repeated (the weapon+the accesories in various combinations) it is better to merge the accesories' textures and maps so that the model will have just one texture and material...

Even if that would mean I will have 1 texture with gun+scope+GL+PEQ module on it for each weapon?

On first sight I would say that it's better to have the weapon and scope and GL use separate textures, so the texture count and sizes are few times smaller in overal.

And another conclusion would be not to use two different materials if parts of weapons are ment to be more shiny - but make an _SMDI map for it even if it will contain little detail at all...

This is getting pretty interesting... Althought it's gonna be lots of merging and additional maps and probabl twice or trice the texture ammount.

[.kju 3245]

The question is quite similar to Panda[PL]'s.

How would you suggest to merge your textures in this case.

Lets say you have many custom objects with many textures.

Would you merge textures for each individual object

or

would you merge textures for all objects the same time to keep

the overall texture amount down?

[Yoma 0]

As little as i know of the inside technics of mods. I'd like to add a small but (i think) very important factor.

One of the things i absolutely hate in arma compared to ofp is that is sometimes friggin hard to actually GET IN vehicles.

(the SU for example needs you to be exactly in the right spot)

I suppose one can define the distance needed to achieve this somewhere in a mods definition.

The effect this gives is not so much a performance issue, but a usability issue, still i consider it very important, after all, people are going to PLAY the game, rather then stack up on a vehicle desperatly trying to enter it.

[rocket 9]

Quote[/b] ]One of the things i absolutely hate in arma compared to ofp is that is sometimes friggin hard to actually GET IN vehicles.

(the SU for example needs you to be exactly in the right spot)

I suppose one can define the distance needed to achieve this somewhere in a mods definition.

This has more to do with the location of the named selection "pos driver" and "pos cargo" in the memory LOD. From trial and error, I have found these are best placed at eye height, slightly outside of geometry and view LODs.