Григорий Дядиченко

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

— Уже скоро 30, устройся на работу! — Я и так работаю, мам! Иногда в продакшене бывает трудно объяснить чем ты занимаешься и что это настоящая работа :)

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

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

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

@render_ru канал наших друзей, который должен быть у каждого 2D/3D художника в закладках! А так же у них есть ламповый чат по графике @Render_Chat.

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

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

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

Компьютерная графика про математические трюки На самом деле большая часть работы с шейдерами, VFX, светом и т.п. Это всё математические трюки. Часто смотря на какое-то явление при разработке шейдера или чего-то подобного мы стараемся найти упрощённую математику для него. Когда-то давно я писал серию статей по математике в геймдеве, где через примеры пытался показать применения этой самой математики. Вот для скажем статья с функцией плоской волны. Когда понимаешь концепцию того, что значит "считается в каждой вершине" и "в каждом пикселе" параллельно, то проще понимать как передаются туда аргументы, и как их можно использовать в функциях. Допустим в статье по волне можно представить, что в центре меша у нас есть точка (пивот) и аргументом для функции волны является длинна вектора от пивота до конкретной вершины меша (фаза в уравнении) + время действия эффекта Поэтому для написания прикольных эффектов полезно понимать некоторые концепции из математики. Но тут конечно в математике есть огромная проблема. Так же как и с чтение того же Рихтера. Рихтера в разы проще читать, когда уже что-то понимаешь в разработке и когда понимаешь зачем он тебе нужен. Я люблю периодически смотреть лекции мфти по вышмату. Они лежат в открытом доступе и очень интересные (на них непростительно мало просмотров) Есть по самым разным темам, и без семинаров конечно усваивать материал сложно, но при желании — можно. И проблема всего вышмата, и всех лекций по нему, что я когда-либо видел. Вышмат всегда идёт от теории, а не от примеров. А с примерами было бы учить в разы интереснее. Скажем вчера в чатике CG мы обсуждали сферические гармоники. И если посмотреть лекции по этой теме в физтехе, то лучше не надо. Если для вас оператор Лапласа, свёртка функций и т.п. магия, смотреть это нет смысла. И там приводится решение с доказательством абстрактных понятий и абстрактных задач. Но совершенно непонятно "А зачем мне это знать?" Хотя скажем вот эта статья это уже объясняет (если пропустить эльфийский для не эльфов, и почитать описания на английском и картинки) По сути привести примеры из астрономии, компьютерной графики и прочему не так долго. Даже не во время лекции, а хотя бы ссылками на "почитать". Скажем перед лекцией, чтобы на лекции было понятно "зачем это" Просто я не разделяю позиции многих преподавателей, что "это всё неважно, теория объясняет весь спектр применений". Так как зачем самостоятельно повышать входную планку? Я только через 2 года после начала коммерческой разработки смог нормально читать и понимать Рихтера, через 3-4 года чистую архитектуру как просто "понятную брошуру". Так как у меня уже были насмотренность и опыт на практике. И сейчас тоже самое с вузовскими знаниями. У меня была мат. база из-за моей вышки, но по сути я сейчас часто изучаю всё заново, просто в разы быстрее, так как понимаю, как воспринимать эту информацию. В целом математику самостоятельно изучить можно даже стартуя со школьных знаний, сейчас много открытых источников. Но это конечно будет тяжелее, чем в вузе, потому что информация особо не структурирована в плане порядка изучения довольно часто)

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

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

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

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 и ещё пару работ по теме :) Надо покопаться в теме, думаю много интересного можно накопать :)

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

Комплексные числа А раз уж начали про математику, то можно и про комплексные числа поговорить. Сегодня я нашёл совершенно шикарное видео про них. Там всё научно популярно интересно, так что не "отключайтесь" сразу :) Это видео очень круто объясняет связь между комплексными числами и поворотами) Многие считают, что комплексные числа и их понимание нужны только для каких-то супер-сложных задач. Уравнения Навье-Стокса для симуляции жидкостей, для описания колебаний, деформаций и т.п. Но работая с Unity вы пользуетесь комплексными числами каждый день, даже не понимая их (ну или я надеюсь, что пользуетесь) — это кватернионы. Базовое применение без каких-то зубодробительных формул с рядами и тензорами — это просто повороты. Углы Эйлера это конечно классно, но у них есть проблемы вроде того, что между ними сложно сделать линейную интерполяцию, сложно их применять на вектора и т.п. А кватернионы отлично для этого подходят. И про них уже так много написано, что даже не хочется повторяться. Например тут. Они в разы удобнее роторов, матриц и углов Эйлера — это по сути главное, что нужно про них знать) Поэтому хотя бы в научно популярной форме про них полезно послушать и попробовать вникнуть. А так, кто знает, вдруг как-нибудь захочется реализовать что-то вроде такого. Важно понимать, что с практической точки зрения в математике главное — уметь её читать) Мы не занимаемся разработкой математических теорий и теорем. Мы просто точно так же, как мы переводим бизнес требования в код, переводим язык математики в код. Поэтому если его выучить, вы просто получаете в копилку широкий спектр инструментов, которые многие вещи делают возможными. Конечно уметь доказывать теоремы из головы классный навык, но в среднем супер крутым является умение просто пользоваться той огромной базой знаний, которую сделали математики за последние сотни лет :)

Графы Раз сегодня вспоминали графовые редакторы, то стоит написать и в общем про графы. На этом канале хотя и немного сложновато, но объясняется база теории https://youtu.be/LFKZLXVO-Dg Зачем нужны графы? Вообще для почти всего. Все программисты и программы по сути занимаются тем, что приводят один формат данных к другому формату данных. Массивы байт в картинке на экране, аналоговые сигналы от кнопок в команды на отрисовку и так далее. Основная работа программиста — жонглирование данных, знание о том какие формы данные умеют принимать, и как Х превратить в Y. На мой взгляд, это самое простое и самое общее описание работы программиста. Дальше уже идут оптимизации и прочее :) В математике есть две великолепные огромные теории связанных с этим. Теория множеств и теория графов. Фундаментальные теории знать для работы не обязательно, но очень полезно. Так как вы знаете ответы на вопросы исходя из них. Но в чём преимущество графов? Это ещё одна форма данных, которая позволяет вам делать больше крутых штук. Occlusion Culling базируется на принципах BSP и графах, меш по своей сути — это граф, игровой AI будь то Behavior Tree или FSM так же можно представить в виде графа, навигационный меш и многое другое. Даже связи в коде и весь код можно представить в виде графа. И очень полезно в своём арсенале иметь такой мощный инструмент и понимать его законы. Поэтому очень рекомендую изучить эту тему) Это я ещё не говорю, какую откровенную магию можно делать из идей топологии пространств и характеристического числа плоскости, и в каких случаях применять в той же деформации и укладке графов :) Но про это надо придумать, что полезного рассказать, чтобы вы не уснули читая XD

Так как в телеге не очень удобно вставлять картинки в повествование, то часть статей буду писать в Дзен :) Там неплохой редактор https://zen.yandex.ru/media/id/6235ce8fe9c353590fd97c06/kajetsia-mne-nachinaet-nravitsia-vizualnoe-programmirovanie-627a29adfabf455791ab4994

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

Что не так с IF в шейдерах Самый сложный вопрос на который я когда-либо искал ответ: "Почему в шейдерах плохо использовать IF?" Но тут нужно знать где искать. Иногда полезно перечитывать старые книжки, так как Рендер Хелл я читал последний раз в универе, а эта информация там была во второй книге. Просто когда мало что понимаешь немного по-другому воспринимаешь и запоминаешь информацию) Полный ответ на этот вопрос во второй лекции этой крутой серии лекций :) Но дело в методе под названием лок-степ. Все ядра процессора на гпу выполняют одну и ту же команду с разными данными о пикселях и вертексах. По архитектуре параллельных вычислений это невозможно, чтобы часть ядер выполняло одну команду, а часть другую. И вот как работает в этом случае IF. Сначала выполняются все команды одной части IF-statement, но при этом часть ядер "спит" из-за переданных параметров. Потом "спящие" ядра просыпаются и выполняют ту часть, что была в else, а отработавшие ядра начинают спать) У Unity в мануалах есть так же неплохой набор статей про бранчинг, и как юнити что оптимизирует, что тоже полезно почитать. Так как есть исключения в истории выше, если скажем компайл тайм понятно по какой ветке пойдёт шейдер. Но мне всегда было интересно в чём проблема на низком уровне. А то все знают, что if в шейдере — это плохо, что это бранчинг. Но я нигде не мог найти внятного и подробного объяснения "почему?" :)