Скрытие объектов за стенами

[Кирпи4]

Народ, выручайте....
Пробовал браться за это, но выходит либо сущая говнота, либо просто знаний матана не хватает...
Может есть какие - нибудь либы для этого? Рад буду даже хоть самому алгоритму...

[Mr_F_]

гугли по словам occlusion culling, способов много.

[Nex]

Эм. "пик" встретит стену. И думаю тема не полностью раскрыта.

[Кирпи4]

Окей, раскрываю
У меня есть меш за стеной, и, допустим, баундинг бокс в виде куба.
Нужно сделать так, чтобы меш хайдился, если баундинг бокс полностью загорожен. EntityVisible - вообще убило меня, так как он проверяет на видимость ЦЕНТР ентити - бред...

[Platon]

Сообщение от Кирпи4

Окей, раскрываю
У меня есть меш за стеной, и, допустим, баундинг бокс в виде куба.
Нужно сделать так, чтобы меш хайдился, если баундинг бокс полностью загорожен. EntityVisible - вообще убило меня, так как он проверяет на видимость ЦЕНТР ентити - бред...

юзать порталы и\или антипорталы (оклудеры).

порталы, грубо говоря, это полигоны описывающие проемы в стенах.

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

от каждого портала можно построить фрустум, т.е.
берем по паре вершин от полигона портала (по его ребрам)
строим пару векторов от камеры до этих вершин
векторно перемножаем, нормализовываем и получаем нормаль плоскости
скалярное прозведение этой нормали с вектором "камера-центр координат" даст четвертую компоненту плоскости.
в результате получишь несколько плоскостей которые и будут фрустумом

соответственно как происходит кулинг сцены:
пробегаем по порталам по иерархии видимости
режем полигон портала фрустумом ( ибо он можнт быть виден только частично, и чтобы правильный фрустум через него построить, нужно определить видимую часть этого портала )
строим новый фрустум из урезанного полигона

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

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

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

антипорталами может выступать любая геометрия. Принцип тот же самый - строим через окклудер фрустум, и все что в него входит уже наоборот - скрывается. Если геометрия окклудера сложная ( т.е. не просто полигон, а например куб ), то сначала надо определить силуэтные вершины ( минимальные\максимальные по проекции на плоскость камеры ), и по ним уже построить фрустум так-же, как описал выше для портала.

ЗЫ
извиняюсь за этот поток сознания писал в спешке, попзжа подробнее опишу, если надо конечно.

[Кирпи4]

Надо, надо, конечно надо =)

Мне кажется, аффтар больше половины из сказаного не понял.

[Mr_F_]

"рисуем" геометрию в буфер глубины
"рисуем" другие порталы в буфер без записи, но с тестом и определяем виден он или нет
добавляем видимые порталы, соответственно стороне, в две ветки текущего портала

рисовать придётся видимо не 1 раз? т.к. даже если с огромным фовом отрендерить кадр в направлении портала, не факт что у нас в нём растеризуются другие порталы, которые очень по бокам.
наверное надо будет 5 раз рендерить, аля полукуб, чтобы со всех сторон потенциально видимые увидеть.
алсо, вместо софтварного растеризатора, эффективнее было бы юзать occlusion queries.

насчет "режем полигон"

хм, я тупо делал фрустум из позиции камеры и точек портала (их было всегда 4), в принципе достаточно получить описывающий прямоугольник портала в экране и поплющить направление/фов фрустума, чтобы через него шёл.

[Platon]

Сообщение от Кирпи4

Надо, надо, конечно надо =)

Я ожидал что будут какие-то вопросы направляющие, а то я вот даже незнаю что подробнее объяснить

Сообщение от Mr_F_

рисовать придётся видимо не 1 раз? т.к. даже если с огромным фовом отрендерить кадр в направлении портала, не факт что у нас в нём растеризуются другие порталы, которые очень по бокам.
наверное надо будет 5 раз рендерить, аля полукуб, чтобы со всех сторон потенциально видимые увидеть.
алсо, вместо софтварного растеризатора, эффективнее было бы юзать occlusion queries.

Рисовать 1 раз, ибо рисуем не через фрустум, а просто все что с одной стороны портала ( определяем чо с какой стороны находится относительно плоскости портала, как для BSP разделяющая плоскость короче ).
Насчет окклюжн квери - хороший вариант, но я предпочитаю велосипеды )

Сообщение от Mr_F_

хм, я тупо делал фрустум из позиции камеры и точек портала (их было всегда 4)

Если портал виден чуть-чуть, то получишь оверхед, ибо фрустум будет через весь портал, и соответственно будет рисоваться то что не видно из камеры. Для маленьких порталов может и лучше будет, не надо будет тратить время на обрезку, и через такой портальчик видно мало. Но для больших порталов уже сомнительно.

Сообщение от Mr_F_

в принципе достаточно получить описывающий прямоугольник портала в экране и поплющить направление/фов фрустума, чтобы через него шёл.

Ну можно и так, если портал не сильно сложный по форме, иначе такое огрубление прямоугольником может не окупится.

ЗЫ
Пока парочку картинок прикреплю для топикстартера, надеюсь они немного прояснят хрень в 5ой мессаге

На первой изображены некоторые варианты кулинга через порталы:
рис. 1 - порталов нет, обычный вариант кулинга через камеру
рис. 2 - один портал, полностью виден из камеры, темно-синим виден новый фрустум построеный через портал
рис. 3 - тот же вариант, только камеру немного повернули, портал теперь виден частично, ярко-красным - портал обрезаный фрустумом камеры
рис. 4 - вариант посложнее, тут уже проглядывается иерархия порталов

на второй схематично построение фрустума через полигон портала
p0 - точка камеры
p1 .. p6 - точки полигона портала
E1 .. E6 - ребра полигона, проходясь по которым строим плоскости фрустума
V1 .. V6 - вектора, построенные через точки портала от точки камеры
для каждой плоскости фрустума надо найти нормаль ( направление плоскости ) и смещение относительно центра координат.
внизу справа изображено что из себя представляет нормаль и смещение на примере треугольника ( которые и получаются по ходу расчета фрустума )
внизу слева - как считается

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

[HolyDel]

чем ребристее фрустум - тем дольше будет проходить проверка на принадлежность ему. прилегких дипах может быть дешевле брать четырехугольные фрустумы.

[Кирпи4]

Святыыыыыыыыыыееее щииииии....
Ну что я могу сказать - технология охренительная, но не по блицевским меркам это. Вобщем, буду говнокодить или чего-нибудь думать, если выйдет что-либо стоящее, то запощу.
Есть одна идейка, но она лютое говно , так как каждый кадр предполагается дохрена лайнпиков. Вроде бы есть выход - это физ враппер, там вроде лучи быстрее выполняются, но это уже слишком.

А, ещё вот: можно ли как-нибудь произвести пик из DLL на пуряке?

Сообщение от Кирпи4

А, ещё вот: можно ли как-нибудь произвести пик из DLL на пуряке?

Вытащить адрес нужной функции с последующим вызовом.

[Mr_F_]

Ну что я могу сказать - технология охренительная, но не по блицевским меркам это.

да ну, я как раз первый раз делал их именно на блице)
прирост фпс - был (кроме блица участвовал ксорс, толстые шейдеры и слабая видюха).

На блице разумнее всего сделать секторную систему, библиотека есть где то, ее написал Мад-Медик.

А насчет остального - зачем обьяснять такие вещи если всеравно на блице этого не реализовать ? Остальное будет либо геморой либо в виду закрытости движка будет вообще нереализуемо.

[Mr_F_]

на блице этого не реализовать

если руки кривые, то да.