Альтернатива зед-сортингу

[WhiteDevil]

Преведы!
Поднимаю все те же темы.. 2Д игра, много двигающихся и статических плашек с прозрачными текстурами, которые должны сортиться друг меж другом.
Присутствует крайняя необходимость в батчинге, но сортинг все ломает и дробит. Для ПК какбэ пофиг, но айосу очень очень надо
Над решением бился очень долго, но так и не было найдено нормального. Так что видимо остается искать лишь альтернативный вариант, один из которых было по-кадровое вшивание текстур, напрямую, в большую текстуру, которая ложится на одну единственную плашку. Как оказалось, операции(GetPixels\SetPixels) с большим количеством пиксельных массивов сами по себе являются очень трудоемкими, по-крайней мере вызываемые через скрипты.
Сделать такое например через пост-эффект представляется чем-то страшным и неудобным, потому что в шейдер придется передавать данные о позициях объектов и много чего другого.
Если есть какой-либо другой вариант, подайте хотя-бы идею. Лучшим вариантом конечно было бы починить батчинг при нормальном зед-сортинге скриптом
Всем спасибо..

[burlak]

Странно, это второе упоминание про медленный батчинг... Не замечал такого...

Если количество z-уровней фиксировано - можно реализовать через шейдеры - слепить нужное количество шейдеров с разными значениями тега Queue и применять их в зависимости от уровня спрайта.

[gnoblin]

а какой шейдер ты используешь?

[gnoblin]

Странно, это второе упоминание про медленный батчинг... Не замечал такого...

Если количество z-уровней фиксировано - можно реализовать через шейдеры - слепить нужное количество шейдеров с разными значениями тега Queue и применять их в зависимости от уровня спрайта.

Не, тут речь о том что бачинг не работает (а не тормозит).

Фишка с очередью отрисовки - прикольная, я только недавно узнал что так можно .

[WhiteDevil]

Спасибо за ответы
У мну блендовый шейдер. Графика вся попиксельная, катаут шейдер шефу совсем не нравится
Медленное получается запекание в текстуру (но это пока оставим), а батчинг просто сеется. Его работу я проверяю в PerfHUDe, и реально выходит, что без сортинга все объекты слеплены. При сортинге (оффсет мизерный), плашки практически делятся либо на мелкие группы, либо вообще сами по себе. Вся суть заключается в сортировании движущихся объектов относительно статических. И тех, и тех при максимальной нагрузке .. ну по 500 каждый. Так что уровней сорта там не 5 и не 10. Сотни. Так что очереди отпадают Да и все-равно гордыня хочет все 1000 слепленных объектов, чем рядочки по 50-100
Только сейчас осознал, что в принципе может помочь система, использованная в SpriteManagerе, там ведь что-то вроде мануального батчинга и получается, когда меш создается динамически из большого количества повторяющихся объектов.

[gnoblin]

а причем здесь вообще запекание сетпикселем?

[WhiteDevil]

Ну, теоретически, имея позиции всех объектов в сцене и, что важнее, их зед-координаты, можно запекать текстуры этих объектов, в порядке back-to-front судя по зед, в одну большую текстуру и, в резалте, выводить лишь одну большую плашку с этой текстурой. Таким образом, ресурсы тратятся не на отображение графики вообще, а на покадровое запекание. Вот и говорю, что метод лишь запекания оказался дорогим, используя только юнити-функции. Используя .НЕТ библиотеку, производительность увеличилась, но недостаточно

[artk]

А для частиц SpriteManagerе принесет выгоду в скорости или нет? И есть ли для них готовая оптимизация.

[DbIMok]

artk хотите обсудить SpriteManager vs Particles, создайте отдельную тему (создайте систему с 1000 частицами, посмотрите на 1 ДК и сотни FPS и подумайте, хотите ли вы ее "оптимизировать")

хотелось бы видеть что такое "сортинг все ломает и дробит". сотрудник писал матч3 (коллапс) для iPad, это подложка, пиецы, блоки, "заморозка" - 4 слоя до 200 полупрозрачных элементов в каждом + сзади бэкраунд полупрозрачный с облаками + сверху всего этого разлетающиеся партиклы/эффекты/надписи. никаких трюков вроде комбайна мешей и прочих запеканий, кроме встроенного динамического батчинга не использовалось.

[WhiteDevil]

Ну с этим все просто. Три теста только со статическими объектами. С динамически создаваемыми обстоятельства во много раз хуже, дробление происходит еще сильнее + глюки с вертексной анимацией в шейдере.

Первый тест: рисуем много травок.

Скрытый текст: показать

1 дк для задника, 1 дк для батча травки

Тест два: рисуем домики.

Скрытый текст: показать

1 на задник, 1 на домики

Тест три: вместе.

Скрытый текст: показать

Практически каждый домик сам за себя. Травка поделилась на горизонтальные уровни, около 15 уровней.

Хочу подметить, что в первых двух тестах сортинг присутствует. Просто задействован лишь один материал в одной очереди (что и было посоветовано в одной из далеких юните-презентаций). В третьем тесте два материала, и все собсно ломается. В полном проекте этих материалов вобщем.. мягко сказать, намного больше
Так что для полноты....

....Тест четыре! Снова все вместе, но без сорта.

Скрытый текст: показать

3 дк

Я бы глаз отдал, чтоб посмотреть как ваш коллега решил эту проблему

[DbIMok]

да не было у него никаких проблем. в том, глючном 3-ем скрине с 25 дк странны не только они но и 4 текстуры (хотя вроде должно быть 3? а то и вообще 2). где-то в коде ошибаетесь, что-то делаете неправильно. домики и травку можно держать в 1 атласе, выводить можно на 1 плейне через 2 UV (если логика позволяет).

[WhiteDevil]

Четвертая текстура это случайно попавший в сцену курсор
Делаю еще 4 теста, в пустом проекте, на совсем другой машине.

Тест один

Скрытый текст: показать

Тест два (не обращать внимания что объектов несколько, это первая попавшаяся текстура )

Скрытый текст: показать

Тест три

Скрытый текст: показать

Тест четыре (без сортинга)

Скрытый текст: показать

Схожесть тестов только в использовании одной и той же версии юнити - 3.4.0
Сортинг - лишь одна строчка:

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

using UnityEngine;
using System.Collections;

public class sorting : MonoBehaviour {

        void Awake () {
                transform.position = new Vector3(
                                        transform.position.x,
                                        transform.position.y,
                                        transform.position.y/10f);
        }      
}

Приложение А.
Пятый тест конечно заслуживает отдельного скрина, но он "почти" не отличается от предыдущего. Вобщем если использовать катаут шейдер, то батча будет два. Но как я говорил, катаут использовать не могу. Да и как оказалось он в 2 раза медленнее блендевого на айпаде, что.. странно.

Вобщем вывод такой, я его сделал еще давно, поэтому пришел именно за альтернативой решения.
Бленд + сортинг + несколько материалов в одной рендер очереди = батчинг брейк
Я буду счастлив оказаться неправым

[burlak]

Походу ты прав.

Если включить "капитана очевидность", рисование транспарентов подразумевает рисование поверх существующей картинки. Т.е. когда мы рисуем травку поверх мячика, мячик уже должет быть отрендерен предыдущим ДК. Если же мячик в свою очередь нарисован поверх травки, то данная травка должна быть отрисована еще одним ДК. Получается - сколько уровней с различными материалами, столько ДК. Как то так.

Единственное спасение - единый атлас текстур для всего что перемешано на экране.

[DbIMok]

да, батчит, но генерит ДК, если не задавать renderQueue.

[WhiteDevil]

Ну окей, а как себя тогда поведет SM?
Даже если материалов несколько, присутствует возможность получения одного отсортированного биг-меша?