Форуми / Mapping / r_speeds и тяхното редуциране. - SECTOR.BG Counter-Strike Community

Форуми

SECTOR.BG Counter-Strike Community - The Best CS 1.6 Servers in the World! :: Форуми :: Общност :: Mapping		<< Предишна тема \| Следваща тема >>
r_speeds и тяхното редуциране.


Редактори:Kobri, Lucky, SleepWalker, perfektnoto savur6enstvo, Lummox, -ThugLife-, Xfirb, pochti perfekten*, Keep Hope Alive

Автор

Отговор

DragonClaw

чт сеп 01 2011, 05:20

Регистриран потребител #18

Регистриран: пт фев 20 2009, 01:58
съобщения: 791

В днешно време много хора си мислят, че след като машини, поддържащи 100fps на CS са по-достъпни от всякога, оптимизации по картите не са необходими. Лаг обаче може да бъде причинен не само от ниската производителност на даден компютър, но и от дестабилизирането на HL Engine, а в такъв случай дори най-бързият компютър няма да ви помогне. Оптимизирането има и друг плюс - тъй като можете да направите много без картата да изглежда "по-зле", то ви отваря възможност за още повече детайли, с други думи оптимизирането не е ограничение, а обратното.

За да проверите дали картата ви е добре оптимизирана трябва да стартирате играта под developer mode:
developer 1
map <mapname> - пускате си картата
r_speeds 1
gl_wireframe 2

При написването на r_speeds 1 в горния ляв ъгъл на екрана ще ви излязат числа, подобни на тези:

wPoly е броят на полигоните с текстура (texture polygons) на картата, които са изрисувани в момента, с други думи полигоните, които играта "вижда" в момента.
ePoly е броят на полигоните на моделите (.mdl).
MS са милисекундите, за които всеки един кадър е изрисуван.

Двата основни принципа за намаляване на r_speeds са намаляване полигоните на даденото пространство и намаляне видимостта (връзки между пространствата).

Да започнем с връзките между пространствата:

Както виждате на картинката, препоръчителни са тесни връзки между отделните големи пространства, широките трябва да се избягват, защото повече полигони биват изрисувани наведнъж. Стени дори с малки дупки/прозорци не блокират видимостта и е по-добре да не се използват.

Ако сме се погрижили отделните пространства да са свързани добре, можем да намалим и полигоните за всяко от просранствата. За целта трябва да знаем как HL Engine реже полигоните:

Полигоните са изрязвани на всеки 240 units. При мащаб на текстурата 0.5x1, полигоните са изрязване на 120 units, докато мащаби над 1x1 намаляват полигоните и са често използван метод.
Това може да се промени с добавяне на параметър за HLBSP -subdivide # (default 240) при компилиране, но често по-големи стойности създават проблеми под software mode и картата крашва при зареждане.
Представете си че в стая имаме 10 сандъка, като на всеки от тях виждаме по 5 страни (4-те стени + горната страна); размер на тексурата 256х256. Всяка страна на сандъка ще има 4 полигона, вместо 1 (при текстура 240х240 пиксела или по-малко). 3 полигона повече на страна X 5 стени за сандък X 10 сандъка = 150 полигона повече, което не е малко!
При правенето на Bomb/Defuse (de_) карта ползването на тексури ***х256 пиксела както и стени високи 256 units е нормално, тъй като това съвпада с по-широка мрежа, работи се по-лесно и очите ви се натоварват по-малко. Въпреки това е добра идея да намалите височината на стените на 240 units, защото това намаля двойно полигоните за дадената стена и редуцира r_speeds много.

Друг начин за намаляване на полигоните е избягването на "extradivides". Те се получават при допирането на две равнини:

Има няколко начина за предотвратяването им:
При задаването на func_wall функция обектът няма да прави допълнителни изрезки върху друга равнина. Има обаче няколко неща, с които трябва да внимаваме:
1.Обектите с функция (entities) са изрисувани от по-голяма дистанция за това трябва да използваме null текстура по равнините им, които са недостъпни за погледа ни.
2.Задаване на обща функция за големи обекти не е добра идея, защото където и да сме, играта ще трябва да изрисува абсолютно целия обект, ако виждаме дори само част от него.
3.Групирането в обща функция на предмети, чиито равнини се допират трябва да се избягва, защото отделните обекти ще изрежат допълнителни полигони по другите равнини.

Т.нар. "brush in brush" ефект също прави extradivides. Ако примерно равнините на два блока се закачат малко в единия ръб, могат да се появят допълнителни изрезки дори по другите равнини на двата блока:

Още един начин за избягването на extradivides е стар трик с оставянето на 1unit празнина между двата обекта. Така равнините им не се допират и няма да има допълнително изрязани полигони.

Други начини за оптимизиране са:
използването на null: [натисни тук]
използването на hint: [натисни тук]
добавянето на -full параметър на HLVIS при компилиране. Това прави изчисленията по-точни и понякога може да спести някой друг полигон.

Също така не е зле да имате едно на ум, че func_water принципно е доста натоварващо entity за HL Engine, за това е по-добре да използвате func_illusionary (contents - water) вместо вода, освен ако не са ви не обходими вълни.

Урокът е базиран главно на информация от тези статии:
[натисни тук]
[натисни тук]

[ Редактирано нд сеп 04 2011, 10:19 ]

Най-отгоре

{SENDPM=18}


Иди: Най-отгоре Colour Key: Главен Администратор, Администратор, Support, Екип, CS Админ, VIP, Miss Sector.BG, Потребител

SECTOR.BG Counter-Strike Community - The Best CS 1.6 Servers in the World!

Добре дошли

Свържи се с нас

Форуми