Ну чтоже. Вот мы вплотную и подобрались к самой главной, так сказать фундаментальной проблеме всего движка. К формату его уровней. Это краеугольный камень всего. От этого зависит как на уровне взаимодействуют монстры, как отсекается видимость, насколько надёжна физика и насколько быстро всё это рендерится. Ни один из существующих форматов, близких по духу к кушным движкам не отвечает поставленным требованиям. Возможно кто-то просто не задавался таким вопросом или наоборот считает, что там всё в порядке. Я на это отвечу следующим образом: если сознательно ограничить свою фантазию колидорами из кваки - то конечно жы проблем нет.
Перечислю здесь основные проблемы, применительно к форматам уровней Quake1 и Quake3 (я их выбрал как базовые, которые знаменовали смену поколений). Но сперва обозначу общие проблемы, которые нас подстерегают в 2019-м году, если мы решили строить наши уровни вокруг BSP-дерева:
1. Очевидно, что BSP-деревом можно описать любую солидную структуру. Для ускорения поиска и пересечения. Но есть проблема. Чем больше полигонов в структуре - тем больше дерево. В какой-то момент возникает ситуация, когда нережущие алгоритмы управляются на порядок лучше режущих. К тому же BSP существует в варианте, который ничего не разрезает и там оно не сказать что блещет производительностью. К тому же само его построение с уникальными полигонами на ноде может занять чертовски много времени. Ну с этим можно бороться сделав какие-то изначальные допущения. Сам алгоритм особо не покрутишь.
2. Из преведущего пункта очевидно вытекает, что наилучшим образом с BSP дружат браши - замкнутные конвексные структуры, которые по своей сути обладают одним интересным свойством - их легко редактировать, легко текстурировать и они хорошо держат точность, чтобы на базе такой геометрии можно было строить абсолютно замкнутые уровни и генерировать порталы видимости в автоматическом режиме, а не заниматься расстановкой функ_окклюдеров. Но есть у брашей и серъезные минусы. В силу специфики их текстурирования, из брашей практически нереально построить tri-strip объекты для ускорения отрисовки. Невозможно склеить вертексы, когда на каждой стороне браша какая-то своя отдельная текстура. В моделях такое практически не встречается, хотя разумеется и возможно. Ну просто там изначально другой подход к текстурированию. Из чего вытекает следующее правило - много брашевой детализированной геометрии будет тормозить независимо от того как мы её оптимизируем. Невозможность использования стрипов снижает конечную производительность от 1/3 до 1/2 от возможной скорости. Из чего сам собой напрашивается вывод - использовать брашевую геометрию только для грубых набросков, не увлекаться.
3. BSP обладает приятной возможностью создать офлайн-массив видимости, т.е. заранее знать из какого сектора уровня какой будет виден. Не в последнюю очередь благодаря автоматической генерации порталов. Собственно это вообще единственный способ иметь такую видимость. Все остальные способы базируются на уже отрендеренных полигонах и на PC имеют лаг, связанный с получением данных непосредственно из видеокарты (на приставках ЧСХ лага нет, там другая архитектура). Это обходится либо созданием упрощённого софт-рендера, который работает в отдельном потоке, либо забиванием на оптимизацию, как в юнитях разных. Но всё это имеет смысл только коридорной геометрии. На открытых пространствах толку никакого, как вы понимаете.
Очевидно что полагаться на один PVS нельзя, требуются дополнительные способы.
4. Возможность трассировки полигонов без построения каких-то дополнительных ускоряющих структур. Очень сильно завязано на детализацию, как вы понимаете. Плюс сам факт разрезания полигонов не полезен для рендеринга. Но можно решить построением нескольких деревьев и разных наборов видимых сурфейсов, хотя это и приводит к увеличению размера карты. Можно построить чисто аксиальное дерево, однако в плане увеличения производительности от него немного толку.
5. Надо так же отметить, что вышеописанные проблемы при отказе от BSP, вообщем-то никуда не деваются, а некоторые становятся вообще принципиально неразрешимы, типа рассчёта PVS. Отказ от брашей нецелесообразен, поскольку дизайнеру часто требуется создавать какие-то зоны, водные пространства, триггеры, навмешы. Брашы для этих целей подходят идеально. Как там народ делает триггеры в движках без брашей остается только догадываться.
Добавлено 22-09-2019 в 16:55:
Теперь по списку проблем в уже известных форматах.
Применительно к Quake1:
1. Слишком подробное дерево. Это хорошо для реализации сверхбыстрой точечной трассы, но плохо для визуализации, если мы собираемся использовать дерево. Впрочем для рендеринга можно использовать другие собирательные структуры, ну скажем нечто вроде суперлифов, которые включают в себя основные лифы с видимостью и детальные лифы с такой же видимостью.
2. Фиксированные хуллы. На основе информации, имеющейся в карте возможно построить коллизию для произвольных фигур, но есть одна проблемка - туда не попадут клипбрашы. Восстановление клипбрашей из соответствующих деревьев тоже не будет точным, поскольку для разных хуллов деформированная геометрия уже выглядит не так как для точечного (ну вы это могли видеть, включив визуализацию хуллов).
3. Raw-лайтмапы. Ну это легко исправить, немного доработав формат. Минус таких лайтмап в том, что они провоцируют появление швов на сложной геометрии, состоящей из треугольников. Если кубать строго квадратными брашами, то никакой проблемы нет. Но брашевый ландшафт из треугольников провоцирует появление швов на лайтмапах, несмотря на все метды противодействия им.
4. Нету ареапорталов. Ну здесь я даже не знаю, так ли уж они актуальны в наше время. Мне кажется этот подход уже устарел и не нужен. Он только усложняет получение информации видимости в различных частях рендерера, т.к. необходима синхронизация состояний, плюс лишняя нагрузка на сеть.
Применительно к Quake3:
1. Брашы вместо клипнодов. Может показаться странным, но по некоторым причинам код трассировки брашей неоднозначен. Есть там такая проблемка, при которой с одной стороны браша игрок проникает в него на эпсилон, а с другой наоборот - не достает. Решается через параметр overbounce, который отталкивает игрока в PM_FlyMove. Как в ку2, так и в ку3. Я не знаю, может вальва в сорсе и решила эту проблему (там не юзается овербаунс), но в Doom3, Кармак от греха вообще не использует коллизию по брашам, они там только для определения контентсов.
2. Упрощённое дерево. Баланс между избыточностью и скоростью. Для рассчёта PVS и рендеринга дерево оптимально, для трассировки производительностью не блещет, из-за чего возможно лайтмапы считаются достаточно медленно. Впрочем это можно решить, построив в лайтмаппере какую-то кастомную трассу.
3. Типы поверхностей. Нет юниформности, мы должны с каждым видом действовать по своему. С брашами так,с патчами эдак, с фларесами иначе. В качестве эксперимента может это было и неплохо, но вообще это очень неудобно. После компиляции мы не должны знать что это было раньше патч или модель, для нас это должен быть просто полигон. Впрочем допустимы некоторые хинты, которые позволят загружать группы полигонов в VBO единым целым, например, если из них реально построить стрипы (для патчей или моделей). Ну вообщем достаточно неоднозначная вещь.
4. карта не содержит в себе информацию о рёбрах, которая могла бы нам пригодится, ну например для физики, или Ксероксу для создания теневых объемов
Подводя итоги, хочется обратить ваше внимание, что ни тот ни другой из форматов в чистом виде нам не подходит. И модификация в любом случае будет достаточно серъезным делом. Основной вопрос заключается в том, какой из форматов взять за исходную точку для дальнейших доработок.
Собственно оба подходят в равной степени, надо решить нелёгкий вопрос, что будет быстрее в плане имплементации, что займет меньше времени.
Помню, в серьёзном сэме были огромные пространства и при этом отличная производительность. Или это только за счёт того, что на тех пространствах нихренашеньки кроме монстров не было?
Пространства сами по себе значения не имеют. Имеет значение только поликаунт. Вон в первом дууме ставят на карту сто тысяч монстров и это всего-навсего 200 тысяч треугольников, монстры-то спрайтовые!
Вот и не тормозит. Вспомнил забавную штуку, вот как раз связанную с пространствами. Есть такая единственная игра для Unigine - называется Cradle. При старте мы спавнимся в своей хижине. Хижина жутко интерактивная. Там все предметы настоящие. Это значит что в любом комоде, мало того, что можно выдвинуть любой ящик, так еще и в этих ящиках лежат настоящие итемы, которые можно брать. Ну вообщем внутри хижины поликаунт зашкаливает просто. А я тогда рассуждал в точности как ты - уж если в индоре такие тормоза, то в аутдор вообще соваться без резона. Но я набрался храбрости, выглянул и офигел. Потому что гигантский аутдор (5-7 кв.км) ВООБЩЕ не тормозил, а чему тормозить, если это был пустой ландшафт?
Дикие разрезы, выпадающие полигоны и дыры в клипбрашах. Настоящий комшмар мэппинга — уйма времени уходит на то что бы не было видимых щелей и косяков, и невидимых препятствий и дыр. И, естественно, чем геометрия детальней и чем сильнее отличается от аксиальной, тем больше вылезает проблем. Даже p2st хоть и дают результат лучше всего, но всё равно требуют повышенной внимательности к таким деталям.
Дядя Миша писал: если сознательно ограничить свою фантазию колидорами из кваки - то конечно жы проблем нет.
Ничем не ограниченная фантазия во все времена приводила к эпичным провалам.
Цитата:
Дядя Миша писал: Чем больше полигонов в структуре - тем больше дерево.
Это не совсем верно. Ку3шное дерево зависит только от структурных полигонов, но не детальных.
Цитата:
Дядя Миша писал: из брашей практически нереально построить tri-strip объекты для ускорения отрисовки.
Никогда не понимал этой фанатичной сакрализации три-стрипов, по крайней мере со времён первого GeForce, т.е. появления TnL-кэша.
Цитата:
Дядя Миша писал: На открытых пространствах толку никакого, как вы понимаете.
Очевидно что полагаться на один PVS нельзя, требуются дополнительные способы.
Поиграй в те же TES4, TES4 или Фоллауты. Там мухи отдельно, котлеты отдельно. В смысле, есть ландшафт с чем-то вроде ROAM и лодами, а есть калидоры с PVS, а между ними - загрузки с прогрессбаром. И людей это уже 10 лет как вполне устраивает.
Цитата:
Дядя Миша писал: Как там народ делает триггеры в движках без брашей остается только догадываться.
Я в 2001 году делал триггеры под первый UE без брашей. Как-нибудь напишу мемуары об этом.
Цитата:
Дядя Миша писал: Нету ареапорталов. Ну здесь я даже не знаю, так ли уж они актуальны в наше время. Мне кажется этот подход уже устарел и не нужен. Он только усложняет получение информации видимости в различных частях рендерера, т.к. необходима синхронизация состояний, плюс лишняя нагрузка на сеть.
Вот здесь - долго смеялся.
Цитата:
Дядя Миша писал: карта не содержит в себе информацию о рёбрах, которая могла бы нам пригодится, ну например для физики, или Ксероксу для создания теневых объемов
Пригодиться они могут примерно как ворона эстонцу из анекдота.
А всерьёз писать про теневые объёмы в 2019 году просто неприлично.
Цитата:
nemyax писал: в серьёзном сэме были огромные пространства и при этом отличная производительность.
Там полигонов было, по ощущениям, меньше чем в первой халфе, на все эти огромные пространства.
Цитата:
Дядя Миша писал: Вон в первом дууме ставят на карту сто тысяч монстров и это всего-навсего 200 тысяч треугольников, монстры-то спрайтовые!
Там ИИ примитивный, вот и не тормозит. Сделай в халфе 100 тысяч монстров ВООБЩЕ без модельки - и офигеешь от тормозов сервера.
XaeroX писал: Ку3шное дерево зависит только от структурных полигонов, но не детальных.
это и так подразумевается.
Цитата:
XaeroX писал: Никогда не понимал этой фанатичной сакрализации три-стрипов
Да вон ЧАЭС без стрипов с лайтмапой - ФПС вдвое упал.
Цитата:
XaeroX писал: Там ИИ примитивный, вот и не тормозит
Да понятно что ИИ. Но я про полигоны.
Добавлено 22-09-2019 в 21:46:
ИИ там кстати как в квейке. Но в 2Д.
Добавлено 22-09-2019 в 21:58:
Я тут пытаюсь решить задачку с материалами. Кутришные шейдеры очевидно устарели и не конают. К тому же там все типы встроенные.
Можно просто скопипастить материалы из паранои, но встанет вопрос - а как подключать кастомные glsl. И передавать в них параметры.
В параное без вариантов. Но в NT надо сделать подгрузку кастомных GLSL шейдеров. И тогда уже мутить что угодно со спокойной душой.
Была у меня такая любопытная имплементация кажется в 2015-м году. Для NT как раз и делалась.
Расскажу немного о новой концепции материалов. Она не совсем новая, я её придумал еще в 2015-м году, но тогда посчитал излишним к реализации, поскольку разработка NT застопорилась, а для паранои она бы была черезчур сложной. В чём основная идея?
Материалы у нас, как вы знаете основываются в первую очередь на возможностях рендерера. До появления программируемого конвейера вполне логичным было бы просто охватить все возможные комбинации и стадии фиксированного конвейера и задавать рендеринг довольно простым языком, который Кармак реализовал еще в Quake3. Впоследствии, когда появился бамп и Cg, эта система была пересмотрена в сторону упрощения, но всё равно не избавилась от духа FFP. В настоящее время её использование носит негативный характер. Там где требуется создать простой материал она избыточна, а там где материал кастомный что либо реализовать затруднительно. Собственно, этот момент отразился уже в Wolfenstein 2009, там дуумтришную систему материалов полностью перепахали в сторону гибкости и использования шейдеров. В чём заключается моя идея?
Нам не надо пытаться описать в материале принципы рендеринга, это реализуется в GLSL, в стандартных или пользовательских шейдерах.
Всё что нам надо - это настроить переменные и юниформы, однако как вы понимаете, прописывать каждый раз пачку переменных для каждого материала каждой текстуры - сомнительное удовольствие. На помощь приходят шаблоны с предустановленными дефолтными параметрами.
Однако и тут возникает вопрос - надо ли нам каждый раз прописывать пути к каждой текстуре, ведь мы не сможем указать эти пути явным образом в шаблоне? Явным образом нет, но мы можем построить наш путь из переменных значений, таких как <wadname>, <modelname>, <mapname>. Приведу пример шаблона и материала, построенного с его использованием. Это ни в коем случае не окончательный вариант синтаксиса, один из текущих:
Здесь image создаёт юниформ-сэмплер для GLSL и грузит текстуру в случае наличия дефолтного пути, который формируется из переменных, заключённых в треугольные скобки. Текстуры со знаком доллара - это внутренние, которые движок подставляет по смыслу. ну разумеется, каждому полигону достанется именно своя лайтмапа, а не какая-то абстрактная. $screendepth будет содержать копию экрана глубины, полученную перед рендерингом меша, содержащего в себе именно этот материал. vec2 u_detailScale = "$matdesc/detailScale"; возьмёт дефолтные значения из materials.def. Сам materials.def не расширяемый, его параметры определеные заранее, ну вы его видели в параное. Там всякие звуки-партиклы при попадании пули в стенку, звуки шагов, декали, физические свойства материала. Ну и возможность задавать некоторые физичные параметры разом для всего шаблона, ну скажем smoothness или detailScale, хотя можно и просто прописать константу. Впрочем, еще раз скажу - это ни в коем случае не окончательный вариант, это просто для понимания как будет выглядеть система.
Дядя Миша
Допустим чувак захочет реализовать подсветку досягаемого объекта под кросс-хером. Как ему поможет такая система материалов? Ведь для конкретного объекта не выставишь униформ.
nemyax всё зависит от тех переменных, которые мы передаём в шейдер. Я же не сказал, что можно будет прописать только константы.
Будет привязка как к глобальным, так и к локальным переменным.
Но синтаксис я пока еще не продумал.
Опять же, можно наделать много шаблонов на все случаи жизни и использовать их в разных материалах, на ходу перегружая те или иные параметры. В основе системы лежат два простых соображения:
1. чтобы не надо было каждый раз прописывать одно и тоже для кучи материалов или в крайнем случае это был минимальный набор данных.
2. чтобы любой из заданных параметров было возможно перегрузить. В том числе - создать новый параметр, который в шаблоне вообще отсутствует.
22-09-2019 13:55
