Unity: Всё, что вы не знали о разработке

Unity: Всё, что вы не знали о разработке pinned a photo

Итак, я завел сайтик, где буду размещать все события, а также вести блог (сейчас там можно найти все темы, которые есть в этом канале, но в более удобном виде).
Канал в ТГ остается и я буду делать посты тут тоже.

Регайтесь на событие, которое пройдет в эту субботу в 4 часа по мск:
https://www.unsafecsharp.com/events/ugui-Рассказываю-про-uiwindows

#event

Всем привет! Мне очень нужен ваш фидбэк для моего личного сайта. Можете написать все что считаете нужным:

https://docs.google.com/forms/d/e/1FAIpQLScgfoG3ayzhQcBnQM6IY-QnTzMk0-uIyKwks02x7lzEClnChQ/viewform?usp=sharing

Всем огромное спасибо;)

#feedback

Запись на тему как использовать ME.BECS:

https://youtu.be/g3_WBfb8ljM

#event #record

В мета-данных любого файла можно хранить свои данные.

Есть поле userData, в которое я обычно записываю json, чтобы можно было хранить вменяемую структуру.

Для этого можно использовать AssetImporter::userData.

#unity #metadata #lifehack

Напоминаю, что сегодня в 16:00 по мск будем разбирать ME.BECS. Кто еще не регался - велкам:

https://t.me/unsafecsharp/192

#event

Итак, пришло время сказать что я думаю о будущем и юнити.

Что сделали юнити?

Глобально они хотят вылезти из задницы, в которую сами себя засунули. Это напоминает наш релиз Mushroom Wars 2, когда мы хотели выпустить стим-версию, платную, без внутренних платежей, рекламы и прочего ф2п говна. Но вскоре поняли, что выжить можно только в ф2п. Поэтому приоритет резко стал мобильным и бесплатным.
По сути юнити сейчас находится в большом минусе, они потратили кучу денег, чтобы стать монополистом на рынке, а теперь им приходится платить по счетам, чтобы хоть как-то вернуться в ноль.
Изначальная политика юнити была криком о помощи, нежели чем реальной возможностью поправить свои дела. То есть они ожидали, что их политика не сильно понравится, но они не ожидали что этим решением они убьют рынок ф2п.
Я уже много раз писал почему это убивает ф2п рынок, думаю, что вы и сами понимаете это, если нет - го в комменты.

Что делать дальше?

На самом деле ничего. В реальности если ваша компания вылезает за рамки 1млн - вам нужно добавить 4% к расходам магазина (ну представьте, что apple стали брать не 30%, а 34%). Больно? Да. Сильно? Ну нет. Вы же не откажитесь от рынка ios, только потому что комиссия увеличилась на 4%?

Но есть и обратная сторона. Особенно для тех компаний, которые закупались в ноль, то есть тратили условно 1млн, получали обратно этот же 1млн, но при этом платили комиссию стору. То есть глобально вы привлекаете юзеров, которые когда-нибудь что-нибудь да заплатят.

Возвращаясь к теме поста…

На самом деле мы имеем такую реальность:
1. Юнити - скорее всего (на 99%) подписки останутся, то есть при достижении каких-то ревенью, вы должны будете платить 4% от гросса. Чем это плохо? Глобально это вы к 30% комиссии стора добавляете еще 4%. Много это или мало - каждый решает сам с точки зрения бизнеса. Возможно, что будет отдельное решение для топовых студий, но что-то я сильно сомневаюсь.
2. UE - даже если забыть про проблемы с размером билда, что там не сильно парятся насчет мобилок в принципе (глобально для мидкора можно и пережить) - с вас хотят 5% гросс, что собственно чуть больше, чем хочет юнити, при этом имея лучший бэкграунд для мобильной разработки. Понимают ли это эпики? Думаю, что да. Будут ли они с этим что-то делать? Думаю, что нет. У них другие приоритеты, и если вы думаете, что в UE все намного лучше, то вы просто забыли историю.
3. Годот - движок, который сделан программистами для программистов. Там есть редактор, да. Удобный? Нет. Много вопросов в принципе к архитектуре, которые вряд ли будут решены. До юнити годот настолько далеко, что это только год минимум надо потратить только на редактор (это если самим движком не заниматься). В целом из плюсов только шарп и плюсы, но прикрутить шарп вообще не проблема сейчас к любому движку. Для простых проектов пойдет, для более сложных - ну скорее нет.
4. Cocos - тут все просто. Движок, который не умеет в плюсы, ну или хотя бы в шарп - не движок, а какая-то хрень для веб-разработчиков. Я сам когда-то писал на js (ts тогда не было), поэтому я понимаю, что возвращаться на js/ts - это деградация.
5. Остальные движки. В реальности они не готовы к продакшену, совсем. У некоторых есть неплохие редакторы (flax, stride), плохая поддержка, т.к. на них просто забили (собственно, зачем конкурировать с юнити?).

Что будем делать мы?

Для текущих проектов - очевидно, что юнити. Для следующих проектов - не знаю. Думаю, что юнити глобально выйдут в плюс и все будет у них хорошо. Мы еще раз вернемся к этому вопросу в следующем году и посмотрим что успели сделать другие движки, но пока остаемся на юнити.

Это все мое личное мнение на происходящее, которое не имеет отношения к мнению компаний Azur Games, Jet Whales и Zillion Whales.

#unity #future

Unity: Всё, что вы не знали о разработке pinned a photo

Есть на SkinMeshRenderer галка "Update when offscreen".

Что делает скинмеш? Он на цпу (на других потоках) или на гпу (компьют скиннинг) запускает апдейт позиций вертексов на меше.

Что значит оффскрин? Это относится к SkinMeshRenderer'ам чьи баунды не попали во фрустум камеры.

Мы не можем запустить рендер до скиннинга.
Мы не можем запустить скиннинг ДО куллинга.
А куллинг мы не можем запустить ДО окончания просчета игровой логики (вдруг у вас в LateUpdate камера куда-то перемещается).

В итоге:
Если вы галочку оставите - у вас могут просчитываться скинмеши, которые не видно сейчас. И из-за этого может дольше рендериться кадр.
Если вы галочку уберете - у вас может дольше рендериться кадр из-за того, что скиннинг не параллельно с игровой логикой шёл.

Автор: @shiko_q
Пост: https://t.me/unity_cg/49798

#rendering #skinnedmeshrender

В эту субботу пройдет евент на тему ME.BECS, я расскажу как ее использовать и отвечу на ваши вопросы. Формат немного поменяем и я сначала расскажу об API и отвечу на интересующие вопросы, а затем мы сможем посмотреть на ваш проект и решить конкретные вопросы.

ME.BECS скачать можно тут:
https://github.com/chromealex/ME.BECS

Регистрация на событие тут:
https://unsafecsharp.timepad.ru/event/2594690/

#event #ecs

Запись на тему ME.BECS:

https://youtu.be/Ao1eoXbPWxw

#event #record

Напоминаю, что сегодня будем разбирать ME.BECS. Кто еще не зарегался - велкам:

https://t.me/unsafecsharp/187

#event

Unity: Всё, что вы не знали о разработке pinned a photo

Параметры метода (params)

Есть такая штука, которая позволяет вызывать метод, когда мы не знаем сколько параметров хотим туда передать:

void Method(params object[] arr)

Но есть некоторые особенности, которые нужно понимать:

1. По-умолчанию такой вызов создает новый массив (т.е. триггерит GC, что плохо):

void Method1(params object[] arr)
void Method2(object[] arr)

var arr = new int[10];
Method1(arr); // будет создан массив object[1] и к первому элементу присвоен массив arr
Method2(arr); // будет ошибка компиляции, т.к. object[] не соотвествует типу int[]

2. Если мы передадим точный тип массива, то это не будет создавать новый массив:

void Method1(params int[] arr)
void Method2(int[] arr)

var arr = new int[10];
Method1(arr);
Method2(arr);
// Эти 2 вызова идентичны

3. Любой вызов будет создавать новый массив:

void Method(params int[] arr)

Method(1, 2, 3)
Method(1)

Вывод: избегайте методов с params, особенно если это хот часть.

#gc #performance #params #basics

Давно у нас не было никаких событий, надо исправляться 🙂
В эту субботу (c 16:00 по мск) пройдет событие на тему ME.BECS, я расскажу как она устроена, отвечу на ваши вопросы.

Регайтесь по ссылке:
https://unsafecsharp.timepad.ru/event/2583150/

#event #ecs

В Unity есть возможность Indirect рендеринга: Graphics.RenderMeshIndirect

Начну чуть издалека.

Что есть дроуколл?

Это запуск GPU пайплайна по неким параметрам.
Вот вспомните ту самую картинку, которую вы видели:
вертексный шейдер -> геометрический -> .... -> фрагментный

Для дроуколла надо выставить эти параметры:
-переключатели на гпу для НЕпрограммируемых stages
-программы для программируемых
-забиндить буферы и прочие ресурсы

Основные буферы - это вертексный (позиции) и индексный (индексы вертексов).

Индексный буфер опционален, но важен для оптимизации, т.к. многие вертексы повторяются в разных треугольниках и для них нам не надо уже перевычислять позицию и вертексы можно упорядочить не по порядку как они в треугольнике располагаются, а оптимальным для производительности способом.

Что есть инстансинг?

это когда мы не делаем новые дроуколлы, а просто перезапускаем пайплайн X раз в рамках одного дк.
Для каждого перезапуска пайплайна мы просто меняем SV_InstanceID (видеокарта сама его меняет) - SV_InstanceID от 0 до X.
Мы не перебиндиваем ничего и не ждём команд от цпу - поэтому инстансинг очень быстрый.

Что есть индирект?

это когда количество запусков пайплайна, количество вертексов и индексы для них задаются не напрямую - с цпу, а так же рассчитываются на гпу - в компьют шейдере.

Но в рамках одного вызова, даже вызова индирект - мы не можем забиндить разные индексные оффсеты.

(p.s. схожим образом, кстати, работают Task и Mesh шейдера)

Что есть MDI?

Это когда гпу может сама решить сколько вызовов indirect ей нужно.
И не только запустить несколько вызовов пайплайна, но и индексные оффсеты сопоставить на разных вызовах самостоятельно.
Для этого гпу помимо номера инстанса - SV_InstanceID знает и номер текущей отрисовки.

MDI не на всех апи поддерживается, на некоторых реализации отличаются, на других делается фоллбэк, а на третьих вообще его нет.

Метод Graphics.RenderMeshIndirect позволяет рисовать MDI там где это поддерживается и делает серию обычных Indirect вызовов там, где MDI не поддерживается.
Однако, как показали тесты, семантика SV_DrawID поддерживается не везде =(

Автор: @shiko_q
Источник: https://t.me/unity_cg/48214

#rendering #graphics

https://t.me/madcsharp

@alexmtq создал канал про оптимизации и unsafe приколдэсы на шарпе и в дотнете.
Сейчас пилю либу для унификации ансефа по всем рантаймам. Будет работать как в Mono/IL2CPP, так и в настоящем дотнете, т.е когда юнитеки завезут .NET Core всё продолжит работать.
Основные фичи:
1. вызов методов без .Invoke (т.е без аллокаций), вызов нативных методов без обёртки через нэйтив.
2, Изменение длины и типа массивов — это полезно для бинарной сериализации, рентерпретации данных без дополнительных аллокаций итд
3. Изменение типа размера листов + thread-safe способ для добавления элементов, в том числе через Burst, без дополнительной аллокации NativeList<T>
4. Изменение стрингов без переаллокации
И много всякого другого.

AOT статик методы для компиляции

Совсем недавно ко мне обратился коллега с просьбой помочь с ошибкой, когда json не мог распаковаться и падал с ошибкой примерно такой по смыслу:
"Не могу найти конструктор с передаваемыми параметрами", а стек показывает, что где-то там через рефлексию создается инстанс (через Activator) и при вызове конструктора чет все падает.

И тут знаете, как в шуточках за 300, люди делятся на несколько групп:
1. Неопытные с ужасом идут гуглить ошибку, ничего не находят, идут дергать вторую группу;
2. Более опытные понимают, что тут как-то не очень все тривиально, идут в место где рефлексией создается какой-то объект и пытаются понять как же можно было накосячить создателям плагина, что оно не работает;
3. Ну и такие как мы с вами, которые в принципе уже понимают, что билд скорее всего il2cpp, что рефлексия - это плохо, что il2cpp ничего об этом знать не знает, а значит проблема просто в том, что метода нет после компиляции.

К чему я это все. Для исправления подобных ситуаций, il2cpp нужно "подсказать", что существует метод (или конструктор), для чего я обычно делаю в проекте файл AOT.cs:

public static class AOT {
   [Preserve]
   public static void Dummy() {
      new SomeClass().Method(); // не вырезаем конструктор и метод из билда
      ...
   }
}

Т.е. мы никогда не вызываем этот метод, но при сборке эти методы будут добавлены.
Вообще это касается всех вызовов через reflection и когда в проекте не указывается вызов.

#aot #il2cpp #error

Fluent-interface

Вы, наверное, слышали и встречали такую штуку, а некоторые даже писали.

instance.Method1().Method2()

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

Как?
Ну это довольно просто:
void Method() {…}
Меняем на
T Method() { return this; }
Где T может быть текущим типом, может быть интерфейсом (как в оригинале было и задумано, но структуры все портят).

Где?
Я использую такое в API своих ME.ECS/BECS для сборки фильтров и запросов.
Вне ecs я передаю настройки в виде структуры, которую я собираю как раз через такой подход. Ну и твинер у нас написан с таким же походом.

Зачем?
Лаконичность кода и легкость восприятия.

Пишите в комментах где вы используете fluent-interface подход.

#architecture #fluent #interface

Разбираемся с профайлером

Вообще я уже писал немного про это раньше, но решил расписать более подробно про каждый сэмплер, чтобы было понятно где искать проблему.

WaitForTargetFPS: Время, потраченное на ожидание целевого значения FPS, указанного в Application.targetFrameRate. Редактор не использует VSync на GPU, а вместо этого использует WaitForTargetFPS для имитации задержки VSync.

Gfx.ProcessCommands: Поток рендеринга охватывает всю обработку команд рендеринга. Часть этого времени может быть потрачена на ожидание VSync или новых команд из основного потока, что можно увидеть в Gfx.WaitForPresent.

Gfx.WaitForCommands: Поток рендеринга готов к новым командам, и может указывать на узкое место в основном потоке.

Gfx.PresentFrame: Поток рендеринга представляет собой время, затраченное на ожидание рендеринга и представления кадра графическим процессором, что может включать ожидание VSync.

Gfx.WaitForPresent: Когда основной поток готов начать рендеринг следующего кадра, но поток рендеринга еще не завершил ожидание представления кадра GPU. Это может указывать на то, что узкое место в GPU. Посмотрите на представление временной шкалы, чтобы узнать, проводит ли поток рендеринга одновременно время в Gfx.PresentFrame. Если поток рендеринга все еще проводит время в Camera.Render, узкое место в CPU, т.е. тратит слишком много времени на отправку вызовов отрисовки/текстур на GPU.

#profiler #profiling #performance #gpu #cpu