Открыть список
Как стать автором
Обновить

Комментарии 11

А если сиквенс анимации сделать не в линию, а квадратиком (допустим, 8х8 спрайтов) + подогнать размер под степень двойки + отрезать альфу в отдельный атлас, то можно получить возможность аппаратного сжатия текстур (цвет и альфу придется смешивать 2 выборками в шейдере), что еще ускорит весь процесс + загрузку.
Действительно можно пакавать и квадратом, это приводит к добавлению всего 1 действия в вертексном шейдере.
В реальности полезнее использовать «полоски», с различными анимациями и дополнительно кодировать в цвете индекс текущей анимации, так можно расширить функциональность для проигрывания различных анимаций: ходьба, бег и тд и тп. В принципе вариантов применения и модификации может быть множество.
В инете был доклад Евгения Овчаренко — Lots of 2d кажется назывался, поищите — там он рассказывал как сделать быстрый рендер через партиклы, реально очень быстро работало. Объективности ради можно было бы сравнить еще тот способ.
Еще вариант — убрать нагрузку от батчинга, потому что юнити тупо проверяет баунд каждого меша на попадание в frustrum камеры и добавляет его в динамик-батчинг. Сделать меш из N*4 вертексов, где N — максимальное количество юнитов, инициализировав их в ноль и обычными квадами по 2 треугольника. Потом в апдейте просто двигать по 4 точки в нужную позицию юнита (обновлять нужно только позиции вертексов и переливать в меш), а в шейдере уже раздвигать их на определенный размер по вектору, заданному, допустим, в uv, а направление брать из z координаты вертекса — получится этакий инстансинг.
Ну и в догонку — сорцы на гуглодрайве да еще и с авторизацией? Годная идея, гитхаб / гитлаб / битбакет зафейлились и должны быть немедленно свернуты.
Накладочка с гугл драйвом получилась, перезалил на битбакет. Спасибо за совет.
А почему, кстати, в шейдере (в репе) в v2f используется сигнатура COLOR? Вроде как должна быть сквозная нумерация TEXCOORD0..TEXCOORDn для всех интерполяторов.
Для передачи цвета вертекса используется сигнатура COLOR и как раз она и сквозная, если передается и в фрагментный шейдер.
http://docs.unity3d.com/Manual/SL-VertexProgramInputs.html
Никакой сквозной (автоматической) передачи нет, данные копируются / модифицируются в вертексном шейдере, а между вертексным / фрагментным шейдером должны передаваться 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).

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