0 Пользователей и 1 Гость просматривают эту тему.
Тема: "Памятка мододелу" на примере Viking Conquest DLC (Прочитано 5342 раз)

« : 27 Января, 2015, 10:28 »

Наткнулся на TW на эту тему, почитал, узнал много нового и решил поместить сюда, авось кому пригодиться. Переводом заниматься некогда, потому без оного. Ну если вкратце: автор заглянул в ресурсы мода и ахнул, от непотребства, и дальше он даёт советы по исправлению.

Автор - Death by EMP
Тема на TW

--------------------------------------------------------------------------------

Dear Players, Community members and other fans, I was quite excited to get my hands on the new DLC, But I am now very disappointed in it’s quality.

I spend some time in the Source code of the module (decompiled it) and the BRF files and I can only say that I’m CRYING, how can they release it in this state, and expect it NOT to crash and bug is beyond me.

Main reasons for warband engine to crash: errors in BRF files, High memory usage.
Main reasons for low performance: Bad code, oversided textures and sounds, LOD nonusage.

The Brytenwalda team is to blame for these problems, NOT TALEWORLDS!

Following are the things I shall lay out as problematic that need sorting out ASAP. Keep in mind that I only took a quick sweep over the files and that I most likely did not list everything.

1. General Reminder
2. Script/Module System
3. BRF Files (Using OpenBRF to view them)
4. Textures
5. Sounds

1. General Reminder
Mount & Blade engine loads everything into memory at startup! That means that EVERY single texture, sound and mesh will be loaded into memory. OGGs and brfs. will be unpacked and will become MUCH larger than on your disk.
Also keep in mind that Warband is a 32 bit engine and can only load up to 2000mb into memory. As soon as you go over 2000 megabyte, it will crash!

2. Script/Module System
First of all after opening the source code after decompiling, I got quite scared of the massive amounts of it… anyway I started reading through multiplayer code only because this is the thing that is the most messed up at this time as far as I know.

I shall lay out a couple of topics I want to talk about.

2.1 Performance
In multiplayer, with many players, performance is crucial,
First of all, there are many mission templates, running, often, maybe too often, those will suck up CPU performance, the oh so important performance factor for dedicated servers… please check all template timers and make sure they need to be this often.
Next is the containing code itself, I see many times killing loops in loops, for instance a for each agent in for each agent loop. This is a killer, especially when ran often, with just 10 players you will execute code 100 times, with 100 players the code is executed 10000 times, you can imagine the strain on the server cpu.
Your sea shader change and time code is ran all the damn time even when not needed, 40 times per second really?
There are many more cases, think of horn code checks every frame, etc etc, its a mess.. sort it out!

Networked events… I see so many ints flying left right from and to server, are they really needed? so many? events are heavy, they are secure send, resend and so on, this is a easy killer to networked performance, reduce the events, many things you're sending is already available to the client, for instance his damage and other things…

Overall, cut down on useless code, get rid of straining loops with better architecture, reduce networking events that are not needed, its better sending one event with 4 ints than 4 events with one int! I can rant on but this is so obvious to me… Just, go through the code and think. can this be better..

2.2 hackpositiblies
Maybe even worse than performance, Hack possibilities, I don’t want to give too much ideas to people going to exploit things, but lets just say that many of your bonus abilities, checks and other things are client side only, meaning people can change the code and get rid of many safe guards, think about horns, beserkermode and i think i already said too much, please check absolutely everything a client sends to the server double!, this is so easy to hack right now I’m crying.

3. BRF Files (Using OpenBRF to view them)

3.1 BRF Errors
First of all, I found several errors in the .brf files. Please fix ALL of the following 606 errors and warnings.

Here is a link to a PasteBin due to otherwise exceeding the maximum number of letters.
http://paste.ubuntu.com/9482081/

I think these should be pretty clear. Please contact me if you have any questions about this. Fix all of these, then proceed.

3.2 BRF Organization
Now off to performance optimisation.

First of all, put ALL your textures into a SINGLE .brf.
Then put ALL your materials into a SINGLE .brf
After that put ALL Native textures into a SINGLE .brf
And at last put ALL Native materials into a SINGLE .brf

3.3 Load order
You should always load the Native resources first, then the Mods/DLCs resources.
Take a look at how I have done it in my mod;

Here is a short extract:
load_mod_resource = textures_face_gen
load_mod_resource = shaders
load_mod_resource = mymod_shaders
load_mod_resource = textures
load_mod_resource = mymod_textures
load_mod_resource = materials
load_mod_resource = mymod_materials
load_mod_resource = materials_face_gen

3.4 Texture Flags
We will start with textures. Open the brf in which you saved your textures.
If you click on one of the textures, take a look at the flags. What I have seen so far, is that “Viking Conquest” does not have any texture flags assigned.

Assigning texture flags is easy. Flags depend on your texture size.
Assign: AA000 for 1024*1024 textures
Assign: 99000 for 512*512 textures
Assign: 88000 for 256*256 textures
Assign: 77000 for 128*128 textures

This are the most important flags. If you have textures with different sizes, simply click on the “...” icon to the right of the “Flags” bar. Go to “Size U” and “Size V” and select your texture size.

3.5 LOD usage
Models should become less detailed on distance, this will save a lot of GPU strain for your game, especially in big maps, with lots of players.

You have many meshes without LODS, but only LOD 1 and 2.
However, I would recommend only making LOD 2 and 4. Making all LODs works, but in my experience it is better to only have LOD2 and 4.

Creating all LODs (1,2,3,4) will be unnecessary memory usage. LOD1 is making almost no difference to LOD0. It is just to close, any larger change in geometry will be immediately visible. Making LOD4 very low quality will do fine for most clothing items and so on. Make sure lods use the same material as its parent..

A great way to save a lot of drawcalls in the map is to give small objects (apples, sausages and generally stuff that is very small or always inside buildings) a lod4 mesh that has 0 Vertices and Polygons.

Do not take the LOD2 - 4 only rule too serious though. In some cases it will be better to use LOD3 instead of LOD2.

3.6 Collision meshes
Another source of crashes are collision meshes, these need to be as low poly as possible at all times!
ESPECIALLY MOVING SCENE PROPS,

I noticed that your ships (which are moving sceneprops) Have a rather high polygon collision mesh. Moving scene props are a killer to performance if they have many faces, preferably keep them below 10, anything over 100 is a damn killer. Your ships have over 120 faces.

Also all other scene props in your scene should have very simplified collision meshes, I see that many of your items have very high face count on their collision meshes.
Even though these objects are not moving it will still be a source of crashes and performance problems (Especially with high player counts).

Small objects do not need a collsion mesh at all. I saw a couple of sausages that had a 1000 Polygon collision mesh. Why? Do you need to walk on them? do you need to hit them with your sword? Most likely not. Think about these things before applying any collision meshes.

Long story short, in general, try to keep your collision meshes under 1000 faces and collision meshes of moving objects under 100.

4. Textures

4.1 Compression
I noticed many textures are unnecessarily compressed with dxt5, this takes a lot of memory and is highly inefficient. dxt5 should ONLY be used when you need semi-transparency for your alpha map, otherwise use dxt1 - without alpha unless you have transparency.

NEVER use dxt3, ever. It’s just bad.

4.2 Unused textures
Alright. Take a quick look at this image. It includes all textures that you are currently NOT using.
That means that these textures are in your Texture folder, but are not referenced in any of your BRFs. If players are using load textures on demand, these will not be loaded by the game. They will however have had to download these files for nothing. If players are NOT using load textures on demand, all textures in the BRFs will be loaded on startup, including these unused ones! Not good!

5. Sounds

5.1 Compression format
Warband is known to have problems with sounds you have two things going on here.
The sound engine used is performing much better with WAV files. You only have OGG files, these will perform worse and crash the engine faster.. All short files should be WAV! Using WAV files might increase the overall filesize of the DLC but in the end you are going to profit from it.

It is a common misconception that OGG files are smaller. They are only smaller on disk. As soon as Warband starts up it will unpack all these OGG files and put them into memory. Your 6kb large OGG files will become 10mb.

5.2 Stream for harddisk
Large sound files that are not played often should be streamed from harddisk, this will mean they are not loaded into memory at startup and will not strain the memory so much, these should be in OGG to not get in trouble with harddisk slowness.

Use : “sf_stream_from_hd” in your sounds.py

« **Ответ #1 :** 30 Января, 2015, 04:06 »

А по русски?

« **Ответ #2 :** 30 Января, 2015, 16:01 »

Что-то вроде того (поправьте, пожалуйста, ежели я где ошибся) (курсивом в скобках - мои слова):

« **Ответ #3 :** 31 Января, 2015, 00:57 »

Спасибо большое.

Полезные ссылки

Голосование

Оформление

Статистика

Пользователей

Сейчас на форуме