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

Прикольный туториал по ретро эффекту. Не уверен конечно в подходе к пикселизации картинки, хотя можно все артефакты на стиль, и основной плюс этого метода, что рендерить такого размера кадр сможет любой калькулятор https://www.youtube.com/watch?v=3Ccu3UtiSdw Я когда-то игрался с подобными трюками, но для другого. С рендером в отдельное RT. Для блума. Но это же классический скринспейс эффект скажете вы) И будете правы, даже в постпроцессинге есть, а так же куча его вариаций на просторах интернета. Базируется он всегда на блюре. Только вот он достаточно прожорлив на производительность. А задача была завести сай-фай сцену на телефоне за 7к рублей :) Ну а какой сайфай без блума? Самый быстрый придуманный трюк прост в своей гениальности. Все светящиеся объекты рендерились отдельной камерой с разрешением в 3 раза ниже оригинальной) Получался достаточный эффект для разрешения телефона за 7к рублей, и всё летало :) Собственно так же в RT с альфа каналом рендерился кадр со светящимися объектами, а сортировка не ломалась, так как в шейдерах информация о Z не отбрасывалась :)

Rider Flow https://www.jetbrains.com/riderflow/ Просто шикарный плагин для Unity от JetBrains, как и многое от джетбрейнс :) В этом обзоре можно посмотреть на его фичи :) https://youtu.be/iUIjiKtILUc Я же могу сказать, что я пробовал много IDE, и это всегда холиварная тема для программистов :) Кто-то любит вижак, кто-то вижуал студию код, кто-то до сих пор не смог выйти из Vim :) Я же уже 4 года как пересел на райдер с вижуал студии и он просто прекрасен. Но дело даже не в райдере, прекрасен не он, прекрасен решарпер. Основной причиной перехода 4 года назад стало то, что решарпер в вижуал студии дико тормозил, а в райдере просто летал :) Поэтому новая штука от брейнсов — это всегда круто :)

Ахахах) Видимо перед постами надо всё же пить чашку кофе XD Так красиво написал. А ссылку забыл :) Вот конечно же сниппет :) https://pastebin.com/FiU3KcUV Ставьте 👍 если подобные сниппеты полезны :) Чтобы понимать нужно ли делать такую рубрику :)

Кстати о Random Есть много способов что-то рандомизировать и выдавать случайные значения. Но веса задавать массивом не всегда удобно. В юнити есть абсолютно замечательная вещь много для чего, и мы к ней будем ещё возвращаться — AnimationCurve. В данном случае подобным образом можно хранить веса в виде кривой. Где прямая линия — это равномерная вероятность, но поиграв с кривыми можно получить распределения по интереснее (см. скрины). И так как кривую можно это очень гибко настраиваемая штука По сути мы берём интеграл от части кривой и получаем площадь под ней, что и считаем весом в наших вероятностях :) Что бывает нагляднее и проще, чем вбивать кучу весов, особенно если значений очень много и нужно "примерно так" :)

DALL·E 2 (https://openai.com/dall-e-2/#demos) Больше конечно похоже на первоапрельскую шутку, чем на что-то реальное, но появилось оно вроде не первого апреля) Какая-то просто безумная нейросеть (судя по картинкам) :) Я скептик :) Так как за последние 7 лет я видел столько красивых роликов про технологии, что пока её нельзя потыкать, я ей не верю :) Но если оно действительно работает, как показано на сайте — it’s revolution Jonny :) Не скажу, что это «убьёт мир иллюстрации», как многие говорят. Так как всё же стиль соблюдать — нужен будет специальный человек по работе с этой нейросетью :) Но низкобюджетный сегмент для небольших клиентов — сильно подкосит :) В общем подождёмс пока можно будет протестировать :)

А пока можно посмотреть красивые картинки :)

Хоть и старенький, но классный туториал по эффекту из Dragon Ball https://youtu.be/TR1xM1HMNQ8 Он отлично демонстрирует, что VFX это такая кросс экспертиза, где нужно немного уметь в несколько дисциплин вроде 3д моделирования, написания шейдеров и т.п. :)

Триггерный ИИ Игровой ИИ — это очень глубокая тема, в ней можно прям закопаться. Конечные автоматы, Behavior Tree и многое другое. Комбинированные методы. Но я хочу рассказать об упрощённой задаче, так сказать для затравочки, которую мы решали в этом проекте https://foxsys.pro/beringia-game Это стенд на выставку, так что тут нет требования, чтобы ИИ был прям умным) В целом есть базовое правило, когда вы выставляете игру на выставке, каком-то шоукейсе или другом мероприятии в идеале у неё должно быть два состояния: в неё кто-то играет или она играет сама в себя. Причём решений второго масса, самый простой из которых, когда игры никто не касается больше 1-2 минут, она переносится на старт и запускает ролик с записью геймплея. У нас же игра позволяла простенький мультиплеер на стенде, поэтому идея была просто. Нужен ИИ который: 1. Будет играть сам с собой и игроками 2. У него можно перехватить управление. На случай если кто-то решил зайти в игру, когда другие игроки играют. Чтобы не ждать пока "ИИ" доиграет 3. Будет играть каждый раз не одинаково. Плюс с ИИ всегда есть проблема баланса, чтобы в простой игре он не всегда выигрывал и у него был рассчитан диапазон набираемых очков В подобном раннере — это было сделано довольно просто. Карта у нас заготовленная, хотя на бесконечной делалось это бы точно так же. По трассе просто расставляются триггеры с весами. Где вес определяет с какой вероятностью ИИ пойдёт в сторону и в какую. Если вдруг у кого-то нет, вот сниппет самого простого алгоритма расчёта взвешенной вероятности https://pastebin.com/aMCZup9V Добавив условие, что триггеры игнорируются, если пользователь нажал кнопку управления в течении последних 15 секунд, мы получаем перехват управления. Как игроком, так и ИИ при 15 секундном бездействии заберёт на себя управление, если кому-то скажем нужно срочно отойти и с кем-то поговорить Причём важно понимать, что триггеры в данном случае — это всего лишь удобный инструмент для левел дизайна. В сущности ровно тоже самое можно было бы параметрически представить в виде сценария, где запуск сценариев зависит от пройденного игроком расстояния, и в момент перехода границы делается взвешенный выбор. То есть скажем таким образом не на триггерах, а сделав сценарий в виде графа решений, можно сделать ИИ для любой пошаговой игры скажем. Но как я и говорил, сам по себе ИИ это очень глубокая тема, так что потом разберём и другие примеры :)

Fluent Design Надо немного поговорить на тему UX в AR. У майкрософта есть старая классная концепция дизайна — Fluent Design. https://www.youtube.com/watch?v=vcBGj4R7Fo0 И одна её идея отлично подходит под дополненную реальность. В ней очень круто смотрится акрил :) (В прошлом году я даже написал статью с разбором, как его получить https://habr.com/ru/post/565662/ и репозиторием https://github.com/Nox7atra/UMOM ) Но что такого классного в акриле в AR? Ну на самом деле несколько пунктов. 1. Как и любой "фотореализм" он не имеет стиля — то есть универсален Плюс фотореалистичной графики относительно стилизации в целом в том, что нельзя сказать "о, этот реализм — это марвел, а этот dc". Их можно разделить по настроению, по посту, по цветовой палитре и т.п. Но по сути визуально реализм есть реализм 2. Он подстраивается под любой фон В AR фоном у нас является видео-поток с камеры, поэтому сложно подобрать цвета, которые будут хорошо смотреться на любом фоне. Красное на красном будет сливаться и т.п. Поэтому интерфейс с фактурой отлично отделён от фона 3. Он не отвлекает от самого AR Центральным объектом в AR вряд ли является интерфейс, поэтому конечно кнопки отделены от фона благодаря фактуре, но в какой-то момент их проще перестать замечать, так как так или иначе они цвета фона. Есть трюки, как на акриле балансировать контрастность, если это вдруг зачем-то надо. Но обычно, как раньше говорилось: "Лучший интерфейс, это отсутствие интерфейса". Так что акрил это компромисс, так как при правильном использовании ты как минимум перестаёшь замечать наличие худа, как такового. И кажется что места на экране больше для самого центрального объекта В целом в Fluent Design концепции было много интересных идей, жаль она конечно не развита с точки зрения гайдлайнов так, как тот же Material Design :)

Как мерить фпс? В целом для любой более-менее серьёзной разработки нужны дебаг инструменты, которые открываются в рантайме. В мелких проектах я просто делаю скрытую панель, которую крайне маловероятно что найдёт пользователь (например 15 кликов быстрых на определённый текст в интерфейсе). В крупных проектах они вообще не идут в сборку, так как там есть dev, stage, prod билды, настроенные для них окружения и т.п. Собственно ряд инструментов ездит почти в каждый проект) Один из таких это https://github.com/Tayx94/graphy Абсолютно гениальная вещь для мониторинга перфоманса) Ребята сделали очень крутой плагин) Он показывает фреймрейт, память, громкость звука. А так же всю информацию о тестируемом устройстве — просто ляпота :)

Пиксельарт Многие любят фотореализм и графен, а мне как-то всегда больше нравилась стилизация. Ori, Hades, Crypt of the NecroDancer :) И бывают так же клёвые представители пиксель арта, тот же Narita Boy (очень стильная игра) С пиксель артом есть одна проблема, хотя она и мелкая. Чтобы не было визуальных проблем нужно весьма специфично двигать камеру (собственно кратно пикселям) Удобно размер камеры делать таким и всю сетку координат, чтобы работать вообще с int значениями, а не с float. Тогда в целом ничего не будет мерцать :) Ну и вот недавно вышел прикольный туториал на одном канале по VFX в стилистике пиксель арта :) https://youtu.be/JZDlCuIpq9I

Какой красивый шейдер на параллакс маппинге 🤩 https://mobile.twitter.com/tomdns_/status/1044637213533892608

Epic Games анонсировали Reality Scan https://www.capturingreality.com/introducing-realityscan Места в бете уже закончились и будем посмотреть, как оно будет работать. Больше инструментов всегда круто!) И если будет работать качественно — шикарно :) Но тут стоит сказать, что они не единственные и не первые. Хотя я не видел, чтобы кто-то бесплатно давал своё облако для расчёта фотограмметрии. А что ещё существует? Ну например https://www.trnio.com/ тоже досатточно прикольное комплексное решение по сканированию пространства) Есть Agisoft Metashape (https://www.agisoft.com/) — правда для мобильного телефона, там нужно написать свой клиент. Но ничего не мешает на сервере поднять свою ноду для фотограметрии. И совсем для разработчиков https://github.com/alicevision/meshroom которое прям заточено под разворачивание серверов Это было если мы говорим про качественный скан. Если брать простенький скан, то на IOS много сканеров умеющих собирать модель чуть ли не в реалтайме на устройстве :) Но качество там конечно так себе Единственное, чем это действительно может быть супер круто — это интеграцией с выкладкой в маркетплейс. Поставил аппу на телефон, отсканировал какую-нить красивую 3дшку, прошёл базовую премодерацию, поставил цену-описание, и вот у тебя ассет в маркетплейсе. Хотел бы я подобную тулзу для ассет стора, думаю тогда там можно было бы найти много интересных сканов) Когда я лазал по горам в Дагестане, я уже думал, что было бы прикольно иметь тулзу, которая куда-нить в облако шлёт подобные симлес текстуры (см. картинку ниже). И может стоит заморочиться и сделать такой опенсорс инструмент) Путешествуешь, гуляешь, чёт красивое сфоткал/отсканил, кто-то потом использует в своей игре или ролике — кайф же :)

Player Prefs В целом префсы великий механизм для кроссплатформенной разработки. Когда ваши сейвы и т.п. не весят несколько мегабайт, то это всё что вам надо. Даже при синхронизации сейвов с сервером — это отличная штука для оффлайн доступа :) Я довольно часто сейвы и конфигурации храню в виде json строки в префсах. Основной плюс этого кроссплатформенность. Да почти на всех платформах всё решается Application.persistentDataPath, но скажем не на том же webgl) И кстати для неё есть достаточно прикольный репозиторий с инструментами, чтобы в редакторе было немного удобнее всё это дело тестить https://github.com/sabresaurus/PlayerPrefsEditor

Паттерн декоратор Думаю это самый популярный шаблон проектирования. Многие языки целиком пронизаны им. JS в особенности, где по сути "всё декоратор". Определение и пример формальные почитать можно тут https://metanit.com/sharp/patterns/4.1.php, хотя я не согласен с определением Component. Так как по тексту статьи Component должен быть интерфейсом, а не абстрактным классом. Но мы же говорим про Unity. В юнити декоратором по сути является любой MonoBehavior, так как он расширяет функции объекта, и в любой момент эти функции можно снять или отключить :) Но это даже не самое главное. Тоже самое условно можно сделать через наследование) Декоратор как раз таки прикол в том, что по своей структуре позволяет избежать сложной иерархии наследования) Например вы хотите, чтобы у вас в игре был меч. И чтобы он бил "огнём", "ядом" и "льдом". Как это можно сделать? Ну самый упоротый путь сделать класс Sword, и от него отнаследовать ToxicSword, FireSword и FrostSword. Это позволяет сохранить разное поведение, но усложняет реализацию комбинированного урона Можно сделать "маску урона". По сути завести enum DamageType и хранить в мече либо битмаской, либо словарём (если значения урона разные). Поведение будет определять класс меч, а урон резолвить переданный в него словарь. Это лучше, но тоже не так удобно А можно сделать компоненты, которые определяют тип урона FrostDamageModificator, ToxicDamageModificator и FireDamageModificator. Которые добавляют классу меча функциональность урона. Так же какой-нить AOEAttackTypeModificator и т.п. для того, чтобы определить как меч бьёт. И потом собрав все эти компоненты по конфигу айтема меч получит все нужные ему свойства. А класс Sword будет просто скелетом определяющим, как это всё между собой дружить :) И это один пример. Я допустим очень сильно люблю декорировать всякое в маркерном AR всякие эффекты. Конечно с мечом пример долго реализуем, поэтому в репозитории я привёл более простой пример с декорированием инпута. Его в целом можно сделать и без общего класса скелета, он сделан скорее для наглядности :) https://github.com/Nox7atra/PatternsUnityPlayground Да, хитрая иллюзия того, что в юнити скелет не знает про свой декоратор. Но важно понимать, что в юнити скелетом является трансформ, который через дженерик метод добавляет на себя компоненты наследники MonoBehavior. Так что это нормально, чтобы класс "скелет" знал про декораторы и наоборот. Хотя там зависимости опять таки можно развозить кучей способов. Основное это всегда функциональная суть паттерна) Суть паттерна Декоратор: 1. Расширение функционала без наследования 2. Возможность натянуть на скелет (основное что непонятно новичкам в этом паттерне — это его блок схемы. Даже в примере по ссылке выше — это лишь один из примеров реализации такого скелета) Основные плюсы: 1. Легко включать выключать различные функции и придавать свойства объекту 2. Легко комбинировать между собой свойства, при этом зная другие паттерны делать это так, чтобы декораторы друг о друге ничего не знали (что вернее) Прошлые разборы: 1. Команда — https://t.me/dyadichenkoga/76 P.S. Когда соберу большую часть паттернов, надо будет закрепить наверное на канале в какую-нить общую статью :)

Очень жаль, что Brackeys год назад перестали вести свой канал. Конечно не скажу, что я согласен со всеми их туториалами (портал между локациями я бы делал через стенсил, а не через две камеры, как пример) Но всё равно там много крутого контента. И советую с ним ознакомиться, если вдруг не знали :) Ну и этот туториал диззолва тоже неплох https://www.youtube.com/watch?v=taMp1g1pBeE :)

Работа с функциями в шейдерах Я часто говорю, что программирование — это не математика. И это на самом деле так. Кроме шейдеров. Шейдеры — это математика. Дисторшн и т.п. сейчас художники используют во всю. Но первоначально это математика. У меня есть старая серия статей про математику) И в одной статье из серии я разбираю полностью уравнение плоской волны https://habr.com/ru/post/435828/ И в целом существует много прикольной математики) Из старых мат моделей, что я находил на просторах интернета я помню https://andrewhungblog.wordpress.com/2018/04/29/page-curl-shader-breakdown/ Идея её проста, по сути "накручивание меша на цилиндр" :) Но чем интересна статья про волны, она отлично иллюстрирует, зачем часто бывает полезна удобная визуализация. И если в самой статье я рекомендовал вольфрам, то позже я нашёл инструмент в разы удобнее) https://www.desmos.com/calculator?lang=ru Да, конечно диффур там не посчитаешь и т.п. Но для того, чтобы подобрать правильный параметр для синуса или какую-то кусочную функцию — подходит отлично. И в разы проще разобраться, чем в том же вольфраме :)

Шейдер граф Я очень любил писать шейдеры кодом. На мой взгляд это было быстрее) Ну и с реймаршингом и т.п., это правда так (ставь 🔥 если стоит написать про реймаршинг — не байт ни разу) Но сейчас я прихожу к тому, что графами в разы проще делать сложные эффекты. Когда тебе не приходится в 100 раз искать по куче проектов тот же дисторшн. Или же просто нужно "покрутить" и "по переставлять". Добавить френеля, убрать френеля, пошумить и т.п. Но возможно я так сильно не любил это всё дело, так как просто не знал про этот мануал и эту часть пакета шейдер графа https://docs.unity3d.com/Packages/com.unity.shadergraph@6.7/manual/Custom-Function-Node.html Создавая свои кастомные ноды можно делать много прикольных авторских шейдеров. При этом воспринимать это всё дело часто в разы проще, чем векторный код + интересные шейдеры можно выложить скриншотом. Хотя конечно вот тут — код копипастить удобнее :)

Одна из моих любимых фич за последние годы в Unity — это VFX Graph) С ней можно делать откровенную магию. Конечно, как и любой VFX она требует некоторой насмотренности. К VFX можно подходить по разному. Для придумывания каких-то новых эффектов нужно экспериментировать и иметь некоторое художественное понимание. С другой стороны для повтора чего-то существующего достаточно просто пытаться технически разбирать "из чего состоит тот или иной эффект или явление". Но для начала я в любом случае советую изучить инструментарий и пройти как можно больше туториалов) Это всегда отличный источник идей и "набивки руки" :) Вчера я наткнулся на неплохой туториал по созданию портала через VFX граф :) https://www.youtube.com/watch?v=V2NZb0WN7SY