Комментарии 34
Если кому будет интересна тема разработки игры, я готов продолжать и расширять статью с привидением конкретных шагов, решений и дальнейших планов. Также, думаю, вам будет интересна тема построения многопоточного Open GL приложения разработанного на Java, о котором постараюсь рассказать в следующей статье.
Действительно интересно. Я так понимаю графический движок у вас самописный?
Интересно, продолжайте =)
Инстансы статических мешей еще нет?
Мне кажется странным, вроде ничего особенного из графики нет и фпса нет, большие движки большое количество трисов спокойно переваривают, может и у Вас проблема в чем-то другом?
Инстансы статических мешей еще нет?
Мне кажется странным, вроде ничего особенного из графики нет и фпса нет, большие движки большое количество трисов спокойно переваривают, может и у Вас проблема в чем-то другом?
Еще много чего интересного не реализовано. Сейчас больше сосредоточен на реализации геймплейных механик. Работа над оптимизацией вывода графики вынужденное отвлечение от центральной задачи, но постепенно приходится реализовывать и докручивать некоторые функции. Проект пишется на Java, что накладывает некоторые ограничения. 4 миллиона трисов при 60 FPS это неплохой результат на gtx 660. Или может вы заметили на скрине с пальмами 30 FPS? Это экспериментирую с синхронизацией и ограничил планку в 30 FPS.
и правда хорошо, спасибо, уяснил некую информацию для себя, а то оптимизация дело тонкое...=)
Какой момент был интересен?
вообще конечно всё) ибо я еще зелен и молод, тем более пытаюсь что то сделать на юнити, но в целом информация про полигональную сетку ландшафта, мне тут под ухо объясняют похожее + ваш материал, дает материал в голове, который я понимать начинаю но выразить не могу, как то так хДд Спасибо в общем) буду следить за новостями
Если я правильно понял — то затык был на CPU стороне, а не GPU?
В таком случае, надо уменьшать количество дроуколлов. Я так полагаю, вы не используете инстансинг? Судя по скринам — у вас много однотипных мешей, самое оно для инстансинга. Заставьте GPU этим заниматься.
В таком случае, надо уменьшать количество дроуколлов. Я так полагаю, вы не используете инстансинг? Судя по скринам — у вас много однотипных мешей, самое оно для инстансинга. Заставьте GPU этим заниматься.
Да, узким местом был CPU. Инстансинг не использую, есть небольшие проблемы с определением однотипности объектов и их хранением для сцены, конечно это решаемая задача, но честно не хватает рук на решение всех задач.
но честно не хватает рук на решение всех задач.
Понимаю, но это сильно поможет вам в long-term.
Еще пару вопросов:
1) LOD-ирование работает надеюсь?
2) На скринах, с такого расстояния, я бы уже переключал на imposters. Или я просто не замелил и это уже реализовано?
Полностью согласен, задача по инстансингу стоит в таск листе, возможно стоит её подвинуть на более ранний этап разработки.
1. Геометрия у нас упрощена до минимума, и малейшее её упрощение приводит к видимым искажениям, даже с такого расстояния. Тут играет роль ракурс камеры.
2. Нет, не реализовано. Поясню. В билде не будет отдаления камеры на такое расстояние. При отдалении камеры, в определенный момент, будет происходить переключение на стратегическую 2D карту.
1. Геометрия у нас упрощена до минимума, и малейшее её упрощение приводит к видимым искажениям, даже с такого расстояния. Тут играет роль ракурс камеры.
2. Нет, не реализовано. Поясню. В билде не будет отдаления камеры на такое расстояние. При отдалении камеры, в определенный момент, будет происходить переключение на стратегическую 2D карту.
Используете ли triangle strips? Хотя с оптимизированной сеткой это нетривиальная задача.
И вот в этих местах нет «дырок»? Там по сути разрыв в топологии. Может «дребезжать» на больших расстояниях.
И вот в этих местах нет «дырок»? Там по сути разрыв в топологии. Может «дребезжать» на больших расстояниях.
Может «дребезжать» на больших расстояниях.
Кстати, да. В таких местах рекомендуется «сшивать» вершины.
В том то и дело, задача не тривиальна, так что пришлось отказаться от triangle strips.
Но такие места обходятся путем:
Все эти вертексы лежат на одной линии. А выделенные трисы как раз служат неким переходом, дабы нивелировать подобные разрывы.
Но такие места обходятся путем:
Все эти вертексы лежат на одной линии. А выделенные трисы как раз служат неким переходом, дабы нивелировать подобные разрывы.
Как боретесь с GC? Бывают микрофризы?
В Fortnite используют очень эффектный и эффективный метод оптимизации для повторяющейся природы: менять такие модели на хитрый набор спрайтов.
www.shaderbits.com/blog/octahedral-impostors
Третий пример:
www.shaderbits.com/blog/octahedral-impostors
Третий пример:
Спасибо за ссылку, интересный подход.
На средней игровой карте, при максимальном отдалении и при большом скоплении пальмВот тут скрыта возможность оптимизации, которую Вы, кажется упустили. Дело в том, что на большом удалении многие элементы объекта становятся меньше одного пикселя, так что нет никакого смысла подробно анализировать и отрисовывать.
Следовательно, для каждого объекта надо иметь несколько векторных моделей — для разных расстояний. Дальше, кажется, очевидно — но могу разобрать подробно.
Далее: при отрисовке объектов есть несколько разных алгоритмов определения видимости объекта (и отдельно каждой его части). В некоторых алгоритмах можно применить такую оптимизацию:
Вся сцена (все имеющиеся объекты) выстраивается в иерархию. Например, допустим, у нас есть несколько людей в пустоте. Тогда:
- сцена = человек1 + человек2 + ...
- человек = туловище + голова + две руки + две ноги
- рука = плечо + предплечье + кисть (этот уровень разбиения можно совместить с вышележащим — т.е. рука не будет присутствовать в иерархии, а кисть будет сразу частью человека)
- кисть = ладонь + пальцы
Если обнимающий шар объекта не попадает в экран — его рисовать вообще не нужно. Т.е. можно выбросить сразу много заведомо ненужной работы.
Если обнимающие шары двух объектов при проецировании на экран не пересеклись — то эти два объекта никак не перекрывают друг-друга; так что незачем искать пересечения треугольников.
При использовании «лучей зрения»: если луч зрения не попал в обнимающий шар, то он не попадёт ни в какой элемент (треугольник) объекта.
Сразу замечу, что любое слагаемое всегда является частью суммы; однако, обнимающий шар слагаемого может выходить за пределы обнимающего шара суммы.
…
Если обнимающий шар объекта не попадает в экран — его рисовать вообще не нужно.
…
Если обнимающие шары двух объектов при проецировании на экран не пересеклись — то эти два объекта никак не перекрывают друг-друга
Я один вижу здесь противоречие?
Следовательно, для каждого объекта надо иметь несколько векторных моделей — для разных расстояний. Дальше, кажется, очевидно — но могу разобрать подробно.
Ну так это и есть LOD-ирование, о котором мы говорили чуть выше в комментариях.
Если обнимающий шар объекта не попадает в экран — его рисовать вообще не нужно. Т.е. можно выбросить сразу много заведомо ненужной работы.
У меня это работает по другому принципу, так как у меня все объекты находятся в тайлах, определение их видимости простая задача.
А почему не пирамидой лодов? При максимальном удалении большинство деталей ландшафта просто не видны особо и их можно «упрощать»
Вот куда еще упрощать эту пальму?
Это не последний лод, можно ещё дальше собирая пачки пальмы в билдборды:
i.imgur.com/ss5CB1A.jpg
То есть простой треугольник/квад с запечённым изоражением вашей пальмы. С применением нормал-мапы смотрится вдалеке вполне сносно.
Ну и группы пальм рендерить всегда дешевле чем поштучно из-за DrawCall bottleneck
i.imgur.com/ss5CB1A.jpg
То есть простой треугольник/квад с запечённым изоражением вашей пальмы. С применением нормал-мапы смотрится вдалеке вполне сносно.
Ну и группы пальм рендерить всегда дешевле чем поштучно из-за DrawCall bottleneck
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация графики. Интересный Concave Hull