Tbf with instancing you would need one draw call per shell type. But even then that’s more of a CPU bottleneck. I really don’t get the server performance thing. Dropped shells don’t even have armor so they can be 100% client side.
Even then you could do draw-call batching but that would only matter if many people with different shells fire during the same frame, otherwise you would have a drawcall per frame anyway. There is just no reason for it to have any impact. The volume of shells per match would always only be the maximum player count per match (if every player has a vehicle with a unique shell) as every shell fired from one tank is just a reference to its unique parent shell type mesh and texture (if you duplicate this stuff you should revisit programming school and would have a very low hanging fruit for optimization).
I only did a bit of graphics programing and never got to batching but the supposed limitation here makes no sense. I understand that this doesn’t really matter and that the devs don’t want to bother but all the models and textures are already done so ??? I am sure devs are aware of instancing as it’s is 100% used in the game (with trees for example) so maybe there is some other bottleneck I am missing.
Even then. The number is limited to the number of vehicles in a match. It could be a multiple hour long EC match with tanks, planes and naval alltogether and it would never exceed the VRAM used in the beginning when the match got loaded as every shot fired and every case ejected is just a reference representation of a unique shell → 1.000.000 shells fired just use as much VRAM as 1 shell.
Or they either just don’t want to do it or are too lazy. Some errors with modelling of some meshes and props can be just accounted to laziness or slip of the pen because they wanted to be done with it fast and QA didn’t do their job right or flatout didn’t exist.