[Map] Assault on Grozny (2km) [Released]

[Arab]

Actually, my earlier suggestion about using that autoclick program: Don't use it. It autostarts, and I easily forget about it, press the keyboard shortcut and it clicks things.

[Rudd]

Excellent screenies there mate, re performance issues you'll suffer from the same problem as dragonfly where enterables are causing alot of the trouble, if it comes too it, start thinking about which enterables to replace with vbf2 statics. It really looks brilliant though.

[Ason]

if it comes too it, start thinking about which enterables to replace with vbf2 statics.

Thanks guys, to me it actually feels like the heavy stuff is the outer parts of the city with the small houses, because there I have pavements+walls+trees+houses+various small objects packed togheter...But yeah, it would be great if I "only" had to replace some big enterables.

[Rudd]

I hear that, remind me, have you already decreased the size of the lightmaps for the Russian house's Wreck LODs? That might help performance in those areas, since those houses aren't actually destructable its a must-do thing to save RAM and FPS

[Ason]

I hear that, remind me, have you already decreased the size of the lightmaps for the Russian house's Wreck LODs? That might help performance in those areas, since those houses aren't actually destructable its a must-do thing to save RAM and FPS

yeah first thing I did, I think there is really nothing more to optimize in lightmapsfolder, if I remember correctly I resized just about everything that could be resized..

[rPoXoTauJIo]

You can also not make an entirely new faction and just use a kit variant for Russians. For example the Russians do not use a _ziptie variant yet. For that you just need to create new faction that is called ru_ziptie and create all the kits you want with _ziptie suffix. With that trick you wont even need new python.

Sad to report that this isn't working either
Even more, python replacing main weapons on spawn screen&requestables if i'm creating _ziptie factions.

Guess no map-based solution for this atm.

[Ason]

Sad to report that this isn't working either
Even more, python replacing main weapons on spawn screen&requestables if i'm creating _ziptie factions.

Guess no map-based solution for this atm.

That's a shame, thanks for looking into it though.

Does someone know how to properly generate the groundhemi?
I generated it a couple of times but it still doesn't work properly(when inside L-shaped buildings I get sunlight on the gun for example). I use the default settings and when it's done generating, the terrain turns completely black(I guess that's just a bug that always happens) then I close the editor without saving. Is that how you do it?
Most parts work fairly well but there seems to be some errors here and there:/

[Rabbit]

Post a picture of your hemimap

[Ason]

[TheMerchantOfMenace]

Ason, by accident I saw a post you made some 2 years ago about having a hard time motivating yourself to keep working on this map... WOW!

What a shame that would have been if you hadn't found it in you to keep working on this map!

I got on this map this afternoon on PRTA... I only have just under one hour on this map so far, but from what I've seen, this is looking to be one of the top maps in PR.

Beautiful, beautiful map! Thank you for making these maps! Lovely textures, wonderful amount of detail, great variety of terrain to fight in. Top notch!

I really hope there will be no balance issues or any other problems so that this map becomes a regularly played PR map. On top of it, for us infantrymen, this no-air-assets map is a welcome relief.

Can't wait to see what else you can put together.


P.S. Thanks to Mineral as well for his words of encouragement to Ason at a possible critical time.

[Ason]

Thanks for the kind words Merchant, unfortunately the map is laggy as hell atm and won't make it into the mod in this state.

However after playing the map this weekend I have been really motivated to fix it. Although to do that I would need the destroyed versions of the small houses. Can someone explain how to make a static use Geom1 instead of Geom0? I know I have asked about this before but I think I asked about a way to do it in the editor, this time I would like to try to copy the statics, change the name and edit the tweak/con to use Geom1.
Arc_shielder told me this:

You can just simply copy those object folders and remove everything but the con and tweak files. And change the geom line to 1. Ofc you must give these new objects a different name though.

But I'm having some problems finding those lines..

con:

Code: Select all

GeometryTemplate.create StaticMesh house_dest_4a
CollisionManager.createTemplate house_dest_4a

ObjectTemplate.create SimpleObject house_dest_4a
ObjectTemplate.saveInSeparateFile 1
ObjectTemplate.creator MB03:mb
ObjectTemplate.collisionMesh house_dest_4a
ObjectTemplate.mapMaterial 0 Penetrable_plaster_wall 0
ObjectTemplate.mapMaterial 1 Ceramic_tiles 0
ObjectTemplate.mapMaterial 2 Wood_solid 0
ObjectTemplate.mapMaterial 3 concrete 0
ObjectTemplate.mapMaterial 4 stairs_concrete 0
ObjectTemplate.hasCollisionPhysics 1
ObjectTemplate.physicsType 3
ObjectTemplate.geometry house_dest_4a

include house_dest_4a.tweak

tweak:

Code: Select all

rem *** Generated with Bf2Editor.exe [created: 2006/5/15 12:52]
GeometryTemplate.setSubGeometryLodDistance 0 0 50
GeometryTemplate.setSubGeometryLodDistance 0 1 150
GeometryTemplate.setSubGeometryLodDistance 0 2 300
GeometryTemplate.setSubGeometryLodDistance 1 0 50
GeometryTemplate.setSubGeometryLodDistance 1 1 150
GeometryTemplate.setSubGeometryLodDistance 1 2 300
GeometryTemplate.doNotGenerateLightmaps 0
GeometryTemplate.lightmapOverride 0
GeometryTemplate.compressVertexData 1
GeometryTemplate.maxTextureRepeat 16
GeometryTemplate.glowing 0
GeometryTemplate.noLighting 0
ObjectTemplate.activeSafe SimpleObject house_dest_4a
ObjectTemplate.creator MB03:mb
ObjectTemplate.modifiedByUser "mb"
ObjectTemplate.saveInSeparateFile 1
ObjectTemplate.cullRadiusScale 5
ObjectTemplate.geometry house_dest_4a
ObjectTemplate.setCollisionMesh house_dest_4a
ObjectTemplate.mapMaterial 0 Penetrable_plaster_wall 1001
ObjectTemplate.mapMaterial 1 Ceramic_tiles 82
ObjectTemplate.mapMaterial 2 Wood_solid 15
ObjectTemplate.mapMaterial 3 concrete 78
ObjectTemplate.mapMaterial 4 stairs_concrete 34
ObjectTemplate.hasMobilePhysics 0
ObjectTemplate.hasCollisionPhysics 1
ObjectTemplate.physicsType Mesh

[Arc_Shielder]

I must of been drunk when I said that (maybe thinking of the editor?). There is more to it than just finding a line.

EDIT: I'll reply to you later today via PM.

[Rhino]

The only way I'm aware of being able to make a dest object only show its wreck by code, is to give it an HP level of 0 or below in much the same way we have our deployables start off as a wreck when you deploy them.

The big problem with this however in this case, is that they have to be kept as a destroyable object with a Networkable. This means, like normal destroyable objects, you can only place a certain number of them on your map before you risk your map reaching the networkable limit, and if it dose that in a game the server will crash...

There may be a way to force geom1 to show instead of geom0 with keeping the object as a "SimpleObject" without the need of a Networkable but if there is I'm unaware of it.


On top of this, I believe the wreck models are seriously buggy, either in relation to their lightmaps or collisions or something along those lines. As such you should fully look them over and test them before you even consider using them on a large scale.


As such if you really want to use them, the best course of action would be to import the wreck models, fix up all the errors, both created by importing the mesh and any errors before, and just exporting the wreck as its own, new static. This will also mean you don't need to lightmap all the geom0 lods etc too. But this is a pretty complex and time consuming process which you will be hard pressed to find someone to be able to do it.

[TheMerchantOfMenace]

... the best course of action would be to import the wreck models, fix up all the errors, both created by importing the mesh and any errors before, and just exporting the wreck as its own, new static. This will also mean you don't need to lightmap all the geom0 lods etc too. But this is a pretty complex and time consuming process which you will be hard pressed to find someone to be able to do it.

I might be able to do a lot of this work, if shown?

Not necessarily Rhino... anyone, if you have time to show/explain how to do the work described above.

[Ason]

Rhino;2067918']
The big problem with this however in this case, is that they have to be kept as a destroyable object with a Networkable. This means, like normal destroyable objects, you can only place a certain number of them on your map before you risk your map reaching the networkable limit, and if it dose that in a game the server will crash...

Thanks for the help Rhino, I managed to get it working like this (although I don't think I will use them). I'm just curious, for the map to reach the networkable limit does all the destroyable object have to be destroyed or is it enough to just have 300 destroyable objects on the map?

Also another question. I'm rebuilding the city in certain places to increase fps but I'm not really sure what to look for on statics for performance comparison. Is it enough to look at the number of polys or are there other things that count aswell?

For example the normal apartment buildings rus_apt_v2_var1(not the L-shapes but the one that has a yellow version aswell) have about Lod 0 - 6700 polys while the apartment from shija has about 25000 polys.
Is that enough info to know that 2 of the smaller ones are better than 1 of the big one?

[Rhino]

I might be able to do a lot of this work, if shown?

Not necessarily Rhino... anyone, if you have time to show/explain how to do the work described above.

Its requires quite an advanced skillset which isn't at all easy to explain all the steps. Would spend at least a week writing a tutorial while doing an object as an example and tbh it would be quicker for me to do them all myself, but I've got bigger fish to fry and I've got enough projects on the go as it is

Thanks for the help Rhino, I managed to get it working like this (although I don't think I will use them). I'm just curious, for the map to reach the networkable limit does all the destroyable object have to be destroyed or is it enough to just have 300 destroyable objects on the map?

Any object with a "ObjectTemplate.setNetworkableInfo" in its .tweak file (or .con but very unlikely to find it in there) counts towards its networkable count, no matter what state the object is in. This line of code basically just means that the server needs to constantly monitor the state of this object (and or sub part) to see if anything changes and if it dose change, to tell all the clients on the server it has changed. In the case of a Destroyable Object, it has to constantly monitor its HP to check that it isn't taking any damage, or being repaired, even if its at 0 damage and can't be repaired
Vehicles tend to have lots of Networkables, for each player position, weapon, moving part etc. The AAVP7A1 for example has a total of 16 networkables, since there are quite a few moving parts (wheels, turrets etc), weapons (50cal and Mk19) and 8 player seats.

Also another question. I'm rebuilding the city in certain places to increase fps but I'm not really sure what to look for on statics for performance comparison. Is it enough to look at the number of polys or are there other things that count aswell?

For example the normal apartment buildings rus_apt_v2_var1(not the L-shapes but the one that has a yellow version aswell) have about Lod 0 - 6700 polys while the apartment from shija has about 25000 polys.
Is that enough info to know that 2 of the smaller ones are better than 1 of the big one?

The main things you really want to look out for, in order of importance, at least for your map since your main issue is lots and lots of objects, are:

1. Draw Calls - These are basically individual types of items that need to be rendered and one of the main bottlenecks is not with actually rendering objects, but getting the message though the CPU, into the GPU and having the GPU process each draw call individually. If a player's PC doesn't have a very good CPU, then this can easily become the bottle neck with the GPU just sitting back in his arm chair, drinking a cold beer while he waits for the CPU to send the next draw call it needs to do and once its come though it hardly has to get out of its chair to deal with it before its waiting for the next draw call. But the clients GPU can easily too be the bottle neck with having to process all these different individual tasks which can easily overload it as well. In all, the fewer draw calls there are, the fewer individual tasks there are and generally speaking, its much easier for both to process a massive, single draw call than lots of tiny ones, even if the triangle/polygon count of all the little tiny ones is far smaller than the big one.
   • Material Draw Calls - Each Material of an object counts towards the total number of draw calls and the more materials an object has, the more draw calls it has, resulting in it being harder to process, even if each material is loading the exact same textures as another material or other materials. To find out how many materials an object has just open it with BFMeshView and you will see the amount of materials listed for each LOD:
     
   • Number of Parts/Children an object has - If talking about just statics here, some statics has lots of extras added onto them like ladders, TV antennas etc via Child objects. These all count to the amount of draw calls. Some statics like the Carrier, or some city buildings even, are split into multiple objects and these individual objects all count towards their own draw call, turning a assumed single object like the Carrier into lots of individual draw calls, before you even get into its sub material draw calls etc. . If the item is complex like a vehicle then the turret, wheels etc, basically all the other moving parts all all individual draw calls too although if they all share the same materials they can be sometimes in theroy grouped up into a common draw call.
   • Reduction of Draw Calls in the LODs - Having lots of draw calls on lod0 is fine if the LODs drastically reduce the amount of draw calls there are throughout each one. As such you then only have to heavily process an object when your near it, and when far away from it its easy to process, and if every static is like this, then your CPU and GPU only really needs to think about the bunch of objects your near and hardly any on the objects that are far away. Take into account the above both points when looking at the lods to check their amount of materials used on each lod is being reduced, main thing to look out for is the final lod only has ideally only 1 material (especially if its an object that will be drawing for a long distance and your map has a large VD) and also the amount of sub parts are being removed too, with the final lod should only be the main object without any or very few moving parts.
2. Cull Distance - This is basically when the object is removed from the drawing process and generally speaking, most small objects have a very small "cull distance", since they can be removed from view at a small range, without the player noticing them, effectively removing their draw call and having one less thing to process. But big buildings etc need long cull distances, some even beyond 3km (the max VD in BF2) since they are so large that if they where to be culled at any range they would be noticed and worse, have an impact on gameplay (ie, a player thinking he can shoot another but in reality there is an object in the way which he can't see between him and the player which his bullets would hit if he shot at him, since its being culled). There is no easy way to find out when an object culls since its based on the object sizes, how many tris and lods it has, and "cull radius scale." As such the only way to really find this out is to fly away from it in the editor or better yet ingame (since ingame objects have longer cull distances than in the editor) and see at how far you need to fly away from it before it disappears, with the smaller the distance the better, unless it has an impact on visuals and gameplay. A tiny little prop like a shovel that draws for 3kms for example is an object with a really bad cull setup.
3. Texture Size/Memory
   • Textures Loaded by the Mesh & Their Size - Every object has textures assigned to it and you need to ask yourself is it really worth loading these extra textures into the clients memory, which also slows down processing time, with the larger the texture being (and the more its tiled), the harder it is to render. There is also a maximum amount of RAM a player has and since BF2 is a 32Bit game, it can only use around 4gb of RAM maximum even if the player has more and if the player exceeds his memory limit, he/she will crash. Statics luckily share common texture palettes and you should aim to only use objects which use the same textures, as per this post: https://www.realitymod.com/forum/f189-m ... mance.html
   • Lightmap Sizes - One area often overlooked by mappers is how much lightmap space is this object going to take up, also keeping in mind how many of these objects your placing on your map. Some objects, especially large buildings, have massive lightmaps which like normal textures, increase rendering time and strain your GPU more. As such you should look for using objects with the most optimized lightmaps for their size. You can find an objects lightmap size by either opening the LM Samples in BFMeshView, with the ".samples" being the LOD0 sample, ".samp_01" being the LOD1 sample, ".samp_02" being the LOD2 sample etc. Once open you will be able to see the width and height of the lightmap settings in the top left:
     
     
     
     Or by looking in the Master_LightmapSizes.txt file (right click, save as) and Open it with a text editor (it dose not contain all statics yet).
4. Triangle Count - These may be refereed to as "Polygons" or "Polys" but in reality they are all Triangles, ie, 3 Sided Faces where a Polygon can have 3 or more Sides to its Face. To put it simply these are what make up the surface of all objects and what the textures are applied to and generally speaking, the more triangles your object has, the harder it is to render. But with modern day GPUs etc, triangles are pretty easy to render and providing an object has a good set of LODs (look below for more info) then having a high poly lod0 is generally ok.
   • Triangle LOD Reduction - As per the above, its important, especially on maps with large view distances, to have an object with a good set of LODs and most imporantly of all for maps with large VD, have a decent "Final LOD" with very few triangles, ideally under 100 tris.
5. Collision Mesh Complexity - It is important to look at how complex the collision mesh is as well since this is processed by both the client and the server and having very detailed collision meshes can have a serious impact on performance, especially server side performance. col0 is the decal col, what bullets hit and is generally the most complex col, but shouldn't be overly complex. col1 is the physics col, what vehicles hit when they drive into a building, and this should be a very basic mesh. col2 is the player col, what players walk on etc and it should be a pretty basic mesh, but still have all the doorways etc items a player can run into and walk on/though. Again the lower the amount of Triangles/Faces the collision mesh has, the better:
   

[Ason]

Thanks Rhino, I really appreciate the help! I'll try to compare these things on a few different statics.

There is no way to get an accurate number of drawcalls for a static? Should I just look at the number of materials and child objects and compare those values?

When looking at the collisionmesh, do I just look at it to see if it looks complex or are there values to check?

[Rhino]

There is no way to get an accurate number of drawcalls for a static? Should I just look at the number of materials and child objects and compare those values?

That is the simplest way to get a pretty good estimation of how many draw calls have but a more accurate and probably faster way of getting the real draw call total of an object, with its child objects is to open it in the object editor and then in the console type in "raStats.draw 1" and it will display a lot of information about the stats of the object but the one your most instated in is the total draw calls of an object which is shown here in blue for LOD0 of the hotel, which is a total of 13 draw calls:


And if you look at the other LODs (close up) you will see LOD1 also has a total of 13 draw calls, LOD2 has 8 and LOD3 has 6:




But note one of these draw calls is the child ladder on the side of the hotel and if you fly away from the object till it is culled LOD3 drops from 6 draw calls to 5 draw calls:


This is also a very useful tool you can use in the level editor to find out where the areas of your map has the most draw calls and where you need to do the most optimization work, with the amount of draw calls based on what your camera can see, as if you where a player. Remember to put your editor's View Distance to use the Levels settings and have fog, overgrowth etc on for an accruate result.


You can also use this in the debugger for even more accurate results.

When looking at the collisionmesh, do I just look at it to see if it looks complex or are there values to check?

As I tried to explain above, you can see the amount of "faces", aka triangles each col has by expanding it in BfMeshView like so:

[rPoXoTauJIo]

Wow, that's should be in tutorials section. One more useful spampost plz, Rhino?

[ComradeHX]

You finish this map and I will assemble sone period-correct kits to go with it.