Cybermax я этими вопросами не занимался, но можно иметь несколько сетевых моделей. Там как, если RPG игроков дохрена, но синхронизационные пакеты могут идти несколько раз в минуту. И классическая шутерная модель - игроков 32 штуки, но и пакеты идут 30-100 раз в секунду.
Добавлено 04-05-2020 в 20:16:
Кстати вот еще важный момент - разработчикам весьма важно иметь возможность допилить то, чего изначально не было. Скажем тот же VR подключить. И дело тут вовсе не в открытости\закрытости сорцев.
Ну чтож, по предварительным результатам опроса, да и по общим соображениями, я вижу, что в первую очередь надо направить усилия на внедрение динамической системы окклюзии, т.е. избавится от предрасчётов PVS, которые могут занимать сколько угодно времени. Вероятно в дальнейшем я избавлюсь и от BSP, но пока что это некритично, сборка карты занимает несколько секунд, ну максимум - пару минут на каком-нибудь сепульчере. Но динамический окклюдинг нужен обязательно, виз слишком часто не справляется.
Добавлено 05-05-2020 в 14:09:
Цитата:
XaeroX писал: ...после того как заслали донат!
А между прочим в репозитарии Godot Engine есть такой файлик - список донаторов, и там золотые донаторы, платиновые и так далее. Они еще и по рейтингу сортируются. Но конечно это было до кризиса, когда нефть стоила выше нуля.
Дядя Миша
А какие методы ты знаешь эффективного отсечения невидимой игроку геометрии в реальном времени? Например вот знаю фрустум, и LODы (хотя это не совсем отсечение, но в каком то смысле), но не более.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro я ж написал - софтварный рендеринг в Z-буффер. Окклюедеры рендерятся на CPU, чтобы не было лага с получением данных.
Рендер этот довольно простой, там же не надо накладывать текстуры, только растеризация небольшого числа прямоугольников, плюс сам буффер малого разрешения. Ну и желательно его векторизовать, но это я по рассказам, не по опыту.
Мне что-то всё таки кажется, что ни XashNT, ни волатила никому не будут интересны собственно как инструмент для разработки игр, по крайней мере в рамках HLFX. Хотя и сам очень надеюсь что так не случится. Но, всё-таки людям проще влиться туда, где уже есть некоторый набор ресурсов, документации/видеоуроков/статей, примеров игр откуда даже что-то можно стянуть к себе в проект.
Погудели-пообсуждали и возвращаемся к работе. Итак, как же нам обойтись без виза. Сперва попробуем самый тупой метод - будем считать портал флоу налету. Это может оказаться довольно дорого, но попробуем.
Сохранил порталы в карту, вот так они выглядят. Да вы наверное и без меня знаете.
В сорсе бы такие вещи делали детайлами. Кстати инструмент визуализации порталов классная штука.
Не знаю, может глупость сморожу, но что если отсекать ненужное не по геометрии, а по грубой Octree копии модели?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Создал обратные порталы, так наверное более наглядно.
Цитата:
FiEctro писал: а по грубой Octree копии модели?
Можно просто квантизовать всё пространство на AABB и рисовать сегментами. Но есть проблема - у нас же эти брашы уже и так разбиты на отдельные полигончики, ниже некуда. Для гигантских моделей, типа ЧАЭС это вполне рабочий метод, но сами модели придётся посечь на такие же сегменты. Что в свою очередь может негативно сказаться на бамп-маппинге или наложении лайтмапы.
Ладно. Для начала я хочу просто попробовать выполнять BasePortalVis в реалтайме и для отдельно взятого кластера. Это очень быстро, а вот будет ли достаточно эффективно...
Дядя Миша писал: но сами модели придётся посечь на такие же сегменты. Что в свою очередь может негативно сказаться на бамп-маппинге или наложении лайтмапы.
А разве при разбиении нельзя сохранить нормали вертексов в исходном состоянии?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: А разве при разбиении нельзя сохранить нормали вертексов в исходном состоянии?
не поможет. Интерполяция осуществляется внутри треугольника, а не между ними.
Опробовал я SimpleFlood в рантайме. Работает, даже фпс садит гораздо меньше, чем ожидалось бы. Но тут в действие вступает сразу несколько факторов. Если бы эта видимость бралась ну скажем только для рендерера, для камеры - то это одно. Виз он же для движка практически бесплатный, поэтому его юзают все, кому не лень, монстры постоянно проверяют, не появился ли игрок в зоне видимости, код AI дополнительно проверяет наличие игрока, на тему, надо ли играть секвенции или меня никто не видит, серверный кадр строит толстый PVS чтобы отсечь невидимые клиенту энтити. Т.е. за кадр эта штука может вызываться несколько десятков раз, а там рекурсия (пускай и весьма простая) и цикл на numportals * 2. Т.е. всё это просадит фпс куда быстрее чем даст профит от отсечения. Плюс предрасчёты при загрузке карты - сами по себе занимают какое-то время. Ну на c1a0d это полсекунды. Но вообще - неограниченно. BasePortalVis далеко не всегда управляется быстро. Иногда и до минуты маслает в мультитреде.
Вообще конечно использование именно этого кода не вполне корректно, если мы хотим, например посчитать видимость для фрустума камеры. Но тут вылезает другая тонкость - кластеры всё же достаточно большие, т.е. перерасчёт видимости происходит, когда игрок перемещается в другой кластер. Очевидно, если это делать для фрустума, то перерасчёты будут для малейшего движения мышкой. Однако есть одна категория объектов, у которых фрустум не меняется - это лайты. Собсно, в даркплейсе после ряда экспериментов именно для них и оставили портал-флоу.
Добавлено 06-05-2020 в 19:00:
Решил я поизучать как в д3 сделано. А там надо сказать такое обманчивое впечатление, потому что тричетверти компилятора - это по сути паста из ку3. А оставшийся код - это дамп в текстовые форматы, ну я никогда там особо не ковырялся, полагая что оно не представляет интереса. А вот как раз-таки и зря. В дуум3 уже никакие видимые сурфейсы к лифам не цепляются, там идёт группировка по ариям, т.е. большим блокам. И ариа-порталы могут работать в двух режимах. Классический - на двери и визпортал, ограничивающий видимость. И дерево для рендеринга уже не используется, самих арий достаточно немного (лимит на 1024 штуки), они могут быть какого угодно размера - ну скажем на всю карту. Второй любопытный момент связан с тем, что геометрия может разрезаться по размеру этих самых арий. И тут, как я уже говорил - начинаются швы на бампе. Так вот там какая-то хитрая система добавления т-джунков, которая это предотвращает. Впрочем, если маппер не поставил ни одного ареапортала, сами понимаете, это будет довольно тормозно.
Возможно имеет смысл поддерживать оба варианта - классический с визом и "модерновый". Благо что для этого не требуется каких-то фундаментальных изменений, достаточно лишь порезать геометрию.
Добавлено 06-05-2020 в 21:37:
Ну вот подразобрался. Объясню всё подробно, но сначала небольшой экскурс на тему, почему жы в наше время так сильно тормозят старые кушные форматы. Кто-то полагает что дело в БСП, кто-то думает что они просто устарели. Если говорить кратко, то в старых форматах нарушился баланс оптимизации. Поясню. Есть несколько типов оптимизации.
1. Не делать вообще ничего - бывают случаи, когда весь код можно полностью выкинуть без ущерба для функционала. Чаще всего - когда нагородили лишнева. Или же код писался вчерную для теста.
2. Посчитать всё заранее - компиляция. Баланс между процессорным временем и памятью.
3. аппроксимация - берём тяжёлый для выполнения код, упрощаем, получаем выигрыш в скорости при минимальных отличиях в результатах работы.
4. запуск тяжёлого кода предваряется лёгкой для выполнения проверкой.
Вот здесь как раз наш случай. По факту в старых форматах мы столкнулись с совершенно идиотской ситуацией, когда проверка на видимость стала дольше отрисовки. Почему такое произошло?
Очевидный ответ - форматы разрабатывались с учётом софтварного рендеринга, т.е. с отрисовкой на процессоре. Отправка данных на видеокарту капитально перебалансировала всю систему. Но к счастью шины у видеокарт тогда были узкие, прокачка данных была достаточно дорогой, поэтому для intermediate-режима мы наоборот получили прирост производительности. Собсно проблемы начались, когда нам захотелось иметь миллионы полигонов в кадре. Дерево, как я уже говорил очень подробное. Каждый полигон лежит на ноде. А если не помещается - будет разрезан и всё равно положен. При возможности делать очень большие уровни подобный подход сам по себе превратился в тормоз.
1. рекурсия по слишком большому дереве тормознее линейного перебора
2. отдельное отсечение каждого полигона фрустумом если не дороже, то зачастую сопоставимо с их отрисовкой (особенно если их очень много).
3. всё это крайне херово оптимизируется, из-за особенностей текстурирования брашей. Проблематично сделать три-стрипы, к примеру.
Возможность засунуть всю геометрию в единый VBO проблемы не решило - ну потому что мы по прежнему проверяем каждый полигончик отдельно на попадание во фрустум, а потом шлём его индексы на видеокарты.
В Ку3 лифы сделали больше размером, видимо как раз согласуясь с возможностями тогдашнего железа. Но это же зависит даже не просто от возможности добавлять детальные полигоны в лифы. Смысл в том, что рисовать даже по лифам - затратнее чем одним вызовом. Но вот при текущей организации не получается ни то ни другое. Потому что как ни крути, PVS всё же справляется со своими задачами неплохо, а отрисовке группами мешает тот факт, что сами брашы не предназначены для эффективной отрисовки. Я бы конечно мог просто их выбросить нахрен и вообще, но.. мы же хотим кубать, правильно?
И для меня уже пару лет это было. ну не то чтобы неразрешимым противоречием, просто я не мог определиться, как лутьше поступить. То ли выкинуть BSP совсем, порезать всё на квадраты и выполнить иерархическую окклюзию. То ли октри заюзать. Вообщем размышлял я до сегодняшнего дня, пока совершенно случайно не углубился в изучение дуум-тришной организации ареа-порталов (а там же нет виза, как вы помните). Конечно я весь этот код видел и раньше, но в том-то и дело, я просто был изначально уверен, что вся эта замута нужна в основном для построения и оптимизации теневых объемов (что вообщем-то правда - там действительно есть этот код). Но вот ту основную идею, которую я там сегодня разглядел...
XaeroX писал: ...расставлять порталы между ариями будет маппер. Та-дам!
Хочешь прикол? Мапперы эти порталы уже 18 лет расставляют. Причём, расставляя их они ждут от них именно работы порталов. И очень сильно расстраиваются, когда от этой расстановки просто полигонов прибавляется.
Я про хинт-брашы говорю
04-05-2020 15:50
