Есть еще вот какое соображение. Все Кармаковские компиляторы (и д3 не исключение), генерят скорее избыточное кол-во порталов, чуть ли не для отсечения каждого полигона. То есть порталы на дверных проёмах в этом кол-ве тоже присутствуют в обязательном порядке. Надо просто найти удовлетворяющие нашим требованиям и использовать их. А остальные проигнорировать. Крытерий очевидно один - портал всеми своими рёбрами должен касаться реальной геометрии.
Да уж, не так-то просто расставить эти виз-порталы автоматически.
Но я пока еще не теряю надежды.
Добавлено 07-05-2020 в 22:44:
текущая реализация имеет тенденцию ставить авто-порталы в двух случаях:
1. в дверных проёмах (ну собсно, как и нужно)
2. декоративных углублениях, типа всяких ниш (в чём нет никакого смысла).
Отличить нормальный проход от ниши практически невозможно. Увы.
Добавлено 07-05-2020 в 22:52:
Вероятно я просто начал не с того. Надо сперва оценить эффективность отрисовки сгруппированной по материалам карты, разбитой по материалам.
Взять тот же сипульчер. Там примерно 700 тыщ вертексов, 150 тысяч полигонов (треугольников триста-четыреста тысяч) и 252 текстуры (материала). В принципе для любой современной видеокарты это тьху. Это у нас в идеале 252 дипа (по материалам). Там безо всякого виза фпс должен быть приличным. Но это касается только рендеринга, естественно.
Дядя Миша писал: Отличить нормальный проход от ниши практически невозможно. Увы.
делать трассу вглубь портала, и если значение меньше n, то удалять портал?
Добавлено 08-05-2020 в 00:09:
Цитата:
Дядя Миша писал: 252 текстуры (материала)
а если одна текстура используется в нескольких материалах? Как в принципе оптимизировать переключения и синхронизировать их с порядком отрисовки? Или z-buffer все разрулит?
ну, скажем, пускаем две трассы в обе стороны, если одна из них уперлась в геометрию ближе, чем на N юнитов, то убираем портал. Хотя возможна и ситуация, когда прямо перед порталом натыканы брашевые ящики, так часто в КС бывает, например, тогда закономерный фейл.
А вообще насколько критична повертексная точность порталов? Допустим, если аппроксимировать геометрию карты в аксиальные браши, расставить порталы по упрощенной модели, а потом вычесть из них реальную геометрию?
Ну чтож, поскольку я не знаю что такое PYR, давайте я вам лучше поясню, чем я сейчас занимаюсь (как продолжение к верхнему посту).
Я уже неоднократно говорил, что основная проблема брашей - это их неприспособленность к рендерингу видеокартой. Из-за проекционного наложения текстурных координат их проблематично клеить в шареные треугольники, но даже если бы это и было возможным, наступает другая проблема - как эффективно отсекать видимость? На базе портального октри-рендерера, но это обычно предполагает аксиальное разбиение на кубические сектора, что уже само по себе очень неудобно. Есть еще HOM (он кстати использовался в сталкере) - дизайнер ставит сферы видимости и вкладывает их друг в друга. Тоже не слишком удобный подход. И как правило всё это базируется на необязательности иметь замкнутую геометрию. Но дело в том, что в настоящее время геометрию замкнуть куда легче чем во времена создания первокваки - просто делаем скайбокс и всё.
Но при таком подходе, как вы понимаете уже виз начинает сходить с ума, обрабатывая бессмысленную информацию. При том, что виз весьма удобная штука, в том числе и для AI-монстров, да и для сетевой оптимизации.
Проблема виза заключается в его дикой избыточности для современных подходов. Когда он помогал отсечь несколько лишних полигонов, чтобы их не пришлось рисовать софтварному рендереру, это всегда было хорошо. В ку3, оставив виз практически прежним, детализацию предложили делать встраиваемыми моделями, которые на виз не влияли и время компиляции не увеличивали, но в то же время рисовались за один вызов, если были видны. Это несколько исправило положение, но всё равно по современным меркам (т.е. где-то с 2007-го года), было явно недостаточным. Doom3 со своим подходом время сильно опередил, больше скажу, этот подход практически идеально ложится на все части старой архитектуры, снимая практически все проблемы и не добавляя новых. Ну вот кроме потребности расставлять эти виз порталы, но за это будет еще отдельный разговор. Ксерокс, мне вон рассказал, что в том же унреале их с самого начала надо было расставлять. Этож не окклюдеры, которые поставишь и гадай будет от него толк или не будет. Так вот.
Как шла эволюция виза?
1. первый квейк - визблоки намертво привязаны к лифам. Один визблок = один лиф. В лифе от одного до 256 полигонов (кажется в старых компиляторах был стековый массив с ограничением именно на столько, впрочем могу напутать). Теоретически в одном лифе конечно могла быть и вся карта, но это редкий случай, а на ку1 помоему совсем невозможный.
Соответственно если из позиции игрока нам этот лиф не виден. то не видны и все его полигоны.
2. второй квейк - над лифами появилась надстройка в виде кластеров и арий. Кластеры там были ну не точто бы сильно нужны, скорее как индексация для PVS и PHS, чтобы не хранить по два оффсета на сурфейс.
Но было и другое преимущество - мы получили возможность давать разным лифам один и тот же кластер, делать PVS более толстым по желанию. Что в свою очередь позволяло имплементировать детайл-брашы, которые занимали разные лифы, но у которых был один и тот же кластер. Виз считал видимость именно по кластерам, т.е. детайлы не замедляли скорость рассчёта. В принципе можно было обойтись и без кластеров в формате структур, но тогда бы пришлось сохранять эту информацию куда-то еще (что, собственно и сделал китаец в VHLT). Т.е. с ними код становится более удобным и читаемым, но нарушает бинарную совместимость.
3. третий квейк. Здесь арии получили специальный разделитель - ареапортал браш, а двери не надо было линковать со специальной энтитью или искать этот ареапортал по номеру, как было в ку2. Здесь эту задачу разрешили очень изящным образом - ареапортал-браш на самом деле не занимался выключением видимости, он просто делил одну арию на две. А дверь при вызове LinkEdict, просто искала в прикасающихся лифах их принадлежность разным ариям и соответственно могла их соединять и разъединять. Т.е. потенциал был заложен уже тогда, но использовался лишь для дверей. Основное отсечение всё равно происходило по классическому PVS, но зато в Q3 появилась возможность вставки произвольных моделей на карту, которые не влияли на построение видимости и рисовались за один вызов (если на них был один шейдер). Всё это повторюсь было еще актуальным для intermediate mode, когда выбора качать или не качать вертексы через шину каждый кадр у нас еще не стояло. А в 99-м году такого выбора разумеется не было, VBO появился в емнип в 2002-м году, долгое время устаканивался, из-за чего его боялись юзать вплоть до 2006-го года. Или если быть точным, даже не то чтобы боялись, ну просто смысл VBO в абсолютном отсутствии обновлений. А все необходимые действия надо выполнять в шейдерах. Если же обновлять сам VBO, то производительность даже ниже чем с бегинами (при соответствующих объемах данных). Я об этом в своё время писал и негодовал. Плюс еще и шейдеры, в момент их появления были сильно ограничены в возможностях, модели 1.0 и 1.1 использовать невозможно в принципе, разве что для туторов "как сделать развевающийся флаг на Cg". Собсно реальное использование началось именно с модели 1.2 (поэтому вы можете так часто видеть в GLSL-шейдерах прагму #version 120). Причём в отличие от того же DX, уже с этой версии большинства возможностей хватало для реализации очень и очень многого. А чего нехватало - можно было подключить расширением.
4. Doom3. У Кармака была прямая телепатическая связь с производителями видеокарт, поэтому то, что массово начали использовать с выходом кризисов-сталкеров, он мог внедрять уже в 2003-м году, не боясь, что это не сработает. И вполне естественно затачивал форматы хранения под это дело. К тому же в самом D3 положение усугублялось тем, что отложку на тот момент не потянул ни один компьютер (да и в железе еще ничего такого не было реализовано), т.е. нас ожидал овердрав по отрисовке источников динамического света. В 2003-м году. До 16 лайтов на сурфейс. Еще и с конямитенями. Вообще ужас. При таких вводных, рисовать по треугольничку и всё это прокачивать каждый раз по шине смертоубийство. Собственно, Кармак уже тогда сделал прицел на VBO. Но брашевая геометрия, повторюсь для этого не особенно годилась. И виз по своей природе не очень-то этому способствовал, но сам виз было желательно сохранить, он ведь удобный и надёжный. Но скорее всего не было и желания фундаментально менять принципы, на которых фактически держалось уже не одно поколение движков и которые себя весьма хорошо зарекомендовали, плюс у дизайнеров уже выработались определённые правила работы. Всё это накладывало свой отпечаток. Итак, что же было сделано?
(продолжение следует)
Добавлено 08-05-2020 в 14:55:
Цитата:
KiQ писал: А вообще насколько критична повертексная точность порталов? Допустим, если аппроксимировать геометрию карты в аксиальные браши, расставить порталы по упрощенной модели, а потом вычесть из них реальную геометрию?
Я боюсь ты не очень понял. Я не создаю никаких порталов "под дверные проёмы". Порталы генерирует сам компилятор с незапамятных времён. Обычные такие порталы, по ним еще виз считает видимость. Я просто среди этих сотен тысяч порталов отбраковываю те, которые могли бы мне пригодится в качестве ареапорталов. Только и всего.
Не знаю, обращали ли вы внимание, но уже в ку3 дефолтное описание хинта превратилось вот в это
C++ Source Code:
1
textures/common/hint
2
{
3
qer_nocarve
4
qer_trans 0.30
5
surfaceparm skip
6
}
полностью аналогично скипу
C++ Source Code:
1
textures/common/skip
2
{
3
qer_nocarve
4
qer_trans 0.40
5
//surfaceparm nodraw
6
//surfaceparm nonsolid
7
surfaceparm skip
8
}
Это не хитрая кодерская задумка, хинты просто дропнули на уровне дизайнера, т.к. пользы от них не было абсолютно. Т.е. браш оставили, а влияние от него - убрали.
Дядя Миша ну портал же может быть ориентирован? Вообще надо бы мне накидать на досуге портальный рендер, а то что-то я так до конца так и не въехал в их концепцию, а через практику оно приходит...
07-05-2020 08:31
Это штука будет покруче чем LithTech.
