Sidebar

Оптимизация карты. R-Speeds. Wpoly, epoly.

Оптимизация карты. R-Speeds. Wpoly, epoly.

Всем привет! Как известно, в учебнике Дмитрича пишет, что "wpoly" - это полигоны от брашей, а "epoly" - полигоны от моделей (рук с оружием, моделей ироков, моделей на карте). Возникает вопрос, полигоны от энтити-объектов (func_wall и т.д.) попадают в категорию wpoly или epoly? В другой статье от Дмитрича о компиляторах ZHLT Custom build идет речь о закрашивании нуллом невидимых сторон брашевых энтити (к примеру, дно или место прислонения к другому брашу). А в брашах, которые прислонены друг к другу (например, забор, который соприкасается с землей) тоже нужно этой текстурой дно закрашивать или эти стороны автоматически "отсечет" HLVIS?
 

Cep}I{

>: 4 8 15 16 23 42 ▌
Nov 23, 2008
941
35
KaJlawHuKoB said:
А в брашах, которые прислонены друг к другу (например, забор, который соприкасается с землей) тоже нужно этой текстурой дно закрашивать .... ?
Обязательно! Всё невидимое закрашиваем нуллом.
 

Leshiy

Редактируемый
Sep 24, 2011
216
30
4
0
А разве движок не обрезает эти места при компиляции? По крайней мере в соурс работает. До недавнего времени прям с пеной из рта закрашивал все "невидимое" нодравом. Но потом оказалось что на производительность или скорость компиляции - не влияет...
(Это я именно про плоскости брашей которые прилегают друг к другу)
 

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
2 KaJlawHuKoB: функ_валлы это wpoly тоже.
Ну да проверить легко. Делаешь карту-коробку и ставишь на ней функ_валл. Включаешь r_speeds и вертишь башкой, чтобы функ_валл пропадал из поля зрения. Ну и смотришь какой счётчик меняется.
 

Cavador

New member
Dec 8, 2007
1,367
12
0
обязательно надо красить, просто иметь хорошую привычку сначала NULL, а потом уже окрашивать; дело не в том, что компилятор обрежет а, что нет, это просто как хорошее правило.
 
Вот мне издревле было интересно, как же так движок умудряется рисовать вполики гораздо медленней еполиков. Не может ж быть, что вся разница только из-за налепленных на них лайтмап?
 

npocTo_LaM

New member
Oct 27, 2012
1,474
47
0
Имхо, текстурой null стоит закрашивать поверхности (при условии что окрашиваемая поверхность не видна игроку) соприкасающиеся:
- браш + func_detail - красим поверхность браша, поверхность func_detail компилятор сам удалит:
- браш + брашевая энтитя - красим стороны у обоих;
- брашевая энтитя + брашевая энтитя (пример: func_wall + func_wall) - красим стороны у обоих;
- браш + браш, покрытый текстурой sky - красим сторону браша, текстурой скай его покрывать можно, но не нужно, так как полигон все таки останется.
Внешняя поверхность карты и поверхности брашей не видные игроку в игре (пример крыши домов) - красим текстурой null.
Тратить время специально на закрашивание отдельный поверхностей, стоит когда есть проблемы с в_поли. В принципе, выполнять выше описанное - это скорее правило хорошего тона :) да, компиляция идет быстрее в любом случае, но не всегда это заметно. На сложных картах, как насыщенных деталями, так и сложных по архитерктуре (не обязательно с точки зрения игрока, в основном с точки зрения движка) - ОБЯЗАТЕЛЬНО!
Вообще оптимизация нужна и по части моделей, правда лимит там шире.
Как-то так, возможно какой то случай забыл, можно дополнить, если кто вспомнит.
Примечание: построение карты из брашей покрытых текстурой null - это скорее привычка или один из способов брашворка, если нормально и правильно стыковать браши, то это не обязательно.
 

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
Я вам предлагаю провести нехитрый эксперимент:
взять карту где нет ни одной текстуры NULL. Сделать её резервную копию. И копию закрасить нуллом там где вы привыкли обычно красить. Скомпилировать оба варианта и сравнить wpoly.
 

npocTo_LaM

New member
Oct 27, 2012
1,474
47
0
:) ну что привел выше, это отчасти влияет на в_поли, думаю в зависимости от сложности карты разница будет от 25 до 100-150 в_поли, опять же смотря какие методы снижения в_поли были использованы, они то больше влияют на полигоны. Замена текстуры sky на null, описанная выше, лишь слегка отразится на времени просчета освещения при компиляции, на в_поли никак не повлияет.
 

Flash

Administrator
Sep 21, 2004
16,695
41
2 Дядя Миша:
Я такой "эксперимент" проводил более десяти лет назад, когда пришлось карту оптимизировать, ибо вполи сильно велик был. Мне тогда пришлось выделить всю карту и махом перекрасить в нулл, красить всё заново было очень утомительно, но результат того стоил, с тех пор я и взял себе за привычку строить изначально нулле.
 

FiEctro

Ведущий
Jul 28, 2006
17,139
33
2 Flash:
Так CSG всё обрежет же, крась не крась нуллом, а результат будет один и тотже. Исключение разве что составляют фейсы соприкасающиеся с небом, наверное как раз из-за них ты и получил различные результаты.
 

Enimakanaon

Незабаненный
Jun 30, 2015
1,046
41
Я вам, любителям мерять карту вполями, вот что скажу. У новых компов проблем с картами на голдсорсе нет. У меня вот даже арканос в самом сочном месте не проседает ничуть. А у старых компов отчего-то совсем другие проблемы, нежели вполи. Мигающие источники света, анимированые спрайты, стекла-решеточки, и прочая лабудень, и особенно эти ваши любимые модели, сжирают фпс на старье намного сильнее, чем даже экстремально высокие показатели wpoly.

Постоянно имея в своем распоряжении много старых машин, плюс множество знакомых мапперов под ХЛДМ, которые тоже играют с чего придется, я заметил, что вполи в 95% современных случаев - самое последнее, из всего, что может уронить фпс. До смешного доходило, у игроков на слабых машинах лагала карта коробка, на которой вообще ничего не было, а вполи был в пределах 200. Причина нашлась - тормозило от оружия и патронов (!) слишком густо наваленных в эту коробку.

Так что хватит бегать там, с r_speeds 1, и меряться вполями. Это чушь собачая, а не оптимизация.

Методы оптимизации были всю жизнь одинаковые, описаны в доисторические времена, и актуальны до сих пор. Красить нуллом помогает, но очень слабо. Больше всего лишних вполи вылезает не от незанулленых обратных сторон брашей, а от разбиения брашей брашами. Там реально счет на тысячи лишних полигонов, от которых можно и нужно избавляться. Очень важно знать, что браши внутри ентити также режут друг друга - о такой подставе многие и не подозревают, считая, что если они перегнали что-то в func_wall (func_detail), то браши друг друга больше не бьют. Авотфиг! Надо делать слоеный пирог из двух-трев воллов, чтобы внутри одного волла браши друг друга не трогали - если хочется полностью избежать разрезания.

И краеугольный камень оптимизации - это собственно строение карты. Если карта состоит из огромной открытой коробки, где все на виду, то там оптимизировано не будет, хоть тресни. Надо помнить, под какой устаревший отстой мапишь, и ограничивать игроку обзор, чтобы он слишком многое не видел.

Способы определения "оптмизированности" карты, которые принято, с подачи дмитрича, использовать - совершенно никуда не годятся. Даже если вы не будете все измерять параметрами wpoly\epoly, а по правильному напишете какой-нибудь fps_max 1000 (fps_override 1 на стиме) , и будете смотреть, где фпс просаживается от тысячи на вашем суперновом задротском компе - это объективно ни о чем не скажет, потому что, как я уже писал, узкие места у старых компьютеров и у новых - разные.

Потому просто заведите себе друзей с хреновыми машинами, или выкладывайте карты на КСМ - он же для этого и нужен. Пускай народ высказывает, тормозит или нет. Надежнее способа нет. Если не тормозит у того, для кого собсно карта - нафига тогда что-то оптимизировать? :)

[ADDED=Enimakanaon]1488622220[/ADDED]
Собственно, браши очень просто переводятся в модель. Зачастую можно некоторые брашевые конструкции целиком переводить в модель, инструментов для этого множество.

Сам я карты тоже делаю сначала нуллом, но не потому что очень волнуюсь об оптимизации, а потому что когда начинаю браши мучать, то не знаю еще, во что их буду красить.
 
Last edited:

Дядя Миша

Супер Модератор
Mar 28, 2010
15,347
235
0
Кубань
Очень важно знать, что браши внутри ентити также режут друг друга - о такой подставе многие и не подозревают
В моих свежих компиляторах есть параметр zhlt_nocsg 1 который отключает такое повидение. Прописывать в настройки энтити.
 

npocTo_LaM

New member
Oct 27, 2012
1,474
47
0
Как бы вопрос "как правильно оптимизировать карту" в ветке не обсуждался.
Их (способов) достаточно много, некоторые в стародавние времена были не доступны (не известны) большинству мапперов (типа замена конструкций из брашей на модели).
Само собой понятно, что чем мощнее комп, тем меньше просядет фпс и тем быстрее фпс будет выровнен и тем менее лаг будет заметен игроку. Опять же карта может не лагать при тестовом прогоне и может залагать при сетевой игре. И такая ситуация возможна даже на весьма не кислом компе. Так что, опять же имхр, при необходимости карту все же лучше оптимизировать, а не полагаться на то, что у всех достаточно мощные компы и лагов никто не заметит. А то, не ровен час, повторится ситуация с первый крайзисом :)
Да, движек далеко не новый, но проблема в_поли есть и в сорсе, просто там лимит больше и появились дополнительные способы "оптимизации" карты (снижения в_поли).
По поводу устарелости "оптимизации по Дмитричу", основные работают и по сей день, причем даже в том же сорсе. Так что, имхо, если маппер будет пользоваться хотя бы ими будет уже весьма неплохо.
 

Hypax

Парам парам пам! ПАМ!
Jul 18, 2013
563
33
Соприкасаемые поверхности брашей,после компила обрезаются даже если не красить null-ем,во всяком случае на vhlt33.Когда тестил,на wpoly не повлияло,как и на base patches.Проверить это не сложно,особенно если в jack-e,там для ленивых даже комнатка тестовая создается сама :)

И не следует пренебрегать w_poly,а то начнут щас делать все мелкие детали на карте брашиками :D и выльется это в 100000+ вполиков,а на каждый крутой комп,найдется еще более круче.
 

Enimakanaon

Незабаненный
Jun 30, 2015
1,046
41
npocTo_LaM said:
ситуация с первый крайзисом

Гонево это все, про первый крайзис. Там была ОЧЕНЬ хорошая оптимизация, которая не снилась многим современным играм. Я его проходил без всяких тормозов, на очень скромном, даже по меркам того времени компе (GF 8800 GS, Pentium IV 2.4, 512 RAM).

Утку про то, что там плохая оптимизация, запустили после того, как толпы ламеров на своих убер древних развалинах поставили галочку ULTRA напротив всех настроек графики (мошнблюры, супертурбоантиалисинг в овер 9к проходов и прочая лабуда, которая была создана только для того, чтобы было чем нагрузить супер-мощные видеокарты) , и начали выть в интернетах про то, что у них 10 фпс.

Но меня тогда еще жутко рассмешил ответный ход разработчиков - они быстренько склепали Crysis Warhead, и сказали хомячкам - мол играйте в вархеад, там все оптимизировано! И хомячки такие, в сотнях рецензий, написали "вау, играл в вархеад, там все очень круто, не тормозит!". Включая, кстати, небезызвестную Игроманию. (Я с рецензий Игромании всегда угарал, но та особо сочно отражала весь уровень компетентности их авторов).

А вся оптимизация Вархеада заключалась в том, что убрали галочку ULTRA.



В моих свежих компиляторах есть параметр zhlt_nocsg 1

Это круто. Но, с другой стороны, неудобно, что сразу для всей карты. Бывает, что как раз надо, чтобы браши внутри волла порезали друг друга, и дали правильную красивую тень.

[ADDED=Enimakanaon]1488626651[/ADDED]
начнут щас делать все мелкие детали на карте брашиками и выльется это в 100000+ вполиков

Не сделают. Лимитов не хватит.
 
Last edited:

rave

New member
Apr 10, 2011
254
38
1
0
2 Enimakanaon:
Просто у тебя не было ноута с Intel HD Graphics, которые очень не любят goldsrc (например, в cs:go на максимальных настройках fps выше чем в 1.6).
 

Game Server

CSM TV

Page QR Code

QR Code

Donate Campaign

Total amount
$0.00
Goal
$25.00

Latest profile posts

TestUser wrote on TRUP@C's profile.
Master?
TestUser wrote on TRUP@C's profile.
Hello Father

Members online

No members online now.

Discord