Шейдертой

Один из неплохих способов разобраться в шейдерах, ковырять чужие шейдеры. И для этого есть неплохой ресурс — https://www.shadertoy.com

Он не единственный, но и там огромная коллекция интересных шейдеров. Написаны они правда на glsl, а шейдерлаб Unity используют hlsl. И часто написаны не очень хорошо, но эффекты там всё равно красивые и можно вдохновится интересными эффектами и посмотреть разные подходы)

Кроме того есть классный проект переводящий шейдертой шейдера в шейдеры для Unity https://github.com/smkplus/ShaderMan Он позволяет на основе шейдера из шейдертоя сгенерить шейдер для Unity, что бывает полезно. В общем советую попробовать поделать на основе шейдеров с шейдертоя поделать свои эффекты, пооптимизировать описанные там. Да и в целом иметь на вооружении при работе всю библиотеку шейдертоя бывает очень полезно :)

Хороший старый доклад с Unite по оптимизации в графике https://www.youtube.com/watch?v=JUiO64KbAHA

Оптимизации — дело тонкое

На Unite в целом много крутых докладов, которые стоит посмотреть. Вот ещё один из них https://www.youtube.com/watch?v=oatF8e_PPh0 Оптимизации дело тонкое, потому что если хочется добиться графики мирового класса, то нужно оптимизировать всё в контексте проекта. Никакие общие решения и техники не дадут аналогичных результатов в визуале никогда. У вас изометрия, глупо использовать 3д. У вас 3д, но с фиксированными пролётами камеры — есть тоже ряд техник. У вас используется блюр, его можно красиво переиспользовать. У вас стилизация с фиксированным числом цветов, тогда по весу можно запихать в одну текстуру множество математикой. Техник и идей масса, и это ещё не беря что-то сложное, поэтому очень полезно смотреть доклады и учиться на чужом опыте. Причём даже не столько тому, а как у них сделано, а как нужно думать и какой логике рассуждений следовать оптимизируя тот или инной модуль)

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

Прикольные репозитории

Юнити такой движок, что помимо самого движка есть огромное число прикольных штук сделанных комьюнити. Одна из таких система воксельного света https://github.com/sonicether/SEGI Она конечно старенькая, но всё равно рекомендую поковырять она на билд ин рендере достаточно забавна :)

Прикольный список крутых VFX артистов :) https://80.lv/articles/real-time-vfx-artists-you-should-follow/?amp=1

Курсы и обучение новичков

Я тут недавно наткнулся на забавный ролик, где человек ругает курсы и всяких ребят на ютубе за говнокод, когда составляется туториал для новичка. Ну перед сном почему бы и не глянуть, что за пример хорошего обучающего кода там будет. Увидев его код я в целом закрыл ролик моментально. Пример плохого кода, конечно если такие прям есть в скиллбоксе — это печаль. Но я не думаю, что ребята оттуда делают Find в Update. Это единственное за что сильно зацепился взгляд)

Хороший код, а точнее так, действительно хороший код, требует понимания огромного числа концепций и опыта. Плохой пример был действительно плохой, но его можно довести до нормального. А вот хороший код не будет понятен ни одному новичку и учит плохому. И вот почему)

1. Я считаю использование фреймворков в обучении, кроме базовых (типа юнити, или какого-нить плейканваса) — в целом плохим тоном. Понимание самой концепции фреймворков — высокоуровневое знание. Если за тебя всё решают ассеты, плагины и т.п. в реальной работе ты будешь в аду. Так как в сущности ты умеешь не программировать, а собирать конструктор лего. Если делается хорошее решение, это надо ещё и кастомизировать. Допустим я часто ругаюсь на использование Lean Touch в проектах. Он прекрасен, но когда нужен какой-то кастом, то переписать его гемор. А использование целого плагина, когда в билде даже Pinch не используется — ну это сильно. Тащим ассет вместо 5 строк кода. Собственно в "хорошем примере" всё базируется на фреймворке, поэтому я почти сразу закрыл видео

2. Наследование и принципы ООП — это не простые концепции. Второе что зацепило взгляд в "хорошем" примере для новичков — это наследование. Это не базовое знание, не все новички программисты в целом, а тут у нас сразу один и столпов ООП, которым то не все мидлы умеют правильно пользоваться. Сначала обучаясь нужно просто получить прикольные результаты минимальным числом знаний концепций. Так как сначала человека надо увлечь и показать, что ничё страшного тут нет, и вот ты тут написал 5 строк текста, а у тебя весёлая интерактивная фигня на экране появилась)

3. События. События — это тоже высокоуровневый концепт, который нужно долго пояснять человеку, который пока не до конца понимает концепции массивов, циклов, переменных, классов и т.п.

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

Прикольный репозиторий с системой для паркура https://github.com/knela96/Dynamic-Parkour-System

Интересный дайджест с настройкой погоды в игре https://80.lv/articles/creating-volumetric-clouds-modular-weather-and-cloud-shadows-in-unity/

Поговорим про работу с контентом

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

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

И есть 2 пути подготовки качественного контента:

Первый — у вас хорошие специалисты и вы им доверяете

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

Второй — у вас есть грамотный продюсер или артдиректор

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

Да, речь идёт конечно же про коммерцию. Коммерческое производство — это понятный бизнес процесс, с понятными точками, отсечками, схемой менеджмента, целями и т.п. И хороший пример этого игровые студии, которые стабильно производят несколько сотен шапок или скинов. Всё получается делать на уровне постоянного "творческого процесса". И творчество там есть. Просто контроллируемое

Сделал генератор шаблона Unity пакета


https://github.com/Nox7atra/UPTG — так как я периодически выкладываю в опенсорс всякие инструменты и библиотеки свои, и так впадлу каждый раз создавать руками кучу файлов. Так как Unity в мануалах предлагает делать это руками. Написал компактный генератор всего что нужно. Забиваем данные, выбираем туглы и т.п. Надо будет на досуге добавить защиту от дурака с версиями, просто сейчас лень писать регулярку формата x.x.x а без них пакет не будет качаться + надо сделать версию обязательным полем и в целом протестировать, какие поля в пакетах обязательные

Как говорится может кому пригодится — пользуйтесь. Чтобы не делать это всё в ручную

Астрологи объявили неделю полезных ассетов

Чёт напало на меня желание поделать на выходных какие-нибудь полезные штуки. В вот вам ещё репозиторий :) Вас когда-нибудь бесило, что вы в какой-то анимации не можете поменять иерархию или переименовать объект в Unity? Вот меня очень часто. Особенно когда скажем в UI сделаешь какую-то сложную анимацию, композицию анимаций делать не хочется, но иерархию менять — это прям боль, там 5 объектов, заранее не подумал что они могут хотеть двигаться вместе. Из недавних прям таких кейсов, у меня была инфографика, а потом мне потребовалось плавно к ней вести линию соединения. И увидев, что мне нужно либо переносить ключи в 5-ти местах, либо делать ещё одну анимацию с уже внешним контейнером, я решил написать небольшую тулзу

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

Работает как-то так)

Красивая штука) https://www.youtube.com/watch?v=-t0fH4CH0V4

Классный эффект :) https://80.lv/articles/bloodborne-s-moonlight-sword-made-with-maya-unity/

Отличная статья про GPU Instancing https://catlikecoding.com/unity/tutorials/rendering/part-19/Rendering-19.pdf

Последнюю неделю я решил ещё сильнее углубится в рендер. В основном я изучал тесселяцию. И я понял, что пора переходить на URP :)

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

Графы конечно всё ещё ограничены и многое не умеют, но тем не менее сейчас можно сказать, что пора :) Да и думаю на перспективу всякое сделанное под URP многим будет полезнее. Конечно в билтине огромная библиотека готовых решений, и я буду скучать. Но зато в URP есть SRP батчер и много приольных фишек :)

https://dtf.ru/gameindustry/1270216-unity-otmenila-gigaya-demo-igru-s-realnymi-primerami-po-razrabotke-na-svoem-dvizhke

Очень жаль

Что-то полистал я новости последние. И Unity видимо решили повторить успех близов по уровню скандалов. Про "разработчики которые не думают на старте о монетизации — идиоты", это прям что-то уровня "у вас что нет телефонов?"

Я не буду конечно говорить, что пора идти на другой движок и т.п. Так как вменяемая альтернатива одна — Unreal Engine. Но потратив на Unity уже 8 лет, я не знаю что юнитеки должны сделать, чтобы заставить меня переучиться на другой инструмент. Так как пиар и инфополе одно, а инструментарий удобный для работы — другое. Но конечно печально это всё

А, ну и ссылка на новость: https://www.pocketgamer.biz/interview/79190/unity-ironsource-john-riccitiello-marc-whitten-merger/

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

Юнити прекрасен не самим движком, своим рендером, фичами, архитектурой, лайфтайм лупом. UI лучше в нативном дройде например, у веба юнити курит в сторонке (боже какую магию можно творить на CSS). По рендеру тоже, всё что встроенное в юнити переписывается нормальными разрабами в первую очередь. Я уже не помню когда последний раз использовал стандарт шейдер. Да даже физика рейкастов у меня своя для VR проектов, так как PhysX слишком медленный в этом контексте для пары моих задач

Основная ценность Unity — это его комьюнити. И юнитеки делают вообще всё, чтобы поссорится со своим комьюнити последнее время. Я вряд ли сменю Unity не потому, что мне трудно выучить плюсы (я их как бы знаю, хотя и не на про уровне. Но CLI плюсы в целом несложные. Всё что дальше 17 стандарта я не в курсе конечно что там творится. Я остановился на бусте и смарт поинтерах) и в анриале объективно есть часть прикольных фич. Но в юнити я эти фичи заменяю тем же самым сделанным комьюнити + пользуюсь своими наработками + несколькими сотнями готовых репозиториев

Для того же света есть SEGI и Aura. Есть куча крутых репозиториев от keijiro. Есть множество репозиториев с разными технологиями на просторах гитхаба. И это не считая ещё огромного подмножества того, что сделано просто на шарпе. Типа того же моего порта https://github.com/Nox7atra/Triangle.Net-for-Unity Я по сути сделал пару утилитарных методов и перевёл точность на float, но это изначально старый шарповый https://github.com/wo80/Triangle.NET который стоит на плечах плюсовой библиотеки

В общем удивительное рядом. Я и раньше удивлялся работе с комьюнити от Unity, но сейчас такое ощущение, что они совсем себя решили опустить на дно в глазах комьюнити. Сначала закрытие Unity Answers, потом слияние с IronSource, потом закрытие Gigaya, а теперь вот это. Что же будет дальше?

Эхх, жаль этого исполнения нет на стриминг сервисах с музыкой :) Ностальгически скучаешь иногда даже по такому року :) https://youtu.be/n037fE7tol4