На кордоне - десять тысяч кусочков моделей. Я в этой карте собрал около трёх тысяч.
Вот еще какая мысль мне в голову пришла, кстати Ксер и тебе тоже советую поэкспериментировать. BSP при построении, проверяет размер ноды на максимально допустимый. И если он превышает 1024 юнита, то делает дополнительный разруб. Но как она его делает?! Просто берёт плоскость с этим отступом в 1024 юнита. А что если эту часть дерева строить по классическому AABB-разбиению? Тогда у нас уровень до определённых размеров будет делиться точно поровну. В моём понимании это хорошо способствует пространственной балансировке дерева и выравнивает время доступа к нему.
C++ Source Code:
1
int SelectPartition( tree_t *tree, node_t *node, bface_t *list )
У меня сейчас просто сурфейсы линейно тестируются на попадание во фрустум, но я верну дерево и сравню оба варианта на производительность.
Добавлено 31-10-2020 в 11:53:
Кстати в том же XRay есть "разбиение" пространства на отдельные куски. Разбиение фейковое, поскольку террайн и так уже тесселирован, оно просто группирует куски по пространственным квадратам, не делаю никаких дополнительных разрезов. Именно поэтому на скриншотах вы видите дыры с неровными краями.
Добавлено 31-10-2020 в 11:55:
А потом эти куски попадают в соответствующие ячейки octree. Т.е. octree ессно ничего не режет, его вообще нет в компиляторе. Но зато в этом дереве находится всё сразу - и статическая геометрия и динамическая. Дерево достраивается по мере заполнения уровня мобами. Мне лично этот момент не нравится, т.к. октри довольно жрущее по памяти и может во время игры давать вот те самые лаги и фризы. Но это пока что предположение.
А что насчет лимитов всяких? Не получится ли так, что если чел захочет сделать опенворлд, он уткнется тупо в лимиты чего-нибудь и у него получится в лучшем случае просто пустой мир?
У меня такой же вопрос. В ксаше я обратил внимание, что если поставить 30 солдат модельками как env_static, фпс не проседает, а если 30 реальных - то сильно падает. Это из-за их кода или бсп-дерева? Не совсем понимаю, как это работает.
Мне сейчас надо определиться с типом коллизии, вот оно что.
Представлять каждый треугольник в виде плоскости со скосами, довольно эффективно в плане скорости работы, но занимает чудовищно много места.
На какой-нибудь ЧАЭС легко может быть 10-15 миллионов плоскостей.
А ведь она по современным меркам довольно таки лоу-поли.
Впрочем там вылезает еще одна проблемка. У видеокарт оказывается, существует лимит на максимальный размер VBO - обычно миллион вертексов.
Самое поганое, что и на индексы точно такой же лимит - 1 миллион.
Это немного нелогично, к тому же превышение лимита далеко не всегда приводит к каким-то последствиям, на моих карточках.
Так что придётся еще и геометрию разбивать на небольшие батчи.
Наверное сделаю куски по 65 киловертексов с локальными оффсетами, чёб индексы хранить в 16-битном диапазоне.
Но повторюсь, главная задача, это определиться с коллизией. Коллизия будет по треугольникам, но надо решить с какими фигурами. Можно сделать просто triangle vs bbox. Можно как в третьем дууме - набирать произвольные простенькие фигуры из конечного числа вертексов - обычно 32-64. В том же физиксе лимит на активное тело - 256 вертексов, но как правило это даже избыточно.
kotar.sys писал: А в сталкере разве нет упрощенной модели геометрии для коллизии?
Есть, да. Но там как. Вот допустим ёлки стоят на поляне. Понятное, дело, ёлка одна, просто рисуется много раз. А вот в коллизии, все эти ёлки продублированы, ну и не только они, конечно.
Загрузил недостающие части ландшафта. Обратите внимание на поликаунт.
На машинках почему-то текстуры съехали, на всех. Но я пока не разбирался.
Ну вот, прекрасная сцена для тестирования и оптимизации отрисовки и коллизии. Ну и для оптимального хранения данных тоже. Разумеется, я потом буду тестировать и другие сцены, вероятно и из эксодуса, надо получить вменяемую производительность.
Но тут конечно без вариантов - точного ответа нет. Только тестировать и сравнивать. Лоды проверю, размеры батчей, оптимальные размеры VBO, помощь дерева в отрисовке, и так далее.
Это вот как раз такой тип сцены, что нихрена не спрячешь и не укроешь, всё как на ладони.
Добавлено 05-11-2020 в 18:35:
По сути с этой сценой даже мой компилятор не справляется - ему не хватает памяти, выручает только ключ /3Gb в boot.ini
Предвидя советы "ну почему бы не сделать как в сталкере", напоминаю, что новый движок должен уметь как активно использовать полностью брашевые карты, так и полностью полигональные. Т.е. задачка несколько сложнее, чем представляется на первый взгляд.
Нет, не в оптимизации, конечно дело. А в выборе наилучших методов.
А чтобы что-то выбрать, надо многое протестить. Это время.
Два-три миллиона, в зависимости от того, какая часть уровня в кадре. Вот пейсатели форков X-Ray кипятком обоссутся, если у тебя получится показать Кордон со всеми деталями на полной динамике с фпс выше, чем выдают их форки на твоей видекарте
Ku2zoff писал: Вот пейсатели форков X-Ray кипятком обоссутся, если у тебя получится показать Кордон со всеми деталями на полной динамике с фпс выше, чем выдают их форки на твоей видекарте
X-Ray очень хорошо оптимизирован. Но можно еще лучше, т.к. он точился под преведущее поколение карточек.
Цитата:
Cybermax писал: Мне уже больше нравится то что на скриншутах, чем в оригинале
| IP: 
29-10-2020 15:55
