Unity3D Ускорить отрисовку 2D анимации в разы? Легко

[Leopotam]

А если сиквенс анимации сделать не в линию, а квадратиком (допустим, 8х8 спрайтов) + подогнать размер под степень двойки + отрезать альфу в отдельный атлас, то можно получить возможность аппаратного сжатия текстур (цвет и альфу придется смешивать 2 выборками в шейдере), что еще ускорит весь процесс + загрузку.

[Philipp0K]

Действительно можно пакавать и квадратом, это приводит к добавлению всего 1 действия в вертексном шейдере.
В реальности полезнее использовать «полоски», с различными анимациями и дополнительно кодировать в цвете индекс текущей анимации, так можно расширить функциональность для проигрывания различных анимаций: ходьба, бег и тд и тп. В принципе вариантов применения и модификации может быть множество.

[Ichimitsu]

Спасибо за статью, полезно.

[Igor_Sib]

В инете был доклад Евгения Овчаренко — Lots of 2d кажется назывался, поищите — там он рассказывал как сделать быстрый рендер через партиклы, реально очень быстро работало. Объективности ради можно было бы сравнить еще тот способ.

[Leopotam]

Еще вариант — убрать нагрузку от батчинга, потому что юнити тупо проверяет баунд каждого меша на попадание в frustrum камеры и добавляет его в динамик-батчинг. Сделать меш из N*4 вертексов, где N — максимальное количество юнитов, инициализировав их в ноль и обычными квадами по 2 треугольника. Потом в апдейте просто двигать по 4 точки в нужную позицию юнита (обновлять нужно только позиции вертексов и переливать в меш), а в шейдере уже раздвигать их на определенный размер по вектору, заданному, допустим, в uv, а направление брать из z координаты вертекса — получится этакий инстансинг.

[Leopotam]

Ну и в догонку — сорцы на гуглодрайве да еще и с авторизацией? Годная идея, гитхаб / гитлаб / битбакет зафейлились и должны быть немедленно свернуты.

[Philipp0K]

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

[Leopotam]

А почему, кстати, в шейдере (в репе) в v2f используется сигнатура COLOR? Вроде как должна быть сквозная нумерация TEXCOORD0..TEXCOORDn для всех интерполяторов.

[Philipp0K]

Для передачи цвета вертекса используется сигнатура COLOR и как раз она и сквозная, если передается и в фрагментный шейдер.
http://docs.unity3d.com/Manual/SL-VertexProgramInputs.html

[Leopotam]

Никакой сквозной (автоматической) передачи нет, данные копируются / модифицируются в вертексном шейдере, а между вертексным / фрагментным шейдером должны передаваться POSITION (или SV_POSITION) + TEXCOORD0..TEXCOORDn:
http://docs.unity3d.com/Manual/SL-ShaderSemantics.html

Many modern GPUs don’t really care what semantics these variables have; however some old systems (most notably, shader model 2 GPUs on Direct3D 9) did have special rules about the semantics:
TEXCOORD0, TEXCOORD1 etc are used to indicate arbitrary high precision data such as texture coordinates and positions.
COLOR0 and COLOR1 semantics on vertex outputs and fragment inputs are for low-precision, 0–1 range data (like simple color values).

Те лучше не экспериментировать и использовать сквозную нумерацию (в которой уже можно указать точность типа).

[Philipp0K]

Точность и указана как fixed4 т.к. цвет вертекса передается в Color32. В данном примере вертексный шейдер НЕ модифицирует этот цвет и передает в франментный. Использование интерполяторов COLOR, как во входных, так и в выходных данных вертексного шейдера показана в документации Unity3D в разделе Visualizing vertex colors по ссылке, что привел в предыдущем посте.
Что касается точности данных при вычислениях fixed\half\float, то достаточно давно проводил исследования по этому поводу и, как результат, получилось, что на современных девайсах никакой заметной разницы не было.