Про виз немного расскажу. Почему его алгоритм не менялся с незапамятных времён и в принципе подходит для любых вариаций на тему. Виз, как вы помните, не имеет дела с деревом. Он имеет дело с некоторыми замкнутыми примитивами, которые соеденены между собой порталами. Сам примитив может быть как конвексный, так и не очень. Важно чтобы он был полностью замкнутый - это проверяется еще на этапе построения BSP. Если мы оперируем лифами для первой кваки - примитив очевидно будет конвексный.
Для простоты представим его как аксиальный, некоторые стороны будут порталами. Каждый портал имеет две стороны, или точнее говоря - является проходом между двумя лифами. Portal flow - это поток, который идёт точно по размерам портала. Допустим в соседнем лифе напротив портала - солидная стена (для виза это выглядит просто как отсутствие портала на противоположной стенке), а портал находится под углом 90 градусов (коридор повернул). Тогда этот лиф помечается как видимый, а вот уже следующий за ним - невидимый. Впрочем там проверка конечно более сложная, т.к. учитывается видимость для позиции, а не для направленного взгляда (а для порталов видимость оптимально считать именно через попадание во фрустум, но их блин слишком много в классических форматах от Кармака, чтобы налиту это делать, хотя в Darkplaces есть реализация такого подхода). Плюс в том, что видимость считается полностью автоматически. Минус - в том, что дерево строится исходя из минимального кол-ва разбиений, поэтому отсечение видимости порой выглядит очень странно. Чтобы хоть как-то это исправить ввели хинт-брашы, которые заставляют сделать разрез. Прикол в том, что мы не гарантируем, что получившаяся нарезка сделает именно то, что нам надо, это хорошо работает только на самой простейшей геометрии. Да и народ, зачастую не в курсе, что хинты увеличивают кол-во полигонов. А когда это понимают - отказываются от их использования.
Ну так вот - в ку2 уже, когда были введены детальные брашы, чтобы заставить виз работать быстрее, лифы объединили в кластеры. Это очень просто - те порталы, которые находятся между двумя такими лифами уничтожаются, а остальные принадлежат одному кластеру. Кластер по идее уже может быть неконвексным. Принцип работы виза не поменялся.
Ну и наконец то, что я делаю сейчас - вместо кластеров арии, которые задает левел-дизайнер ручной расстановкой порталов. Хотя в некоторым смысле это регресс, т.к. предполагает ручную работу, но на самом деле он практически неощутим. На те же самые места, куда предполагается расставить порталы, дизайнер бы точно так же влепил хинт-брашы. Причём результат от их использования был бы гораздо менее очевиден.
А тут работает простое правило - если человек видит результат своих усилий, ему это проделывать совсем несложно.
Ну и сам рассчёт виза при таком подходе не может занимать больше секунды даже на самых слабых машинах.
makebsp практически готов и я им очень доволен. Карты собирает очень быстро, формат достаточно абстрактный (к примеру компилятор не заглядывает в контентсы примитивов и вообще там мало встроенных параметров), а все компиляторные энтити вынесены в скрипт и дизайнер может наделать своих, какие ему надобны. Пример:
C++ Source Code:
1
// any entity passed through this commands first
2
"default"
3
{
4
// rename keys to default
5
renameKey( "modelscale", "scale" );
6
renameKey( "modelscale_vec", "scale" );
7
8
if( angle )
9
{
10
// support quake legacy
11
convertYawAngle( "angle", "angles" );
12
removeKey( "angle" );
13
}
14
15
// load entity transformation (may be identity)
16
loadTransform( "origin", "angles", "scale" );
17
18
// any entity from embedded level should be gone structural brushes
То есть эти энтити больше не захардкодены внутри компилятора.
Виз встроен внутрь, работает очень быстро - несколько милисекунд, как правило. Ну оно и понятно - даже на самых простейших картах, типа c1a0d из халфы, кол-во порталов на дереве могло легко достигать 4-5 тысяч. А тут мы имеем дело с порталами, которые расставляет сам дизайнер и вероятность того что он раставит более ста штук - минимальна. Да и нет необходимости ставить их столько. Принципы прежние - там где вы раньше ставили хинт-брашы, теперь ставите порталы, можно даже конвертнуть старые хинт-брашы в порталы, просто переназначив им материал. Теперь на очереди освещение, утилита называется dolight как в сталкере
Это что получается, теперь после компиляции вся карта целиком рисоваться будет, если эти браши не поставить?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: теперь после компиляции вся карта целиком рисоваться будет, если эти браши не поставить?
именно так. Но поскольку сурфейсы сгруппированны по материалам и вся геометрия лежит в видеопамяти, мы наблюдаем тот самый эффект, о котором так долго твердили большевики - это не сильно медленее карт с визом, а чаще - даже быстрее. Во всяком случае это касается обычной лоу-поли геометрии до полумиллиона полигонов в кадре.
Добавлено 03-07-2020 в 12:03:
Но с порталами конечно еще быстрее.
Добавлено 03-07-2020 в 12:11:
А да, виз естественно AI использует, чтобы монстры не видели игрока через полкарты. И теперь есть точный контроль над тем, что именно перейдет на следующий уровень, т.к. порталы вручную ставятся.
А зачем БСП тогда вообще нужен? Загружай напрямую obj какой нибудь.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
BSP еще как нужен. Он же удаляет внешние полигоны, Portal Flow первичный делается через него, создаются площади, наконец индексация пространства для коллизии и для поиска параметров. Но в данном случае дерево никак не влияет и не ограничивает дизайнера, как это было в халфе.
Добавлено 03-07-2020 в 14:44:
Так, ну чтожы. Наконец-то лайтмапы. Лайтмапы хранятся всегда снаружи в виде DDS-картинок, их можно удалить, если предполагается использование только динамического освещения, их можно пересохранить в bmp и нарисовать какую-нибудь каляку-маляку. Ну и всё в таком духе.
Думаю на каждую страницу придётся две лайтмапы - RGB+shadow и DeluxVectors. Конечно можно заюзать float-лайтмапы и сохранить там, например сферические гармоники или разложенные кубемапы, но мне бы для начала получить обычное освещение. Тому шо проект полностью пустой, лайтмаппер с нуля пишется. Здесь мне поможет лайтмаппер моделек из паранои, написанный в прошлом году. Он же как раз для трианглов делался, а у меня в этом формате все модели - трианглы. Есть и второй момент - TJunc может там добавить дохрена излишних точек, то есть визуально полигон квадратный, а внутри чёрт знает сколько треугольников.
Понятное дело, если каждый такой треугольник освещать отдельно. во первых будут швы, а во вторых - прощай индексация вертексов. Собсно, это и есть самая сложная задача - построить такую развертку, которая бы учитывала текущие шареные вертексы, удалить из нее внутренние рёбра.
Нечто вроде развёртки для моделей. Вероятно придётся несколько снизить эффективность упаковки вертексов, разбив их по принадлежащим материалам. То есть все шареные вертексы смогут принадлежать только лишь одному материалу. Иначе эта развёртка будет размером со всю карту и такое далеко не всегда получится уместить на страницу.
Ну в obj тоже нет внешних полигонов, если ты их специально не сделаешь.
>> Portal Flow первичный делается через него, создаются площади, наконец индексация пространства для коллизии и для поиска параметров.
Подобные вещи вроде ты делал при первом запуске карты для физики
>> Собсно, это и есть самая сложная задача - построить такую развертку, которая бы учитывала текущие шареные вертексы, удалить из нее внутренние рёбра.
Ну вот с моделькой бы такой проблемы не было, любая сгенерированная развертка не эффективна с точки зрения оптимизации и даёт очень противоречивые результаты.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Ну и да, пока не забыл, давайте уже окончательно разжую как виз работает, чтобы больше не возвращаться к этой теме.
Итак, у нас есть некоторая геометрия (важно, чтобы она была полностью замкнутой). Мы к ней применяем BSP-разбиение и получаем ту же самую геометрию, которая кое-где рассечена секущими плоскостями. И у нас теперь есть лифы. Для ку1\хл, лифы конвексные, для ку3 - произвольные.
Но это не важно. Теперь мы для наших лифов строим порталы. Порталы строятся очень просто - как вы знаете, если взять браш точно по размерам дерева и рассечь его всеми плоскостями дерева (но разумеется соблюдая очередность сечения от корневой ноды к лифу), то те обломки брашей, которые дойдут до лифа - превратятся в точное подобие тех брашей, которые изначально сокрыты в дереве (часть видимых полигонов браша содержится уже в самом лифе). С порталами мы поступаем аналогично - создаём геганцкий портал размером с дерево (под размером "с дерево" я имею в виду tree->mins, tree->maxs, т.е. bbox всех полигонов, которые в него включены) и сечём их нодами. Портал после рассечения удаляется и заменяется на два. А там еще на два ну и так, пока не дойдем до лифа. Некоторая сложность тут в том, что во первых нам не нужны порталы в нодах, поэтому когда портал делится надвое секущей ноды, он перемещается в детей ноды, а из секущей ноды - удаляется, во вторых порталов же обычно две штуки - прямой и обратный. Впрочем, кмк, Кармак написал этот код в 95-м штоли году и он с тех пор ничуть не менялся, может быть поэтому он сложноват для понимания. Ну не суть.
Да, единственный момент уточню, в функции MakeNodePortal каждый портал клиппится при помощи соседей, что может ввести в заблуждение. Но не будем забывать, что соседней портал - это просто такая же секущая от соседней ноды, т.е. абсолютно тот же принцип, что и с созданием брашей, но даже проще, потому что портал это плоскость, а браш всё-таки должен получиться замкнутый.
Так вот. Теперь у нас есть лиф с порталами. Тут важно понять вот какую вещь, для простоты будем оперировать исключительно конвексными лифами в виде кубега. Вот у нас кубег и все шесть его сторон покрыты порталами. Что это значит? Это значит, что из этого лифа можно видеть в шесть разных направлений. Но представим, что этот лиф в углу комнаты, и соответственного у три стороны - видимые поверхности, а еше три - порталы. А теперь представим что лиф у нас очень жирный и занимает весь тупик, откуда только один выход (вполне реальная ситуация). И у него пять солидных сторон, а шестая - портал.
А теперь, собственно то фундаментальное понятие\допущение, на котором и работает виз. Поскольку у нас пять сторон солидных, то мы можем видеть только по направлении из шестой стороны-портала. И, как вы понимаете, мы никоим образом не можем заглянуть за все эти стороны.
Ну потому что наш портал из лифа не висит в ваккуме, а надёжно прилинкован еще к одному точно такому же лифу. А из того лифа допустим смотрят уже три портала и так далее. Вот почему и важно поддерживать замкнутость уровня, чтобы всё это не вытекло обратно на само-себя. Правда дырка в одном месте далеко не всегда приводит к общим утечкам, так что порой даже карты с дырками вполне нормально выглядят. Но как минимум с них не получится удалить наружные полигоны. Кстати наружные полигоны тоже удаляются очень просто - у нас есть глобальный аутсайд лиф (нулевой), который находится снаружи уровня.
То есть это как бы гигантский такой браш, который покрывает всю карту. Но если на карте нет утечек, то мы соответственно не сможем на него выйти изнутри. Внутренности определяются по наличию точечных энтить внутри карты, к слову. Другого способа нет. Поэтому если вы создали где-то пустую комнатку без единой энтити, то компилятор вам выдаст сообщение: no entities in open -- no filling или что-то в таком духе.
Те лифы, к которым не удалось добраться сквозь порталы, помечаются как внешние, мы можем их удалить из дерева вместе со всем, что к ним прилинковано.
Но вернёмся к нашим лифам. Поскольку для определения видимости нам достаточно держать в уме только знание о том, что там где нету порталов - там непроходимая стена, то и соответственно нет и никакой необходимости использовать для работы виза реальную геометрию.
Поэтому .prt файл содержит только список лифов (ну или кластеров или арий, не суть важно), к которым прилинкованы эти порталы. Виз, осуществляется в два прохода (просто для оптимизации и ускорения).
Сперва делается очень грубая прикидка, результаты которой сохраняются в карту в режиме -fast. Потом, по результатам этой прикидки порталы сортируются таким образом, чтобы в начале списка были порталы с наименьшим кол-вом потенциально видимых лифов, а в конце - с наибольшим. Это сокращает общее время рассчёта, но время рассчёта, как вы знаете из-за этого очень быстрое вначале и замедляется в конце.
Можете отключить сортировку порталов, будет более равномерно, но в целом медленее (-nosort в большинстве компиляторов). Смысл этой оптимизации в том, чтобы к моменту, когда мы добрались до рассчёта порталов, из которых потенциально видно очень много - все остальные были уже рассчитаны и мы могли использовать эту информацию, руководствуясь принципом парности - если из B не видно A, значит из A не видно B. Проще говоря мы исключаем двойную работу.
Ну и наконец остаётся, собственно просчитать видимость одного портала из другого. Это очень простая и быстрая операция, если бы не долбанный комбинаторный взрыв, когда кол-во проверок растёт в геометрической прогрессии. Собсно суть проверки - убедиться в том, какие из порталов попадают в окошко видимости нашего портала. Фишка тут в том, что поскольку видимость потенциальная, мы не можем использовать угол зрения, фрустум и так далее. Поэтому для портала, попавшего в наше поле зрения производится максимум обрезание по одной из плоскостей исходного портала. И вот этот уже кусочек (ну или целый, если весь попал), делает точно такую же проверку на видимость соседа. И если он больше ничего не увидел - здесь видимость для исходного портала и заканчивается. Ну а потом, когда вся портальная видимость проссчитана мы просто конвертируем портальную видимость в видимость лифов\кластеров\арий. Это очень простая операция. Смотрим какому лифу принадлежит портал и для него, соответственно выставляем биты тех порталов, которые принадлежат к соответствующим лифам.
Собственно портальные методы отсечения - вешь широко известная, но её обычно применяют в реалтайме, сделать предрассчёты придумал именно Кармак. Когда порталов не очень много, можно использовать куда более эффективное отсечение по фрустуму, собственно в Doom3 так и сделано. Но и в Darkplaces баловались чем-то подобным, хотя там польза от такого метода может опасно приблизиться по времени к скорости отрисовки и куллинг потеряет всякий смысл. Но это делалось для неотвиженных карт
А почему отсекают именно по фрустуму, а не рейкастом? Фрустум же идёт дальше препятствия, а рейкаст не будет рисовать то что за стенкой.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Дядя Миша писал: если взять браш точно по размерам дерева и рассечь его всеми плоскостями дерева (но разумеется соблюдая очередность сечения от корневой ноды к лифу), то те обломки брашей, которые дойдут до лифа - превратятся в точное подобие тех брашей, которые изначально сокрыты в дереве (часть видимых полигонов браша содержится уже в самом лифе).
А мы можем так декомпилировать карту для халфы? Или это вообще не в ту степь?
В построении лайтмап для треугольника, наиболее важный момент, конечно, это не строить лайтмапы, для, собственно, треугольников, а попытаться объединить как минимум пару треугольников в квадрат. Почему - понятно, если аллокать лайтмапу для треугольника, во первых будет перерасход места в атласе, во вторых, мы не сможем корректно записать для какого-то из шареных вертексов координаты лайтмапы - они же не совпадут, как вы понимаете. Да и общая скорость отрисовки ухудшается. В параное я такое сделал просто для теста, т.к. на тот момент впервые с этим столкнулся, всё же лайтмапы на моделях более сложный кейс, нежели на аксиальных квадратных плоскостях. Итак, в первую очередь, еще до, непосредственно, освещения и отрисовки, нам предстоит найти все смежные треугольники.
Эти треугольники могут лежать на одной плоскости, а могут и не лежать, это зависит от того, какая нормаль у вертексов. Если нормали разные, то вертексы продублируются и эти треугольники уже не станут смежными.
Почему мы не можем накладывать лайтмапы на такие треугольники надеюсь тоже понятно. Если нет - поясню. Вот типичная комнатка, у которой стены покрыты одной текстурой и образуют замкнутый квадрат. Как это спроецировать над лайтмапу? Ну очевидно, что никак, задача не имеет чёткого решения. Через тяжёлый матан можно найти один из допустимых вариантов, но я не люблю с таким связываться, т.к. подобные вещи никогда не сходятся к точному решению. Если задача нерешается при одних условиях, значит условия надо менять.
Итак, как же нам найти смежные треугольники? Самый простой способ - через текстурные векторы. Если у треугольника они совпадают, значит они все принадлежат одной площади. Заодно это исключает и вышеописанный случай с комнаткой. Следующий шаг - найти adjacent-рёбра. Хм. Приымыкающие, очевидно. Это можно сделать рекурсивно, через матрицу примыканий. И сформировать из них группы. В принципе этого можно и не делать, но тогда, если у нас где-то будет разрыв между треугольниками, на лайтмапе очевидно останется неиспользованное место, которое, тем не менее будет просчитано с освещением.
К слову сказать вышеописанный подход я уже опробовал и результатами остался доволен, например, он мне автоматически собрал в одну группу ландшафт на карте shaderlab_terrain. В оригинальном q3map2 требовалось в шейдере явно указывать, что это треугольники, принадлежащие одной группе, потому что к ним применено авто-текстурирование.
Вообще в лайтмаппере вот такие вот побочные вещи отнимают больше всего времени.
| IP: 
27-06-2020 09:07
