Обожаю работу с графикой за периодически прикольно получающиеся картинки :) Компьют шейдер просто разбросом 10к точек по кубу случайно :)

Классный VFX вихря :) И довольно простой в своей сути :)

https://realtimevfx.com/t/hovl-s-sketchbook/6983/105

Можно возвращаться в Москву :)

New Input System

Всем хороших выходных в первую очередь. А во-вторых, поговорим про новый Input System (ну как новый, довольно старый). Который Unity меня заставило по сути попробовать насильно XD

Как человек старой закалки с миллиардом своих решений для юнити бородатых версий, мне часто бывает просто лень переходить на какие-то новые системы. Это как с дизайном "зачем вы передвинули кнопку, раньше было лучше" (кряхтит) Но так как я работаю с VR и с Unity 2021 мне просто не оставили выбора, так как включая OpenXR сдк оно просит (довольно настойчиво) "Включи новую инпут систему"

Первое время всё было непонятно и неудобно, так как я полез в код. И пытался там создавать XR устройства, обработчики клавиатуры и т.п. (короче по стариночке всё) Пожрав немного кактус, я всё же пошёл искать тутор. Посмотрел https://www.youtube.com/watch?v=Yjee_e4fICc и тут я как всё понял :) Супер удобная система) В целом управление под всё что хочешь делается супер тривиально, и через гуй) Кайф. Особенно для того же VR, так как мне удобно иметь управление и на клаве для перемещения, и на стиках, смотря что я тестирую :)

Единственное из удобных пакетов Unity на который я пока вряд ли пересяду это Addresables, так как на Webgl я с ними очень много всякого интересного повстречал и мой менеджер ресурсов просто удобнее в ряде аспектов) Но инпут система первое время непонятно и очень непривычно, но потом становится супер удобно, когда вкурил концепт. Особенно если проект под несколько устройств и схем управления :)

Кастомизация профайлинга

Профайлинг — это самая важная часть оптимизации. Перед тем, как что-то исправлять лучше сначала получить проблему и найти в чём она заключается. И инструменты профайлинга в Unity во многом классные. Frame Debugger, да и просто профайлер дают очень много подсказок и информации. И тут недавно у Unity вышла статья про кастомизацию профайлера всякими кастомными счётчиками https://blog.unity.com/technology/customizing-performance-metrics-in-the-unity-profiler

И я даже сталкивался с забавным примером, где это супер полезно. Один из классов задач, которыми я занимаюсь — это визуализации огромных массивов данных. Графы на сотни тысяч вершин, сложные санлейн диаграммы и т.п. И основной прикол и проблема профайлинга этого дела — многопоточность и огромное количество данных. Когда в памяти лежит 100к вершин, то дип профайл особенно в многопоточном случае начинает сходить с ума. Поэтому я писал себе кастомные счётчики, которые выгружались в "отчёты" для понимания, что где надо подрезать) А теперь в Unity, есть такая удобная штука :) Надо будет поковырять)

Интересный репозиторий про VFX

Как можно заметить я обожаю VFX и компьютерную графику. Особенно интересной темой являются компьют шейдеры. Так как я всё же в первую очередь не игровик, а занимаюсь визуализациями данных для компаний, выставочными решениями и чем-то подобным (для игр я под заказ иногда делаю какой-нить VFX, но это скорее исключение) Поэтому мне больше интересен условный VFX в вакууме. Когда нужно сделать один шикарный эффект без размышлений об общей производительности) Частицы реагирующие на движение рук на киннекте или типа того, когда гарантировано можно рассчитывать на какую-нить 3060 и выше. И собственно поэтому очень часто работа идёт с платформами поддерживающими эти самые compute шейдеры)

И гуляя по просторам интернетов я нашёл клёвый репозиторий по этой теме со всякими примерами https://github.com/Kodrin/VFX-Essentials от парня из Unity Montreal, где много прикольных примеров :) Ну и в целом у него много прикольных репозиториев, которые можно поковырять, а это всегда дело полезное :)

Несколько инструментов которые пригодятся для VFX

В целом VFX сам по себе базируется на творческом использовании концепций из разных наук (не обязательно сложных и со знанием того, как пишутся уравнения Навье-Стокса или типа того) Тут до этого был пост с эффектом, который отлично это иллюстрирует :) И полезно иметь под рукой инструмент, который не требует знание блендера, чтобы получить нужный тебе примитив, генератор текстур всяких дебажных и т.п.

Metamesh

В целом эти ассеты круты, как пример генерации мешей и текстур по мета-информации. Но когда мне нужны специфичные примитивы — это бывает супер полезно. Так как через простой интерфейс не залезая в блендер я генерирую себе нужный меш для эффекта, что часто бывает кстати)

Metatex

Плюс минус тоже самое, что и метамеш, только для текстур. Бывает часто полезно, особенно как альтернатива тому, что я рассказывал в статье про градиенты) Мне не хватает в нём только ещё каких-нить шумов, с которыми у меня всё руки никак не дойдут (да и я забываю периодически) сделать реп. Да и статью) Так как шумы — это супер полезная вещь используемая много для чего, и не так важно уметь их генерировать, как уметь ими пользоваться. Но инструмент всё равно крутой :)

Desmos

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

Вот такой коротенький дайджест, может кому тоже пригодится :)

Немного кул стори

Забавная история про то, что важно делать. А что будет потом дело третье. Скажем так, наш мир слишком сложен, и никогда не знаешь, как и что сыграет. И на эту тему у меня много историй)

В университете у меня было очень много довольно странных идей, но я хорошо помню одну из них, которую мне немного жаль, что я не сделал (в основном так как я тогда ничё не понимал в бизнесе и прочем) :) То ли на третьем, то ли на четвёртом курсе я подумал, что прикольно было бы сделать приложение на тренировку дикции. Я тогда что-то увлёкся ораторским искусством и всей этой тематикой. И идея была относительно проста. Многие уже себе представили ML, распознавание голоса, сравнение и т.п. Спокойно — в те времена оно только начиналось, и максимум там был Speech To Text гугла, который я сразу отбросил, так как он слишком много "исправлял". А так как я тогда ещё не шарил за компьютерную лингвистику, что такое фонемы, как в целом разбирается и распознаётся голос — я сразу решил, что этот орешек не по мне) Тем более, что про стартапы я тогда вообще не знал, да и если бы и знал, ну это прям совсем не моя тема) Я не люблю отчитываться перед инвесторами, и если и брал когда-либо инвест или типа того, то скорее по принципам займов. Потому что я по своей натуре скептик и никогда не даю пустых обещаний "космических кораблей")

Но мы отвлеклись) Идея приложения была проста. Собрать в БД кучу скороговорок, сделать функцию записи голоса. Пользователь зачитывает скороговорку, потом переслушивает "как он справился". И основное удобство именно в удобном наборе скороговорок, чтобы не было скучно. И в те времена, когда "красивый калькулятор" и приложение "выпей пиво" — это было круто, идея норм. И полезно было бы потренироваться, и делается супер быстро. Сейчас уже может такое есть) И я его не сделал, так как подумал, что оно ничего не заработает) Хотя если бы в портфолио на третьем было бы такое приложение, то это (как я сейчас понимаю) дало бы мне очков в дальнейшем. Да и можно было чего-то заработать в те времена, но не сделано и не сделано)

К чему это я? Полезно что-то делать, особенно являясь студентом. У профессионала уже немного другое мышление и альтернативы, а вот в студ. годы, я тогда ещё не знал, что попаду в геймдев, но всё могло сложиться довольно интересно. И мне до сих пор интересно, чтобы изменилось доделай я тогда ту идею)

Почему важно делиться опытом

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

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

Так зачем же делиться? И тут стоит разделить на личные цели и общие. Начнём пожалуй с общих)

Программисты — это братство

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

Сложные знания базируются на множестве простых знаний

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

Это не исчерпывающий список конечно, но тем не менее на мой взгляд, это самое важное) Но поговорим про личные

Карьера

Для тех кого интересует работа, когда у вас есть несколько опенсорс решений, репозиториев со звёздочками, публикаций и т.п. к вам как-то меньше вопросов на тему вашей экспертности. Я не беру ещё всякие визы для одарённых. Но суть в том, что я тестовые не делал очень давно, и почти всегда имею пачку офферов. Просто меня не интересует штатная работа от слова совсем, благодаря тому, что у меня много статей и публичных репов, где легко понять, что я умею) Тоже самое с фрилансом, не надо особо объяснять, почему твоё время столько стоит)

Я хотел написать что-то ещё, типа "личного бренда" или другой фигни, хотя на самом деле это всё про карьеру) Ещё конечно "самореализация", и то что иногда (у меня такое даже было) можно продать кастомизацию своих же решений, если бизнес хочет какую-то финтифлюшку :)

Меня просто как-то всегда вдохновляли общие причины. И на самом деле радует, что в сравнении с тем же 2017 годом, уже видно что Unity комьюнити на самом деле сильно выросло и появилось много крутых ребят, что в целом растит общий уровень разработчиков) В целом средний Unity программист — это уже человек знающий очень много, что значит будем делать больше всяких крутых и прикольных штук :)

MediaPipe

Ах да, моя одна из основных экспертиз — это трекинг. Я всё же им уже 6 лет занимаюсь) И тут я нашёл неплохой курс, хоть и на питоне, по медиапайпу) Конечно удобнее было бы разбить его на множество уроков, а не на один на 6 часов. Но тем не менее он неплохо разбирает то, как работать с медиа пайпом https://www.youtube.com/watch?v=01sAkU_NvOY

А что есть медиапайп? По сути — это крутая технология от гугла с готовыми моделями для различных видов трекинга Hand, Face Landmark, Facemesh, Holistic и так далее. И у трекинга + Unity прикол такой же, как и у шейдеров. Большая часть материалов по трекингу, по компьютерному зрению написаны на питоне. И в целом всяких технологий больше всего именно на питоне) И тут есть три пути :)

1. Уметь читать код и портировать или как правильно юзать порты библиотек

Особенно часто я это делаю с OpenCV. Конечно в отличии от питона у шарпа нормальная многопоточность, и много других фишек. Но если брать этот порт OpenCV для Unity и искать примеры на юнити, и на шарпе — забейте. Родные примеры там отвратительные, а инфы в контексте юнити очень мало. Но так как это именно прямой порт, то очень легко использовать подходы, которые люди делали с помощью Python или Java. Или даже C++. По сути самый кроссплатформенный путь, который подходит много кому. И с медиапайпом та же история, есть плагины порты, но понастоящему получится ими пользоваться, читая решения на Python и портируя в Unity)

2. Писать серверы

Привет выставочники — http ваш лучший друг. Очень часто на выставках можно договориться поставить сервачок, что не подходит скажем для всяких приложений в стор. И там развернуть Python Flask + нужную технологию. И всё гонять посредством рест апи. Ну либо сокетами, что ещё меньшие задержки даёт. Но в рамках локальной сети я это проверял очень много раз, и это вполне валидное решение) На хабре в комментах был спор на тему моего Web Gamepad, но я то в выставках такое часто делал и знаю на 100%, что это работает) Всё зависит от требований к системе :) Просто так как десктоп позволяет в разы больше планшетов и телефонов, то благодаря подобным схемам можно делать много очень крутого в рамках выставок. Да либо же даже корпоративных решений. Для одной крупной корпорации мы делали анализатор документов, и часть решения с распознаванием текстов решал Google Tesseract развёрнутый на шарпе в их облаке. Запросом отправлялась картинка, ответом текст документа)

3. Интегрировать другие языки в Unity

Вот тут уже надо понимать, что такое CLR, что такое C++/CLI как между собой линкуются разные языки и т.п. Нельзя не упомянуть, но это тот подход, которым надо пользоваться редко, с чётким пониманием, что и зачем вы делаете. CLR позволяет нам очень много, но это будет работать не везде. Так же как и всякие другие механизмы операционных систем. Что ваш код в некотором смысле может быть мультиязычным безо всяких интерпретаторов. А просто в правильно скомпилированных библиотеках. Но это сложно, имеет в себе кучу проблем и трудно поддерживаемо. Так делается с очень чётким ответом на вопрос — зачем)

В общем курс интересный, трекинг — это супер интересно, кто интересуется темой, пусть он и на питоне, я выше написал, как можно скрестить и поиграться) С пайпом при набитой руке можно делать довольно много прикольных штук. Я всё хочу как-нить через паттерн матчинг сделать распознавалку чего-то вроде гифки ниже :)

Физика и коллизии

Помню в универе, ещё во времена флеша, когда нас учили Action Script 3, одной из задач было сделать бильярд. Сейчас конечно в Unity все пользуются уже готовыми абстракциями над логикой коллизий и PhysX. Но всё же я считаю полезно знать, а чем различаются Discrete и Continuous Collision, да и в целом поднаготную этого дела. И вот интересный урок разбирающий это дело и часть алгоритмов используемых для определения коллизий https://www.youtube.com/watch?v=eED4bSkYCB8 :)

Синтаксический сахар — добро

Я всегда не понимал мнение Рихтера на тему того, что синтаксический сахар — зло. В книжке, которую должны прочесть все без исключения — "CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5 на языке C#" от Рихтера. Причём несколько раз прочесть и перечитывать, если вы работаете с C#, .Net, Unity и т.п. Единственное она сложная, поэтому она конечно не для совсем новичков)

О чём это я? Ах да! В книжке Рихтер говорит о том, что нужно вместо int (да, это тоже сахар) писать System.Int32. И в этом есть здравая мысль, так как новички сразу видят, что даже базовые типы часть фреймворка .Net. Но это исключает, на мой взгляд, главную потенциальную возможность. Оптимизация синтаксического сахара.

Компиляторы развиваются, дорабатываются, и суть в том, что явно написанный код можно ускорить только ускорив реализацию самих операций. Допустим List.Sort сделать быстрее оптимизировав алгоритм. Но это не единственная возможность. Компиляторы на самом деле очень умные, и тут бывает много заблуждений. Как-то на собеседовании одном мне задали вопрос. Что быстрее?

1) "a" + "b" + "c"
2) string.Concat("a", "b", "c")

И по мнению собеседующего первый вариант разворачивался из сахара в string.Concat(string.Concat("a", "b"), "c") Я в это собственно не поверил (хотя так и правда было в каких-то первых версиях .net) и придя домой за свой комп решил проверить. В итоге, оказалось что в последнем шарпе на тот момент всё в разы хитрее. Где-то даже компилятор подставлял string.Intern вместо сахара, просто предсказывая значения в цикле. Что меня удивило) Поэтому сахар позволяет переписать код, который написал программист — оптимальнее

Конечно оптимизации бывают и с явным кодом. foreach разворачивается в for где это возможно, и много других мелочей. Но с сахаром процесс оптимизации удобнее, и что главное — понятнее. Так как если ты в явном виде зачем-то пишешь string.Concat(string.Concat("a", "b"), "c") ну система должна думать. "Он написал явно", "он знает что он делает". А с сахаром "ага, вот что он намерен сделать, ща я сделаю это нормально"

Поэтому я считал и считаю, что сахар — это добро и надо любить сахар) И хорошо что шарп развивается так, что в каждой новой версии сахара всё больше :)

Играясь с компьют шейдерами иногда получаются визуально прикольные штуки. Это 1 миллион случайно брошенных точек, где скорость движения точки равна цвету :) Получается красивый расширяющийся цветовой куб состоящий из огромного числа точек, по котором можно летать. При этом нагрузки никакой, так как движение так же описано в шейдере (но это конечно тривиальный шейдер) :)

Catlike Coding

Если вы вдруг не слышали про этот сайт, то очень советую. Хотя на мой вкус они иногда слишком часто говорят что-то вроде "это очевидно" и приходится догадываться, что там было между шагами. Но всё равно там очень много крутых туториалов. Вот например по компьют шейдерам https://catlikecoding.com/unity/tutorials/basics/compute-shaders/

Процедурные меши и триангуляция

Несколько лет назад я писал небольшую статью про триангуляции. Основной профит от статьи скорее в этом репозитории. Я даже недавно не поленился запихнуть это всё в пакет (хотя ещё нужно будет сделать свой кастомный скоуп пакетов на досуге)

Уметь в Unity манипулировать данными меша довольно полезный навык. И в 3д, и в 2д. В статье указан базовый пример игры, где это вообще маст-хев. Был раньше такой класс головоломок-платформеров, которые проходились за счёт рисования простых форм, по которым дальше нужно было карабкаться. Но на самом деле задач больше, допустим меш каттинг. Если в разрезаете меш плоскостью, то в данном случае вы получаете на самом деле набор контуров (2д). По которым можно построить меш и наложить материал, который должен быть на разрезе (в играх аля beat saber и fruit ninja можно использовать такой подход). И многое другое на самом деле, вопрос тут ограничивается фантазией. При попадании пули натурально разбивать стекло (и да, это можно сделать в реалтайме), уточнение сетки меша для аккуратной деформации металлической пластины при попадании той же пули. В целом в мат. моделировании огромное внимание уделяется понятию "Mesh Refinement" В тех местах, где расчёты нужны точнее. И зачем иметь постоянно огромную сетку меша, если менять её можно динамически при достаточно быстром алгоритме триангуляции :) А на современных мощностях это вполне реально)

Но вся история выше про 2д триангуляции. Что касается 3д, то там задача в разы любопытнее. И есть тоже разные репозитории (по большей части на питоне) типа такого https://github.com/nmwsharp/learned-triangulation Так как есть такая интересная задача, что на вход вам идёт облако точек, а вам по ним нужно построить меш. И есть с выпуклыми формами всё как всегда довольно просто, то вот восстановить меш по облаку точек типа того же шкафа — не самая простая задача. Хотя когда я ковырялся в чём-то аналогичном, я нашёл много интересных инструментов. Один из самых крутых — это Open3D. Огромная опенсорс либа, которая имеет в себе очень много интересных методов по манипуляции 3д данными. Собственно в том числе строить меш по облаку точек)

В общем неважно, работаете вы с 2д или с 3д графикой, но навык манипуляции мешами штука очень полезная, которая позволяет делать очень много крутого :)

Написал тут статью про свой путь в IT. Может кому будет полезно :) https://habr.com/ru/post/664854/

Прикольный тутор по простенькому VFX на обелиске https://youtu.be/ZtM7Z9HS0W4

Draw Call

Все кто не особо вникал в работу графики обычно опираются в оптимизации на 3 метрики. Draw Call, Vertices и Triangles в профайлере. (Ну и на фпс конечно) Юнити придумали относительно неплохую систему "универсальных метрик", которые легко собирать и просто объяснить. Но тут есть свои нюансы. В целом я рекомендую прочитать Render Hell, чтобы иметь общее представление, как работает гпу. Хотя и конечно с упрощениями, но там отлично всё объясняется)

В сущности Draw Call — это вызов отрисовки. То есть CPU готовит для ГПУ команду с параметрами что отрисовать и как, и кладёт её в CommandBuffer. (Именно параметрами, сами текстуры, вертекс буфферы и т.п. уже находятся в VRAM) И вот тут начинают играть роль некоторые нюансы, которые профайлер не показывает, но о которых надо помнить. Основное это видеопамять (VRAM) и шина, о чём часто забывают.

Чтобы что-то отрисовать нужно загрузить информацию из VRAM в ГПУ

Современные ГПУ конечно устроены сложнее, там есть даже L1 и L2 кеш, и всё это зависит от гпу к гпу. Иногда бывает полезно почитать мануалы, особенно если вы разрабатываете под конкретное железо. Упрощённо, так как процессоры не имеют своей огромной памяти, нужно загружать всю информацию для отрисовки через шину. Шина гпу — это канал соединяющий VRAM и GPU. И у него есть ширина — параметр который отвечает за то, какое количество информации шина может обработать за единицу времени.

В контексте Unity количество Vertices вам конечно скажет сколько вы грузите из VRAM в GPU вертексов. Но обычно пропускная способность шины исчисляется всё же в байтах, поэтому это не полное представление. Очень важным является число параметров, которые вы храните в вертексе. Каждый float32 допустим — это 4 байта. То есть скажем вы не пользуетесь нормалями, но зачем-то храните их в вертексных параметрах, А это 12 байт (float32 x 3) информации на каждый вертекс, что при большом числе вертексов может сказываться на перфомансе. Для примера при 60 фпс и рендере модели в 500к вертексов у вас будет шина загружаться ещё на 360 мб в секунду дополнительно информацией, которая никак не используется. Даже если 3д моделеры зачем-то рассчитали нормали, то лучше в настройках импорта поставить None, если вам они не нужны)

Батчнутый меш пойдёт на гпу целиком

Я даже сам так когда-то делал, объединяя всю сцену в одну модель и один материал. Или же многие ассетом для батчинга мешей так пользовались, но у этого есть проблема. Если обратить внимание даже на статс Unity (но это абсолютно логично) Если вы видите в камере даже 1 вертекс меша, то но гпу пойдёт весь его вертекс буффер. И зачем вам грузить лишнюю информацию, которую вы даже не видите. Чтобы снизить Draw Call, но при этом возможно даже негативно сыграть на производительность?

В одном проекте давным давно я так делал и не понимал: "А что не так?" В одной модели в 3д игре была вся комната. Батчить и разбивать меши на группы лучше осознано, понимая как это работает. Чтобы опять таки шина GPU вывозила то, что вы от неё хотите. Комбинировать меши по логике геймплея, тому как игрок перемещается и смотрит на 3д объекты и так далее.

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

Что не так с IF в шейдерах

Самый сложный вопрос на который я когда-либо искал ответ: "Почему в шейдерах плохо использовать IF?" Но тут нужно знать где искать. Иногда полезно перечитывать старые книжки, так как Рендер Хелл я читал последний раз в универе, а эта информация там была во второй книге. Просто когда мало что понимаешь немного по-другому воспринимаешь и запоминаешь информацию)

Полный ответ на этот вопрос во второй лекции этой крутой серии лекций :) Но дело в методе под названием лок-степ. Все ядра процессора на гпу выполняют одну и ту же команду с разными данными о пикселях и вертексах. По архитектуре параллельных вычислений это невозможно, чтобы часть ядер выполняло одну команду, а часть другую. И вот как работает в этом случае IF. Сначала выполняются все команды одной части IF-statement, но при этом часть ядер "спит" из-за переданных параметров. Потом "спящие" ядра просыпаются и выполняют ту часть, что была в else, а отработавшие ядра начинают спать)

У Unity в мануалах есть так же неплохой набор статей про бранчинг, и как юнити что оптимизирует, что тоже полезно почитать. Так как есть исключения в истории выше, если скажем компайл тайм понятно по какой ветке пойдёт шейдер. Но мне всегда было интересно в чём проблема на низком уровне. А то все знают, что if в шейдере — это плохо, что это бранчинг. Но я нигде не мог найти внятного и подробного объяснения "почему?" :)