Дядя Миша писал: Потому что это же дерево крайне желательно использовать не только для отрисовки, но и для проверки видимости на сервере. Там дикие тормоза просто из-за целой кучи этих накопленных лифов, оно идёт по хеадноде, дерево большое. Т.е. надо и на сервере тоже такое дерево.
Так я открытым текстом говорю - тормоза на сервере, что тут понимать-то?
Ты на рыбалку? Да нет, я на рыбалку.
Добавлено 17-05-2020 в 12:09:
Я уже писал, но повторюсь. Вот возьмем тот же сипульчер. Пять тысяч энтить. Дерево со всеми оптимизациями - примерно 11 тысяч нодов и лифов.
Сервер обрабатывает каждую энтить. Ищет лифы, из которых её видно. В кваке статичный массив для каждой энтити на 16 лифов, в халфе 48. Но из-за детальных нодов, там получается зачастую, что этих самых лифов на каждую энтить приходится от 50 до 400. А как устроен механизм определения видимости, если кол-во лифов превышено? Идёт по хеадноде рекурсия. Для дерева в 11 тысяч нодов. И так - для каждой видимой энтити из этих пяти тысяч. Там можно вообще рендеринг кадра отключить - фпс не подымется выше 150. И это мы не учитываем физику, к примеру, почти всё время сжирает это определение видимости. То что должно помогать в ускорении превратилось в ключевой тормоз - слишком подробное дерево.
Добавлено 17-05-2020 в 12:14:
ЗЫ. Нагнал я вам. 10 тысяч лифов - это для кутри, где детальные ноды заведомо выброшены из дерева. В халфовском\кушном формате, там за 65 тысяч нодов и лифов. Из-за чего кстати её не в состоянии загрузить Darkplaces. Он же "для ускорения" распаковывает виздату.
Ну вот и давайте посчитаем. 65000 х 65000 = 4225000000 поделить на 8, получается 503 мегабайта бесполезно занятой памяти. Но в сипульчере не ровно 65к лифов, там больше. Корочи оно вылетает с Out of memory, причём это не исправить заменой short на int. Там в архитектуре интересное допущение.
Наконец руки дошли и до портального тумана. В ку3 туман был видимо прикручен в самый последний момент, поэтому технология имела ряд оговорок и была очень неудобна в использовании. Во первый туман надо было задавать строго аксиальным брашем, во вторых у него могла быть только одна видимая сторона. Конечно эту информацию о тумане надо как-то сохранять в VBO, что уже само по себе не фонтан. Ради какого-то тумана занимать столько места в вертексе. Переход на новую технологию даёт более генеричную информацию, по сути мы вообще не храним туман явным образом, только портальный шейдер, если он конечно не был помечен как невидимый. Единственное отличие от кутришного тумана для дизайнера - видимую сторону надо всегда задавать явным образом. Потому что это всё же портал, а не иллюзия объема. На скринах не туман, как может показаться, а дебажная визуализация порталов для тумана (разумеется эту информацию можно будет использовать и для видимости и для AI). Проволка показывает, что плоскость портала разрезала всё - и уровень и модельку на стене. Кутришный туман резал только брашы и немножко патчи, но дизайнеры знали, что патч он мог с лёгкостью превратить в кусок говна, поэтому старались не вкладывать их в туман
Добавлено 18-05-2020 в 23:08:
Ну чтож, имплементация тумана прошла успешно. Вообще на этих порталах можно столько интересных штук придумать. Ну зато код избавился от спецификации этого тумана. Теперь туман реализуется при помощи видимого ареапортала с настройками тумана. Надо еще будет затестить комнатку с множественными выходами.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
| IP: 
17-05-2020 08:09
