Project Reality Forums

Outlawz7 wrote:No, it's not that straightforward. Like Rhino said, some weapons are better optimized than others.

I got that, but the question is... the amount of polygon on 3rd weapons is the main cause of dropping performance?

Danesh_italiano wrote:I got that, but the question is... the amount of polygon on 3rd weapons is the main cause of dropping performance?

If it is the weapons, its not the polygon count as that's easy for any GPU after 2010. It would be the drawcalls.
No clue what it is though.

Danesh_italiano wrote:So, just confirming, weapons that has same 3rd and 1st models is the mainly reason for FPS drop when looking at players direction?

Doing it manually is basically impossible unless someone get paid to doet

On some systems, and on maps where there are lots of draw calls, yes, but not nearly the number one issue, its a combination of lots of issues, it's just one example of an area that can be optimized, but to do it would take a lot of work and even after it's done, it might not be enough on its own to fix someone's performance totally and for some people, draw calls might not be their systems biggest problem.

Basically a draw call is something that the CPU has to process and send to the GPU, before the GPU can render it. The bottleneck often happens on many systems with not very good CPUs, when so many draw calls are having to be sent through the CPU to the GPU, and the CPU can't cope with all the messages it needs to think about before sending it off to the GPU to process. But draw calls can come from anything needed to be rendered, with some objects often having lots of draw calls for all their different textures/materials, like weapons having unique materials for each attachment they have, and sometimes multiple textures/materials for things like just the scope, having the mounting bracket for the scope, the scope body and then the glass all having different materials.

But for people with really good CPUs, draw calls might not be their bottleneck, it could be their GPU can't handle all the tris they need to render so having lots of high poly guns to render might be their issue, rather than the draw calls needed to be processed before the GPU can render them.

But to be clear, badly optimized handheld weapons is just one of many areas in PR that could be optimized. There are a hell of a lot of bad staticobjects (which Faulljuah has many of them), vehicles etc that PR has in it that are all part of the problem. Fixing the weapons alone while would be a big step in the right direction, wouldn't solve all the problems and for many people, won't make a noticeable change on its own even.

Outlawz7 wrote:No, it's not that straightforward. Like Rhino said, some weapons are better optimized than others.

https://i.imgur.com/sYT4pYW.jpg

https://i.imgur.com/L5BUKPJ.jpg

Those are also not the best examples hehe.

This M4 has 11 materials for it's 3p LOD0, and 6 for it's final LOD.





The FAL was also a quick optimization jobby I did, mainly just lowering the rez of it's 3p textures rather than re-uving it and baking it's textures to a much lower rez model.

The Blowpipe is a better example, although its final LOD is higher poly since it was bulky and a flat final LOD wouldn't have been enough.




If you're wondering why the 3p LOD2 is higher poly than the LOD0, it's because it's the "After Firing" LOD which is hollowed out and is only seen for a bit after firing until it's reloaded, and ignore the shininess of the 3p models, that's just BFMeshView getting confused about how the 3p textures are setup, doesn't do that ingame.



Also it's textures:

1p diffuse/spec and normal all being 2048x2048 with only 1 Mip, total texture memory usage of 6MB:



3p texture diffuse 512x512 with 10 mips, and normal/spec 256x256 with 9 mips, total texture memory useage of 256kb:



And ye, final LOD texture being 128x128 and 1 mip, which is pretty large compared to other final lods of other weapons but cos it was so bulky, texture mem of 16.1kb:


A better example of a proper final LOD texture would be the Bren, 64x32, texture mem usage of 2kb:

Thanks for the explanation, very illuminating!

I think the draw calls must be the main culprit then, seeing as most people with modern systems can run fallujah at 60+ FPS on a local server with no other players present. But then it drops below 30 on a full PvP server in the midst of the action.
That is the case for me and also for two other people with high end system i talked to. I am talking lots of high quality fast RAM, top GPU models and CPUs right up there in the single thread performance ratings, meaning top 10.

So it must be draw calls unless there is another aspect to players/player models being present in the field of view that can affect performance as well.

Wasn't it a practical thing with AR15 based weapons to make parts of them and then assemble them into M4/M16 etc. and that's why each one is made up from so many drawcalls?

DogACTUAL wrote:But then it drops below 30 on a full PvP server in the midst of the action.

Does it also drop on local co-op? Because all those bots are holding the same weapons as human players.

It drops even more on COOP, due to the amount of bodies I guess.

Outlawz7 wrote:
Does it also drop on local co-op? Because all those bots are holding the same weapons as human players.

Yes and my "benchmark" was done with 48 bots. This is why i posted that video with 255 bots.

Outlawz7 wrote:Wasn't it a practical thing with AR15 based weapons to make parts of them and then assemble them into M4/M16 etc. and that's why each one is made up from so many drawcalls?

Ye, and other weapon series, the SA80 series isn't all that different in that regards, many parts that all come together to make lots of versions. This is one of the key reasons why it was never properly adopted because separate 1st person and 3rd person models/textures, with the 3rd person textures having to be together on an atlas, made things a lot more complicated.

Made this video on a nearly full PvP server, started far from people and made my way to the front, never saw FPS fluctuate by more than 1FPS away from the hard-set 100FPS cap that I was getting....

Saw that line that Alon posted:

AlonTavor wrote:game.lockfps 0
I get 1200fps when high in the sky. Its obviously something with the rendering.

Would be nice if we could put that line in a file somewhere to unlock that FPS cap. Is there? Or is that in the compiled pythons?



100FPS cap on Black Gold ~98 player PvP:

SemlerPDX wrote: Would be nice if we could put that line in a file somewhere to unlock that FPS cap. Is there? Or is that in the compiled pythons?

Tried it in console? Should work.

SemlerPDX wrote:. Is there? Or is that in the compiled pythons?

Python does not exist on client if you don't press the "create local" button.

PatrickLA_CA wrote:Tried it in console? Should work.

So, basically it can't be an option in the GFX options menu or config? And must be entered each session? map? through the in-game console? Better than nothing, got a few that need to be input in ARK that same way to get that game to run well, and it's a major game that's been out forever. No worries there.

Would be cool in the modern era of newer systems to provide this option as a checkbox, but I know everyone is mostly focused on what effects the majority of players, and optimizing the new additions. Thanks and cheers!

@SemlerPDX

That map/layer is one of the better running ones, don't ask me why.

Here are a bunch of maps you should try the FPS test on:

Fallujah West
Dovre (the green version)
Assault on Grozny (inside the city)
Al Basrah
Burning Sands (inside the city)
Operation Marlin
Kokan


Some city maps run really well, like Gaza or Jabal.
Any clue why that is? Maybe more vanilla buildings instead of custom ones?

DogACTUAL wrote:@SemlerPDX

That map/layer is one of the better running ones, don't ask me why.

Here are a bunch of maps you should try the FPS test on:

Fallujah West
Dovre (the green version)
Assault on Grozny (inside the city)
Al Basrah
Burning Sands (inside the city)
Operation Marlin
Kokan


Some city maps run really well, like Gaza or Jabal.
Any clue why that is?

None of those maps that run poorly surprises me at all.

Jabal hardly counts as a city map.

SemlerPDX wrote:So, basically it can't be an option in the GFX options menu or config? And must be entered each session? map? through the in-game console? Better than nothing, got a few that need to be input in ARK that same way to get that game to run well, and it's a major game that's been out forever. No worries there.

Would be cool in the modern era of newer systems to provide this option as a checkbox, but I know everyone is mostly focused on what effects the majority of players, and optimizing the new additions. Thanks and cheers!

Kinda pointless when nobody gets above 80

DogACTUAL wrote:Any clue why that is? Maybe more vanilla buildings instead of custom ones?

It's a combination of things, it can be down to what statics are used, how many are used, etc. Each individual object is a minimum of one extra drawcall, can be a lot more if that object has multiple materials as well.
A mapper can make a map seriously unoptimized by just putting lots and lots of individual statics down in the same area, which on their own are well optimized, but having many of them packed densely together can overload a clients CPU with drawcalls.

But yes, some PR statics are not at all optimized and have lots of problems, many have lots and lots of different materials, each adding to the number of drawcalls that need to be processed.

But many vBF2 statics are pretty bad in many ways, and one of the worst thing about most vBF2 statics is they have really bad final LODs. By final LOD, I mean the very last LOD that is shown right upto the point it is culled (objects are coded to be culled, or removed from having to be drawn once you are so far away from them, you can't see them any more, with the smaller the object is, the earlier it can cull or "disappear", removing you from having to even process its draw call let alone render it, but big things like buildings generally have to have very large cull distances), or more commonly until the draw distance cuts it out from being shown.
You can see here this hotel building has a final LOD of 501 tris and 3 materials, which isn't too bad:


Generally, I like to aim for a final LOD of around, or better yet if possible under 100 tris (the lower the better) and only one material, which is what you can see for the final LOD of this tent I made some time ago, which as you can see the final LOD is only 14 tris, the most basic shape of it possible, and only one material, with this final LOD kicking in at 250m and being seen until it culls (can't tell you when that is without loading up the editor and testing, all I can tell you from the code is it has a cullRadiusScale of or upto the view distance:




However, with all this being said, fixing statics and maps in PR/BF2 is a total nightmare. It isn't as simple as just fixing up that static and then having that fixed applied to all the maps it's on. If you change a static in any little way, unless you very skilled and incredibly careful, your going to screw up or at least change its Lightmap UVs (not to mention basically all the statics in PR have horrible automatic Lightmap UVs that really need to be replaced with an optimized custom LM UVs), meaning that any changes you make to the static will mean that all the maps that static is on, will need to be re-lightmapped or have its shadows all screwed up and not only is that a huge amount of work, it often isn't possible with missing editor files.

This is why generally whenever a static gets fixed up, a new version is made of it. I recently fixed up the "cablepole_v2" I made years ago for Dr Rank while also making a few new versions of it, but since the original version had really bad and unoptimized automatic Lightmap UVs since when I originally made it, I didn't know about custom LM UVs, so while I could have kept the old LM UVs while fixing up the minor errors if I was super careful, it wasn't worth it so I made a "cablepole_v2b" version with fixed errors, better LODs/cols but the biggest optimization was the optimized custom LM UVs. Then I just informed all the mappers about the new version and any existing maps that used the old version could replace them with the new version whenever they receive an update, and but it was up to the mappers to do that. But chances are in my experience that very few maps, if any, will ever bother to go to the effort of updating them just for this minor improvement, and only do it if they receive a major update, but at least the new version is there for if that happens and any new maps in the works.


Old versions automatic LM UVs:


New versions automatic LM UVs:

vBF2 statics are very good for their purpose which was putting a handful of them on maps with low view distance.

Outlawz7 wrote:vBF2 statics are very good for their purpose which was putting a handful of them on maps with low view distance.

Ye thanks Outlawz, was planning to but forgot to mention that that is what they where designed for and as such, they didn't need the super low poly and minimum impact final LOD because they would be culled out by the short VD of vBF2 before they where needed.