Comments 29
«Сразу напишу что про атласы и различные пулы, мы пробывали.»
Пробывали. Проверочное слово — Пробы.
Пробывали. Проверочное слово — Пробы.
Это восхитительно…
Хотя хотелось бы увидеть тестовый проект, чтобы не париться с копированием.
Хотя хотелось бы увидеть тестовый проект, чтобы не париться с копированием.
Более эффективно — гененерировать меш с иконками, те 4 вершины на иконку. Это позволит экономить шейдерные операции что будет особенно полезно для мобильных платформ.
(Этот меш обновлять только когда что-то меняется на миникарте, если нужно сохранять размер икононок вне зависимости от маштаба карта — не проблема — размер можно пересчитывать в вершинном шейдере, нужно будет дополнительно передавать размер в дополнительном вершинном UV канале)
(Этот меш обновлять только когда что-то меняется на миникарте, если нужно сохранять размер икононок вне зависимости от маштаба карта — не проблема — размер можно пересчитывать в вершинном шейдере, нужно будет дополнительно передавать размер в дополнительном вершинном UV канале)
Я с ваши категорически не согласен.Вы пробовали это вообще? Во время решения задачи, один коллега предложил попиксельно вписывать все это в текстуру. Ваш подход это напомнил. Ваш способ, скорей проиграет способу со спрайтами. Но давайте распишем алгоритм а вы поправите где я не прав.
1. Нужно генерить меш, скорей всего средствами юнити. Генерим ведь один меш? Верно. Берем 4 вершины, и преобразовываем их для UI, правильно? Иначе что случится при смене расширения? Дополнительно угол, верно?
2. Теперь нормали, ведь вы не хотите чтобы из-за нормалей меш было части полигонов не отображались, верно?
3. Теперь нужно наложить mat? И не простой, а семейства UI, иначе будут проблемы с масками.
4. Mat наложили, но он белый? Следовательно теперь нужно накинуть UV. Сложность этого алгоритма, боюсь даже представить.
5. Теперь все это запускаем, у нас на миникарте все двигаются. Что нужно сделать, с шага 1 все повторить и так каждый update. Ведь вряд ли возможен случай когда на миникарте не кто не двигается.
Можете сделать тест, против обычных спрайтов. Я например сильно сомневаюсь, что это хоть как-то эффективно
1. Нужно генерить меш, скорей всего средствами юнити. Генерим ведь один меш? Верно. Берем 4 вершины, и преобразовываем их для UI, правильно? Иначе что случится при смене расширения? Дополнительно угол, верно?
2. Теперь нормали, ведь вы не хотите чтобы из-за нормалей меш было части полигонов не отображались, верно?
3. Теперь нужно наложить mat? И не простой, а семейства UI, иначе будут проблемы с масками.
4. Mat наложили, но он белый? Следовательно теперь нужно накинуть UV. Сложность этого алгоритма, боюсь даже представить.
5. Теперь все это запускаем, у нас на миникарте все двигаются. Что нужно сделать, с шага 1 все повторить и так каждый update. Ведь вряд ли возможен случай когда на миникарте не кто не двигается.
Можете сделать тест, против обычных спрайтов. Я например сильно сомневаюсь, что это хоть как-то эффективно
1. Вершины генерируются в «пространстве карты» или в любом вам удобном. Преобразованием вершин в экранные координаты будет заниматься конечно вершинный шейдер.
2. Нормали не нужны. Мы ведь работаем со спрайтами ориентированными на плоскость камеры. Про неотображение полигонов — это вы про отсечение невидимых граней по нормали (когда dot(N,V) < 0) — это отключается.
3. В общем случае без материала конечно не получится. Но какой именно материалы и шейдер делать — это сильно зависит от конкретного подхода к организации сцены
4. В общем случае когда спрайты разного размера и максимально плотно упакованы в атлас — без UV не обойтись. Но где Вы тут видите СЛОЖНОСТЬ? Если же спрайты одинакового размера и лежат в атласе равномерной сеткой — достаточно передавать индекс спрайта и UV считать в вершинном шейдере.
5. Миникарты бывают разные. В вашем случае видимо она нужна для отображения динамических объектов (хотя использованные картинки намекают об обратном). В этом случае можно сгенерировать меш только один раз и передавать массив с положением, и поворотом спрайтов — как вы это сделали. Если на карте есть много и динамических и статических объектов — целесообразно будет разделить на 2 команды отрисовки, так что бы не обновлять кажды раз статические спрайты.
(статические — это те которые не двигаются в пространстве карты)
Все выше написано исходя из того что вы сделали большой цикл в пиксельном шейдере по всему массиву спрайтов. Это не эффективно тк этот цикл будет отрабатывать для каждого пикселя карты. В случае когда карта занимает 100*100 пикселей на экране это конечно не будет проблемой, но как только ее развернут на полный экран в 2.5К (хотя бы) разрешении — бюджет кадра будет почти гарантированно превышен. Я понимаю что практически это может не быть вашим случаем, но мы же тут обсуждаем эффективность, верно?
2. Нормали не нужны. Мы ведь работаем со спрайтами ориентированными на плоскость камеры. Про неотображение полигонов — это вы про отсечение невидимых граней по нормали (когда dot(N,V) < 0) — это отключается.
3. В общем случае без материала конечно не получится. Но какой именно материалы и шейдер делать — это сильно зависит от конкретного подхода к организации сцены
4. В общем случае когда спрайты разного размера и максимально плотно упакованы в атлас — без UV не обойтись. Но где Вы тут видите СЛОЖНОСТЬ? Если же спрайты одинакового размера и лежат в атласе равномерной сеткой — достаточно передавать индекс спрайта и UV считать в вершинном шейдере.
5. Миникарты бывают разные. В вашем случае видимо она нужна для отображения динамических объектов (хотя использованные картинки намекают об обратном). В этом случае можно сгенерировать меш только один раз и передавать массив с положением, и поворотом спрайтов — как вы это сделали. Если на карте есть много и динамических и статических объектов — целесообразно будет разделить на 2 команды отрисовки, так что бы не обновлять кажды раз статические спрайты.
(статические — это те которые не двигаются в пространстве карты)
Все выше написано исходя из того что вы сделали большой цикл в пиксельном шейдере по всему массиву спрайтов. Это не эффективно тк этот цикл будет отрабатывать для каждого пикселя карты. В случае когда карта занимает 100*100 пикселей на экране это конечно не будет проблемой, но как только ее развернут на полный экран в 2.5К (хотя бы) разрешении — бюджет кадра будет почти гарантированно превышен. Я понимаю что практически это может не быть вашим случаем, но мы же тут обсуждаем эффективность, верно?
Преобразованием вершин в экранные координаты будет заниматься конечно вершинный шейдер.
Это позволит экономить шейдерные операции что будет особенно полезно для мобильных платформ.
Вы можете это где-то продемонстрировать. Уж больно интересно как вы будете рендерить миникарту с другими слоями UI.
Как будет выглядеть ваш Update.
Все выше написано исходя из того что вы сделали большой цикл в пиксельном шейдере по всему массиву спрайтов.И как будет выглядеть цикл в вашем вершинном шейдере. Как вы решите вопрос с глубиной, когда 2 точки налезут друг на друга.
Спасибо за статью. Не очень понятно почему вы называете шейдером c# код и метод Update. Можно подробнее что метод делает? Я так понимаю, выдергивает изображение из атласа? По тексту все вроде понятно, а вот разобраться в коде не получилось…
Что за странные артефакты на границах у круглой маски? Где-то баг? :)
Годнота! Только сам шэйдер не нашел — забыли прикрепить или я плохо искал?
А давайте посчитаем фпс в реальной ситуации, а не в сферических конях.
Предположим ваша игра со стандартным способом рендеринга миникарты карты выдаёт 60 фпс — т.е время кадра ~ 16,66ms (из них 1.9 занимает вывод миникарты) теперь заменяем алгоритм на ваш получается время кадра 15,56ms т.е 64 FPS. Получили прирост 4 fps. Расчёты грубые, но в реальности будет различие ещё меньше. К тому-же мини карта на то и мини — чтобы висеть в правом верхнем углу и содержать адекватное размерам количество информации (минимальное), т.е разница ещё меньше будет. А то, что вы показываете на скринах, это полноэракранная карта и при ещё отображении можно вообще отключить рендеринг основной сцены и получить огромный fps используя любую технику отображения.
Что я хочу этим всем сказать, ваш способ безусловно интересный, но ненужный, по моему мнению вы занимаетесь преждевременной оптимизацией. Я не верю, что у вас в проекте нет других мест, которые дадут гораздо существеннее прирост производительности если их оптимизировать.
Предположим ваша игра со стандартным способом рендеринга миникарты карты выдаёт 60 фпс — т.е время кадра ~ 16,66ms (из них 1.9 занимает вывод миникарты) теперь заменяем алгоритм на ваш получается время кадра 15,56ms т.е 64 FPS. Получили прирост 4 fps. Расчёты грубые, но в реальности будет различие ещё меньше. К тому-же мини карта на то и мини — чтобы висеть в правом верхнем углу и содержать адекватное размерам количество информации (минимальное), т.е разница ещё меньше будет. А то, что вы показываете на скринах, это полноэракранная карта и при ещё отображении можно вообще отключить рендеринг основной сцены и получить огромный fps используя любую технику отображения.
Что я хочу этим всем сказать, ваш способ безусловно интересный, но ненужный, по моему мнению вы занимаетесь преждевременной оптимизацией. Я не верю, что у вас в проекте нет других мест, которые дадут гораздо существеннее прирост производительности если их оптимизировать.
Мы на реально и оптимизировали. С этого все и началось. Реальный выложить не могу, НДА, вот поэтому собрал на скорую руку тестовые сцены. Если бы у нас разница была в рн 5 10 фпс, думаете мы бы занимались подобным?
Спасибо за статью, пригодится.
Мне нравится как у вас в редакторе отображается иерархия объектов в сцене, это какое-то дополнение?
Мне нравится как у вас в редакторе отображается иерархия объектов в сцене, это какое-то дополнение?
Перечитал статью 2 раза и не понял что вы оптимизируете и каким образом вам помог шейдер?
Начал гуглить, находил много скажем так, нехороших решений, например таких как
Не делайте так, даже если хотите сделать быстро.
Почему тогда Юнити делают также?
Потому что глупо со стороны юнити учить делать правильно и соответственно сложно. Кто по урокам будет пытаться учить писать шейдеры и выдумывать более сложные механики. Со стороны юнити главное показать как это можно сделать, но то, что это совсем не годится для мобильных устройств — никого не волнует.
Тут вопрос не в том, правильно ли это, или нет — вопрос в использовании ресурсов. Урок юнити будет очень много жрать, а если учесть, что мобилки уж больно сильно болеют перегревом, то там каждый 1% нагрузки имеет значение.
Тут вопрос не в том, правильно ли это, или нет — вопрос в использовании ресурсов. Урок юнити будет очень много жрать, а если учесть, что мобилки уж больно сильно болеют перегревом, то там каждый 1% нагрузки имеет значение.
Тут принцип другой. Они карту не рисовали и иконки, они тупо рендерили все меши как есть. В этом случае, они жертвуют быстродействием против простоты, и здесь это оправдано. Они же не всунули какие-то дополнительные меши внутрь префабов.
Но если карта рисованная и схематичная, как например в WOW. То такое решение избыточно.
Тыц Вы автор сего. Так вот вы сделали схематично, что совсем не тоже самое как в этом примере.
Но если карта рисованная и схематичная, как например в WOW. То такое решение избыточно.
Тыц Вы автор сего. Так вот вы сделали схематично, что совсем не тоже самое как в этом примере.
Sign up to leave a comment.
Optimization Unity3d UI by GPU (for example minimap) или создаем миникарту без дополнительных камер и спрайтов