HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)

Есть еще вот какое соображение. Все Кармаковские компиляторы (и д3 не исключение), генерят скорее избыточное кол-во порталов, чуть ли не для отсечения каждого полигона. То есть порталы на дверных проёмах в этом кол-ве тоже присутствуют в обязательном порядке. Надо просто найти удовлетворяющие нашим требованиям и использовать их. А остальные проигнорировать. Крытерий очевидно один - портал всеми своими рёбрами должен касаться реальной геометрии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Да уж, не так-то просто расставить эти виз-порталы автоматически.
Но я пока еще не теряю надежды.

Добавлено 07-05-2020 в 22:44:

текущая реализация имеет тенденцию ставить авто-порталы в двух случаях:
1. в дверных проёмах (ну собсно, как и нужно)
2. декоративных углублениях, типа всяких ниш (в чём нет никакого смысла).

Отличить нормальный проход от ниши практически невозможно. Увы.

Добавлено 07-05-2020 в 22:52:

Вероятно я просто начал не с того. Надо сперва оценить эффективность отрисовки сгруппированной по материалам карты, разбитой по материалам.
Взять тот же сипульчер. Там примерно 700 тыщ вертексов, 150 тысяч полигонов (треугольников триста-четыреста тысяч) и 252 текстуры (материала). В принципе для любой современной видеокарты это тьху. Это у нас в идеале 252 дипа (по материалам). Там безо всякого виза фпс должен быть приличным. Но это касается только рендеринга, естественно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

__________________
-Brain is dead-

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Crystallize когда будешь свой движок писать - именно так и сделай Это штука будет покруче чем LithTech.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Дядя Миша ну то есть конечно не вглубь портала а наоборот, наружу.
Кстати у порталов есть такое свойство как PYR?

__________________
-Brain is dead-

Ну чтож, поскольку я не знаю что такое 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:

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Не знаю, обращали ли вы внимание, но уже в ку3 дефолтное описание хинта превратилось вот в это

1

textures/common/hint

2

{

3

  qer_nocarve

4

  qer_trans 0.30

5

  surfaceparm skip

6

}

1

textures/common/skip

2

{

3

  qer_nocarve

4

  qer_trans 0.40

5

  //surfaceparm nodraw

6

  //surfaceparm nonsolid

7

  surfaceparm skip

8

}

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

nemyax именно.

Crystallize портал это портал, причём тут углы? Портал это окошко такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Дядя Миша ну портал же может быть ориентирован? Вообще надо бы мне накидать на досуге портальный рендер, а то что-то я так до конца так и не въехал в их концепцию, а через практику оно приходит...

__________________
-Brain is dead-

Дядя Миша
Скажи, а портал может только в одну сторону просматриваться в целях оптимизации?

__________________
http://www.moddb.com/mods/monorail-quest