Comments 34
Если кому будет интересна тема разработки игры, я готов продолжать и расширять статью с привидением конкретных шагов, решений и дальнейших планов. Также, думаю, вам будет интересна тема построения многопоточного Open GL приложения разработанного на Java, о котором постараюсь рассказать в следующей статье.
Действительно интересно. Я так понимаю графический движок у вас самописный?
+2
Интересно, продолжайте =)
Инстансы статических мешей еще нет?
Мне кажется странным, вроде ничего особенного из графики нет и фпса нет, большие движки большое количество трисов спокойно переваривают, может и у Вас проблема в чем-то другом?
Инстансы статических мешей еще нет?
Мне кажется странным, вроде ничего особенного из графики нет и фпса нет, большие движки большое количество трисов спокойно переваривают, может и у Вас проблема в чем-то другом?
0
Еще много чего интересного не реализовано. Сейчас больше сосредоточен на реализации геймплейных механик. Работа над оптимизацией вывода графики вынужденное отвлечение от центральной задачи, но постепенно приходится реализовывать и докручивать некоторые функции. Проект пишется на Java, что накладывает некоторые ограничения. 4 миллиона трисов при 60 FPS это неплохой результат на gtx 660. Или может вы заметили на скрине с пальмами 30 FPS? Это экспериментирую с синхронизацией и ограничил планку в 30 FPS.
0
и правда хорошо, спасибо, уяснил некую информацию для себя, а то оптимизация дело тонкое...=)
0
Какой момент был интересен?
0
вообще конечно всё) ибо я еще зелен и молод, тем более пытаюсь что то сделать на юнити, но в целом информация про полигональную сетку ландшафта, мне тут под ухо объясняют похожее + ваш материал, дает материал в голове, который я понимать начинаю но выразить не могу, как то так хДд Спасибо в общем) буду следить за новостями
0
Если я правильно понял — то затык был на CPU стороне, а не GPU?
В таком случае, надо уменьшать количество дроуколлов. Я так полагаю, вы не используете инстансинг? Судя по скринам — у вас много однотипных мешей, самое оно для инстансинга. Заставьте GPU этим заниматься.
В таком случае, надо уменьшать количество дроуколлов. Я так полагаю, вы не используете инстансинг? Судя по скринам — у вас много однотипных мешей, самое оно для инстансинга. Заставьте GPU этим заниматься.
0
Да, узким местом был CPU. Инстансинг не использую, есть небольшие проблемы с определением однотипности объектов и их хранением для сцены, конечно это решаемая задача, но честно не хватает рук на решение всех задач.
0
но честно не хватает рук на решение всех задач.
Понимаю, но это сильно поможет вам в long-term.
Еще пару вопросов:
1) LOD-ирование работает надеюсь?
2) На скринах, с такого расстояния, я бы уже переключал на imposters. Или я просто не замелил и это уже реализовано?
0
Полностью согласен, задача по инстансингу стоит в таск листе, возможно стоит её подвинуть на более ранний этап разработки.
1. Геометрия у нас упрощена до минимума, и малейшее её упрощение приводит к видимым искажениям, даже с такого расстояния. Тут играет роль ракурс камеры.
2. Нет, не реализовано. Поясню. В билде не будет отдаления камеры на такое расстояние. При отдалении камеры, в определенный момент, будет происходить переключение на стратегическую 2D карту.
1. Геометрия у нас упрощена до минимума, и малейшее её упрощение приводит к видимым искажениям, даже с такого расстояния. Тут играет роль ракурс камеры.
2. Нет, не реализовано. Поясню. В билде не будет отдаления камеры на такое расстояние. При отдалении камеры, в определенный момент, будет происходить переключение на стратегическую 2D карту.
0
Используете ли triangle strips? Хотя с оптимизированной сеткой это нетривиальная задача.
И вот в этих местах нет «дырок»? Там по сути разрыв в топологии. Может «дребезжать» на больших расстояниях.
![](https://habrastorage.org/r/w1560/webt/su/qo/pi/suqopidqedpspaw5hfod4t9czk8.png)
И вот в этих местах нет «дырок»? Там по сути разрыв в топологии. Может «дребезжать» на больших расстояниях.
![](https://habrastorage.org/webt/su/qo/pi/suqopidqedpspaw5hfod4t9czk8.png)
+1
Может «дребезжать» на больших расстояниях.
Кстати, да. В таких местах рекомендуется «сшивать» вершины.
0
В том то и дело, задача не тривиальна, так что пришлось отказаться от triangle strips.
Но такие места обходятся путем:
![image](https://habrastorage.org/r/w780q1/getpro/habr/comment_images/e2e/d33/184/e2ed3318485a07c7961e23f965f76cd5.jpg)
Все эти вертексы лежат на одной линии. А выделенные трисы как раз служат неким переходом, дабы нивелировать подобные разрывы.
Но такие места обходятся путем:
![image](https://habrastorage.org/getpro/habr/comment_images/e2e/d33/184/e2ed3318485a07c7961e23f965f76cd5.jpg)
Все эти вертексы лежат на одной линии. А выделенные трисы как раз служат неким переходом, дабы нивелировать подобные разрывы.
0
Мне кажется что сравнимый можно получить построив квадродерево.
0
Как боретесь с GC? Бывают микрофризы?
0
В Fortnite используют очень эффектный и эффективный метод оптимизации для повторяющейся природы: менять такие модели на хитрый набор спрайтов.
www.shaderbits.com/blog/octahedral-impostors
Третий пример:
www.shaderbits.com/blog/octahedral-impostors
Третий пример:
+3
Спасибо за ссылку, интересный подход.
0
На средней игровой карте, при максимальном отдалении и при большом скоплении пальмВот тут скрыта возможность оптимизации, которую Вы, кажется упустили. Дело в том, что на большом удалении многие элементы объекта становятся меньше одного пикселя, так что нет никакого смысла подробно анализировать и отрисовывать.
Следовательно, для каждого объекта надо иметь несколько векторных моделей — для разных расстояний. Дальше, кажется, очевидно — но могу разобрать подробно.
Далее: при отрисовке объектов есть несколько разных алгоритмов определения видимости объекта (и отдельно каждой его части). В некоторых алгоритмах можно применить такую оптимизацию:
Вся сцена (все имеющиеся объекты) выстраивается в иерархию. Например, допустим, у нас есть несколько людей в пустоте. Тогда:
- сцена = человек1 + человек2 + ...
- человек = туловище + голова + две руки + две ноги
- рука = плечо + предплечье + кисть (этот уровень разбиения можно совместить с вышележащим — т.е. рука не будет присутствовать в иерархии, а кисть будет сразу частью человека)
- кисть = ладонь + пальцы
Если обнимающий шар объекта не попадает в экран — его рисовать вообще не нужно. Т.е. можно выбросить сразу много заведомо ненужной работы.
Если обнимающие шары двух объектов при проецировании на экран не пересеклись — то эти два объекта никак не перекрывают друг-друга; так что незачем искать пересечения треугольников.
При использовании «лучей зрения»: если луч зрения не попал в обнимающий шар, то он не попадёт ни в какой элемент (треугольник) объекта.
0
Сразу замечу, что любое слагаемое всегда является частью суммы; однако, обнимающий шар слагаемого может выходить за пределы обнимающего шара суммы.
…
Если обнимающий шар объекта не попадает в экран — его рисовать вообще не нужно.
…
Если обнимающие шары двух объектов при проецировании на экран не пересеклись — то эти два объекта никак не перекрывают друг-друга
Я один вижу здесь противоречие?
0
Следовательно, для каждого объекта надо иметь несколько векторных моделей — для разных расстояний. Дальше, кажется, очевидно — но могу разобрать подробно.
Ну так это и есть LOD-ирование, о котором мы говорили чуть выше в комментариях.
Если обнимающий шар объекта не попадает в экран — его рисовать вообще не нужно. Т.е. можно выбросить сразу много заведомо ненужной работы.
У меня это работает по другому принципу, так как у меня все объекты находятся в тайлах, определение их видимости простая задача.
0
А почему не пирамидой лодов? При максимальном удалении большинство деталей ландшафта просто не видны особо и их можно «упрощать»
0
Вот куда еще упрощать эту пальму?
![](https://habrastorage.org/r/w780q1/getpro/habr/comment_images/21b/da7/327/21bda7327ae41e4706e5ee3ba745e792.jpg)
![](https://habrastorage.org/getpro/habr/comment_images/21b/da7/327/21bda7327ae41e4706e5ee3ba745e792.jpg)
0
Это не последний лод, можно ещё дальше собирая пачки пальмы в билдборды:
i.imgur.com/ss5CB1A.jpg
То есть простой треугольник/квад с запечённым изоражением вашей пальмы. С применением нормал-мапы смотрится вдалеке вполне сносно.
Ну и группы пальм рендерить всегда дешевле чем поштучно из-за DrawCall bottleneck
i.imgur.com/ss5CB1A.jpg
То есть простой треугольник/квад с запечённым изоражением вашей пальмы. С применением нормал-мапы смотрится вдалеке вполне сносно.
Ну и группы пальм рендерить всегда дешевле чем поштучно из-за DrawCall bottleneck
0
Так у меня и так рендерятся паки пальм, а не отдельные пальмы.
Идея с импостером понятна и на поверхности, но повторюсь, что не будет такого отдаления в игре, да не приходит на ум, как это реализовать с динамическим освещением.
Идея с импостером понятна и на поверхности, но повторюсь, что не будет такого отдаления в игре, да не приходит на ум, как это реализовать с динамическим освещением.
0
Sign up to leave a comment.
Оптимизация графики. Интересный Concave Hull