how to increase perfomance

[Kentucky 『 ＨＥＩＧＵＩ 』 James]

Hi, I'm working on this mod: http://forums.taleworlds.com/index.php/topic,291695.0.html
And I'm hoping to improve performance because i want to make large battles run fairly smoothly. Here are a couple of things I'm either currently doing or thinking of doing, so if anybody knows what (in general) impacts performance more or less, please let me know.

- making lods

- removing large commonres files from the modules.txt, and cutting them down to size when i actually need them

- changing shaders (for materials that don't use bump etc.) where possible, though I'm not sure which ones impaxt performance most

- trying to lower polycount where possible, i.e. the cylinders of spears etc.

- deleting unused items

- lowering particle count/life

- converting sounds to smaller formats (although I've heard that .wav runs better than .mp3 despite the size difference)

So which of these gives better startup load times, or smoother battles? Obviously lods are my first priority but i want to know what it is about warband that taxes the computer so much, i mean afaik it's fairly simple compared to some AAA titles made around the same time.

 

[Mandible]

I hear that shaving down your collision meshes can make a considerable difference.

 

[Austro]

The amount of stuff you put into your scene also makes a huge difference. (at least for multiplayer)

 

[Mad Vader]

If you want to save on memory and have many sound files, you could stream some rare, long sounds like voiceovers from the disk, because all sounds are preloaded. The music files are fine, they are buffered as they play.
Particle effects can slow down a battle considerably, so use sparingly.

 

[Kentucky 『 ＨＥＩＧＵＩ 』 James]

Thanks for the replies, i haven't got to scene buildings yet so I'll try those out.

@madvader how would i do this? Is there a tag in module_sounds.py that i have to change?

 

[Mad Vader]

("tutorial_1", sf_2d|sf_vol_7|sf_stream_from_hd,["tutorial_1.flac"]),

 

[Kentucky 『 ＨＥＩＧＵＩ 』 James]

thanks, i'll try that and all the other suggestions.

 

[Cozur]

I hear that shaving down your collision meshes can make a considerable difference.

This.

 

[Somebody]

Building more lods are good, although I've heard advice to the contrary especially with regards to scene props. I have also seen a LOT of people just using the auto-lod feature within OpenBRF, which leads to unpleasant fragmentation depending on how the model was built. Although some of the native stuff will be using lod materials with less intensive shaders (or even smaller/combined texture sheets), whether the material switching is worthwhile is still up to debate.

In general, unused items and such have minimal effect as long as they are not loading extra textures. During the lifespan of a game session however, object slots can be built up and the savegame will take up more memory building that index. This usually doesn't matter too much if you're focused on the battles, but there is always an impact on performance.

With regards to BRF management - there are different schools of thought on this, either separating meshes, materials, and textures, or clumping everything into one larger BRF, or using them as building blocks, each containing item sets for one particular set of OSP resources or a faction. Do whatever you feel is more intuitive.

 

[Swyter]

With regards to BRF management - there are different schools of thought on this, either separating meshes, materials, and textures, or clumping everything into one larger BRF, or using them as building blocks, each containing item sets for one particular set of OSP resources or a faction. Do whatever you feel is more intuitive.

I keep the SWC resource tree tidy and nice by using a hierarchy in the filename.
Taleworlds could learn a bit from this list of mine:

native.bodies.brf
native.castle_e.brf
native.costumes_a.brf
native.destroy.brf
native.interiors_a.brf
native.item_meshes1.brf
native.map_flags_b.brf
native.map_flags_c.brf
native.map_tree_meshes.brf
native.materials.brf
native.object_b.brf
native.particles_2.brf
native.particle_meshes.brf
native.shields.brf
native.skyboxes.brf
native.textures.brf
native.town_houses.brf
native.town_houses_c.brf
native.town_houses_d.brf
native.tree_e_meshes.brf
native.tree_meshes.brf
native.user_interface_b.brf
native.weapon_meshes1.brf
native.weapon_meshes_b.brf
native.weapon_meshes_c.brf
native.weapon_meshes_d.brf
native.xtree_meshes.brf
native.xtree_meshes_b.brf
native.xtree_meshes_c.brf
osp.cloaks.brf
swconquest.anim.human.1866.brf
swconquest.anim.human.acm.brf
swconquest.anim.human.cmw.brf
swconquest.anim.human.daydream.brf
swconquest.anim.human.swyter.brf
swconquest.anim.human.swyter.chair.brf
swconquest.anim.human.swyter.death.brf
swconquest.anim.human.swyter.force.brf
swconquest.anim.human.swyter.lightsaber.brf
swconquest.anim.human.wb.brf
swconquest.anim.vehicle.swyter.brf
swconquest.flora.brf
swconquest.legacy.armors.brf
swconquest.legacy.map.brf
swconquest.legacy.matntext.brf
swconquest.legacy.objects.brf
swconquest.legacy.redplanet.brf
swconquest.legacy.shieldpoweritems.brf
swconquest.legacy.vehicle.brf
swconquest.legacy.weapons.brf
swconquest.map.swyter.brf
swconquest.map.vector.brf
swconquest.models.artizan.brf
swconquest.models.barf.brf
swconquest.models.barf.rocks.brf
swconquest.models.geroj.brf
swconquest.models.happystormtrooper.brf
swconquest.models.pim.brf
swconquest.models.revanshan.brf
swconquest.models.SupaNinjaMan.brf
swconquest.models.swyter.brf
swconquest.models.swyter.traffic.brf
swconquest.models.swyter.traffic.workbench.brf
swconquest.models.takijap.brf
swconquest.models.thorgils.brf
swconquest.models.tyrinius.brf
swconquest.models.vectordalon.brf
swconquest.models.weapons.brf
swconquest.models.wookieepadawan.brf
swconquest.models.yiyangchen.brf
swconquest.shaders.brf
swconquest.skeletons.brf
swconquest.skins.brf
swconquest.space.brf
swconquest.sprops.geroj.brf
swconquest.sprops.swyter.brf
swconquest.sprops.yiyangchen.bespin.brf
swconquest.sprops.yiyangchen.brf
swconquest.sprops.yiyangchen.mandalore.brf
swconquest.sprops.yiyangchen.moseisleycantina.brf
swconquest.sprops.yiyangchen.naboo.brf
swconquest.sprops.yiyangchen.saleucami.brf
swconquest.sprops.yiyangchen.tariscantina.brf
swconquest.thirdparty.brf
swconquest.thirdparty.coverview.brf
swconquest.thirdparty.gog.brf
swconquest.thirdparty.paazak.brf
swconquest.thirdparty.surrealarms.brf
swconquest.ui.brf

By the way, copying native BRFs to your own mod and stripping unused assets of them
avoids filling the RAM unnecessarily and reduces loading times perceptively.

Keep your texture budget on bay by reusing and tiling, saving with the right size and format.
Remove polygons where can't be seen, they are being draw for nothing.

Shading isn't cheap, use it where it makes a difference.

Oh, and using hardware skinning by choosing the right shader is useful for armors and unloading work for the CPU.

 

[Mandible]

Shading isn't cheap, use it where it makes a difference.

By shading, do you mean ambient occlusion via vertex colors or the shading that the engine does?

Oh, and using hardware skinning by choosing the right shader is useful for armors and unloading work for the CPU.

And which shaders would those be for best results?

 

[Somebody]

Use the _skin_ variant of a shader for anything rigged, for example specular_shader vs specular_shader_skin (those are the basic fallback ones, you probably shouldn't be using them in the first place). A lot of (non-rigged) helmet and gloves are using the same material sheets, and I'm not aware of any testing done to see if changing the shader for those items as well might help or hinder performance.

 

[Mandible]

Right, so a metal armor would probably use specular_shader_skin_bump(_high?). Where do instanced shaders come in? When you have many of the same mesh in one scene?

 

[Swyter]

Right, so a metal armor would probably use specular_shader_skin_bump(_high?). Where do instanced shaders come in? When you have many of the same mesh in one scene?

Exactly, what instancing does is recursively using same mesh in various places at once
to save time processing the changestates of textures, vertex buffers and other stuff.

Instancing adds a bit of overhead because needs passing the positions directly by shader,
so it's primarily beneficial in objects which are commonly drawn in the same scene.

--

For example, drawing an instanced tree 1000 times in the same frame is almost free.
Think of it like stamping a seal various times without changing ink color, it's a lot faster.

But using an instancing shader for a rare object which is only drawn once
is a lot more taxing and takes more time than a normal one.

--

It's all about juggling resources correctly, nothing good comes without a cost, as people say.

Edit: Clarified a bit and formatting.

 

[Cunobelin]

snip

I always wanted to ask how you gave SWC such a small download. Well there's that.