Написал тут статью про свой путь в 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 в шейдере — это плохо, что это бранчинг. Но я нигде не мог найти внятного и подробного объяснения "почему?" :)

Интересная инфографика по задержкам

Не особо правдивая правда в плане реальных значений, она скорее интересна с точки зрения порядков. https://gist.github.com/hellerbarde/2843375 Но красивые концепции никогда не про точность :) Опираться бы я на них не стал, так как строчка по сеть выглядит весьма подозрительно. Хочется спросить "а в каком случае? и при какой длинне провода?". Но как концепт — красиво :)

Кажется мне начинает нравится визуальное программирование

Так как в телеге не очень удобно вставлять картинки в повествование, то часть статей буду писать в Дзен :) Там неплохой редактор

https://zen.yandex.ru/media/id/6235ce8fe9c353590fd97c06/kajetsia-mne-nachinaet-nravitsia-vizualnoe-programmirovanie-627a29adfabf455791ab4994

Графы

Раз сегодня вспоминали графовые редакторы, то стоит написать и в общем про графы. На этом канале хотя и немного сложновато, но объясняется база теории https://youtu.be/LFKZLXVO-Dg

Зачем нужны графы?

Вообще для почти всего. Все программисты и программы по сути занимаются тем, что приводят один формат данных к другому формату данных. Массивы байт в картинку на экране, аналоговые сигналы от кнопок в команды на отрисовку и так далее. Основная работа программиста — жонглирование данными, знание о том какие формы данные умеют принимать, и как Х превратить в Y. На мой взгляд, это самое простое и самое общее описание работы программиста. Дальше уже идут оптимизации и прочее :)

В математике есть две великолепные огромные теории связанные с этим. Теория множеств и теория графов. Фундаментальные теории знать для работы не обязательно, но очень полезно. Так как вы знаете ответы на вопросы исходя из них. Но в чём преимущество графов?

Это ещё одна форма данных, которая позволяет вам делать больше крутых штук. Occlusion Culling базируется на принципах BSP и графах, меш по своей сути — это граф, игровой AI будь то Behavior Tree или FSM так же можно представить в виде графа, навигационный меш и многое другое. Даже связи в коде и весь код можно представить в виде графа. И очень полезно в своём арсенале иметь такой мощный инструмент и понимать его законы. Поэтому очень рекомендую изучить эту тему)

Это я ещё не говорю, какую откровенную магию можно делать из идей топологии пространств и характеристического числа плоскости, и в каких случаях применять в той же деформации и укладке графов :) Но про это надо придумать, что полезного рассказать, чтобы вы не уснули читая XD

Комплексные числа

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

Многие считают, что комплексные числа и их понимание нужны только для каких-то супер-сложных задач. Уравнения Навье-Стокса для симуляции жидкостей, для описания колебаний, деформаций и т.п. Но работая с Unity вы пользуетесь комплексными числами каждый день, даже не понимая их (ну или я надеюсь, что пользуетесь) — это кватернионы. Базовое применение без каких-то зубодробительных формул с рядами и тензорами — это просто повороты.

Углы Эйлера это конечно классно, но у них есть проблемы вроде того, что между ними сложно сделать линейную интерполяцию, сложно их применять на вектора и т.п. А кватернионы отлично для этого подходят. И про них уже так много написано, что даже не хочется повторяться. Например тут. Они в разы удобнее роторов, матриц и углов Эйлера — это по сути главное, что нужно про них знать)

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

Книжка Unity про 2Д

Unity опубликовали у себя в блоге книжку по работе с 2д проектами. Прикольно простое руководство для начинающих https://blog.unity.com/games/our-biggest-e-book-yet-2d-game-art-animation-and-lighting-for-artists И иллюстрации неплохие :)

Cluster-based rendering

Интересные примеры технологий очень похожих на Nanite в UE5. Они как-то прошли мимо меня, но любопытно, как они работают. Конечно они упрощённые, так как там решены не все задачи, которые могут решать наниты, но всё равно прикольно выглядят Unity: https://www.youtube.com/watch?v=28T1UOgiGWw Кастомное решение https://www.youtube.com/watch?v=7JEHPvSGaX8

В целом любопытно, что про кластер бейс рендеринг написано достаточно мало работ, так как поискав по ресерч гейту я нашёл прикольную работу по шейдингу https://www.researchgate.net/publication/289301155_Clustered_deferred_and_forward_shading
и ещё пару работ по теме :) Надо покопаться в теме, думаю много интересного можно накопать :)

Matcap и Unity

Написал статейку по маткапам и Unity. Достаточно прикольная техника позволяющая добиваться красивого и супер быстрого визуала в ряде случаев имитируя многие эффекты. На видео те же эффекты на драконе даже похожи на подповерхностное рассеивание)

Забавная обзорная книжка от Unity по всяким инструментам для технических художников. Ничего особо интересного я правда в ней не нашёл, но как некоторая карта "что есть в Unity" может быть полезна) https://resources.unity.com/games/tech-artists-key-toolsets

База математики для игр
Видео

Freya Holmer — очень крутая. Она сделала много крутых ассетов (Shader Forge и Shapes) и в целом многие её проекты, которые можно найти на её сайте, показывают красоту математики в компьютерной графике и играх. Шейдер фордж конечно уже не так актуален, и Фрея перестала его поддерживать. Но тем не менее у неё много прикольных видео, работ и сайд проектов)

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

Часть первая
Часть вторая

Компьютерная графика про математические трюки

На самом деле большая часть работы с шейдерами, VFX, светом и т.п. Это всё математические трюки. Часто смотря на какое-то явление при разработке шейдера или чего-то подобного мы стараемся найти упрощённую математику для него. Когда-то давно я писал серию статей по математике в геймдеве, где через примеры пытался показать применения этой самой математики. Вот для скажем статья с функцией плоской волны. Когда понимаешь концепцию того, что значит "считается в каждой вершине" и "в каждом пикселе" параллельно, то проще понимать как передаются туда аргументы, и как их можно использовать в функциях. Допустим в статье по волне можно представить, что в центре меша у нас есть точка (пивот) и аргументом для функции волны является длинна вектора от пивота до конкретной вершины меша (фаза в уравнении) + время действия эффекта

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

Скажем вчера в чатике CG мы обсуждали сферические гармоники. И если посмотреть лекции по этой теме в физтехе, то лучше не надо. Если для вас оператор Лапласа, свёртка функций и т.п. магия, смотреть это нет смысла. И там приводится решение с доказательством абстрактных понятий и абстрактных задач. Но совершенно непонятно "А зачем мне это знать?" Хотя скажем вот эта статья это уже объясняет (если пропустить эльфийский для не эльфов, и почитать описания на английском и картинки) По сути привести примеры из астрономии, компьютерной графики и прочему не так долго. Даже не во время лекции, а хотя бы ссылками на "почитать". Скажем перед лекцией, чтобы на лекции было понятно "зачем это"

Просто я не разделяю позиции многих преподавателей, что "это всё неважно, теория объясняет весь спектр применений". Так как зачем самостоятельно повышать входную планку? Я только через 2 года после начала коммерческой разработки смог нормально читать и понимать Рихтера, через 3-4 года чистую архитектуру как просто "понятную брошуру". Так как у меня уже были насмотренность и опыт на практике. И сейчас тоже самое с вузовскими знаниями. У меня была мат. база из-за моей вышки, но по сути я сейчас часто изучаю всё заново, просто в разы быстрее, так как понимаю, как воспринимать эту информацию. В целом математику самостоятельно изучить можно даже стартуя со школьных знаний, сейчас много открытых источников. Но это конечно будет тяжелее, чем в вузе, потому что информация особо не структурирована в плане порядка изучения)

Клёвый мануал по 2д

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

Вообще я чёт ничего не пишу про 2д, всё про 3д. Надо будет про что-нибудь в 2д написать, даже про тот же VFX. После следующей статьи подумаю про что можно написать в 2д играх :)

Классная рекомендация по организации 2д анимаций https://youtu.be/nBkiSJ5z-hE Переключать стейты «руками» в разы лучше, чем организовывать граф состояний, когда вам не нужен блендинг и blend tree

Крутой репозиторий с блюром

https://github.com/PavelDoGreat/Super-Blur — старый репозиторий, но всё ещё прекрасный. Неплохо работает на мобильных устройствах. По сути на одной из его старых версий я когда-то делал свой акрил https://www.youtube.com/watch?v=7CtoEqyu3fI Может кому пригодится :) У автора ещё крутой репозиторий с жидкостной симуляцией на вебгл)

Прикольный туториал по электрическому шейдеру на шейдер графе :) https://youtu.be/u9lOaPVtSqg

Поучаствовал в небольшом подкасте по метавселенным (в первой части) https://metauniverse.mave.digital/

Кривые Безье

Чтож, тут тоже мало смысла повторяться, так как есть шикарный ролик. Советую посмотреть. Кривые в целом супер полезная штука очень много для чего, так как благодаря ним помимо того, что описывает Фрея, делается ещё достаточно много разных эффектов в VFX, в процедурной генерации графики и т.п. Кривые Безье по сути частный, удобный и быстрый вид сплайнов. А сплайны уже в свою очередь — это маст хев знание, так как они очень сильно упрощают жизнь в анимациях, в построении уровней и т.п.