Эххх, ностальгия, сегодня что-то вспомнились времена митапов, когда я делал Unity Moscow Meetup)

Уже несколько лет прошло с тех времён) Это было прикольно, в пике там собирались человек под 200, в какой-то момент к нам пришли MSI и помогли с едой на мероприятии, заказав на всех пиццу. К сожалению это отнимало много времени, и пришлось выбирать чем заниматься, своей студией или митапами) Они правда к тому моменту уже были переименованы в CGDevs, но это ещё и забавная история)

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

Прикольный туториал по VFX, который отлично подойдёт для сейф поинтов или бонусов в игре :)

https://www.youtube.com/watch?v=oaDetLRJ0qQ

Как я понимаю программирование?

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

Зачем нужен продюсер?

Внезапно не кодерская тема, но тем не менее про это стоит написать :) Сейчас я всё же программист в меньшей степени)

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

Некоторые объединяют понятия менеджера проекта и продюсера. Это вопрос терминологии, поэтому неважно. Я же эти понятия разделяю. Проджект менеджер — это тот, кто руководит процессом производства. А продюсер — это тот, кто делает чтобы это производство состоялось вообще и потом добивается результата. ПМы так сказать один из инструментов в руках, так как задача добиться результата в бюджет и срок)

Что я чаще всего встречал, что только продюсеры умеют хорошо и качественно решать кризисные ситуации, вне рамок обычного процесса :) Скажем чаше всего кризисы в команде возникают из-за непонимания, поэтому решаются они на самом дела просто. Общением со всеми причастными, при этом без затягивания этого дела. Так как в данном случае, если ничего не делать, то всё начинает рушится :) Но бывает много совершенно разных примеров на самом деле :)

Не изобретайте свои форматы

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

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

Векторные форматы — это сложно, поэтому там столько всего? Да нет, пример другого простого векторного формата — это меш и obj. Это LDraw про который я писал статью https://habr.com/ru/post/433364/ Да в целом многие 3д форматы проще чем SVG. Формат хранения 2д векторных картинок ставший стандартом хранения векторных изображений) Мы храним легковесные иконки, ну нам нужен фреймворк! :)

Ладно. Вернёмся к изначальной теме. Почему свои форматы это плохо? И что важнее когда это плохо?

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

1. Много готового

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

2. Хорошие стандарты вытачивались годами и они обобщены специально

Я понимаю, что у новичков есть мнение "ща я придумаю лучше и всех порву". Сам такой был по крайней мере. И придумать лучше в контексте конкретной задачи несложно. Просто это будет никому не нужно. Стандарты делаются не супер оптимальными, но зато общими, устойчивыми, оттестированными огромным комьюнити. И предоставляются с огромным набором инструментов в довесок. Вот реализовал я тот же парсер LDraw для Unity. Есть такой же для блендера и т.п. Ща с новыми знаниями может по оптимизирую даже его, и добавлю фич (хотя бы цвета в vertexColor шейдер писать для примера). Но помимо этого с другой стороны есть огромное креативное комьюнити, которое делает чертежи таких моделек из которых можно генерить 3д. Разукрашенное, с цветами, хоть персы марвел. И всё потому, что креативным людям дали стандарт

Но конечно же бывают крайности. Просто они бывают реже чем принято считать. Когда я в вузе занимался математическим моделированием, то там 5-10% оптимизации на своём кастомном формате могло превращаться в дни расчётов, и такое тоже есть. Но в геймдеве это супер редкость, когда вам вместо того же bson нужен свой бинарный формат. Вместо rudp свой кастомный протокол передачи данных по сети. Вместо png — свой формат картинок

И тут есть ещё одна оговорка. Интерпретация стандартов. Вы можете кастомизировать стандарт не отходя от него (как программисты) Допустим у вас паллитра в игре, что вам не нужны все 32 бита ргба, вам достаточно всего лишь 2 бит, чтобы записать все цвета игры (то есть у вас 64 цвета). Тогда в одну 32 бит ргба текстуру мы можете записывать 16 картинок. И потом кастомным парсером доставать их на рендер уже в нормальном виде. При этом у вас будут всё так же работать алгоритмы сжатия и прочие инструменты, так как это всё ещё png картинка с точки зрения системы. Лучше фантазировать и экспериментировать с таким, чем придумывать свой новый супер формат)

Компьют шейдеры

Compute Shader — это очень мощный инструмент. Они позволяют делать cущюю магию. В основном с симуляциями и отображением миллионов объектов

Сейчас конечно чаще, если задачу решает VFX граф, то используют VFX граф, который основан на компьют шейдерах (поэтому он работает не на всех платформах) Но в целом, тут как всегда. Зная низкий уровень, можно делать в разы больше. Хотя и медленнее писать :) В целом вот прикольное видео с рассказом общим про комьют шейдеры https://www.youtube.com/watch?v=BrZ4pWwkpto

Допустим одна из типовых задач решаемая компьют шейдерами — это отрисовка форматов типа ply (облако точек) Реализация пасс трейсинга. Которое разбирается в этой статье http://three-eyed-games.com/2018/05/03/gpu-ray-tracing-in-unity-part-1/ и многое другое :) Причём, так как отрисовка миллионов точек на хорошей гпу стоит не дорого, то получается делать очень красивые динамические эффекты с огромным числом точек :) В общем очень полезная штука)

Очень интересно смотрящийся шейдер https://www.youtube.com/watch?v=kr_tdKCT2Xs

Unity Render Streaming

Что-то на неделе я задался идеей сделать свой AR стриминг. Идея его довольно проста в своей сути:

1) Отправляем с устройства позицию камеры в сцене (+ записываем в память кадр видео с таймштампом, и позицию отправляем с ним же)
2) Рендерим Unity сцену исходя из полученной позиции камеры
3) Возвращаем фрейм из Unity с альфа каналом + таймштамп
4) Склеиваем 2 кадра (из юнити и видео)
5) Отправляем результат в очередь на вывод

Дальше регулируя задержку вывода в зависимости от сети и широты канала можно получить неплохой эффект. Но так как, я люблю стандарты, то писать свой протокол стриминга мне не особо хочется. Поэтому я решил поискать "а что есть готового?" И наткнулся на очень интересный пакет. Из коробки конечно он не совсем нужный функционал покрывает, но делает скажем так 80% работы. Это https://docs.unity3d.com/Packages/com.unity.renderstreaming@3.1/manual/

Сделано там всё на основе WebRTC, у него есть ряд довольно странных багов (скину скрины ниже) Но в целом для прототипа идеи попрёт. И главное вывод можно делать хоть в браузер. Хоть куда хочется

Почему важно, что он основан на WebRTC? Протоколов стриминга на самом деле много, но более менее стандартными являются RSTP, HLS, LL HLS, RTMP, RTMP Tuned, DASH, SRT и так далее. И все они в отличии от WebRTC имеют в среднем задержку более секунды. А мы же хотим "почти реалтайм")

У WebRTC же с другой стороны так же есть проблема. Он поддерживает 24 битные цвета без альфа канала. Но в целом, если мы на цветовую информацию отдадим по 6 бит на цвет, то альфу как-нить запихнём. Стандартные плееры будут конечно выводить чушь, но вот кастомный — скушает и не подавится. Что можно сделать шейдером, даже не меняя сам энкодинг-декодинг. Просто интерпретировать по-другому информацию о цвете на гпу при выводе

В общем если дойду до чего-то вменяемого, залью реализацию этого дела на гитхаб) А пакет в целом рекомендую поковырять, он любопытный :) Для моей же идеи мне кажется нужно ковырять https://docs.unity3d.com/Packages/com.unity.webrtc@2.4

А ещё в продолжение утренней темы есть крутая статья обозревающая большинство стриминг протоколов :)

https://www.wowza.com/blog/streaming-protocols

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

https://youtu.be/9n4P4ZjoiLs

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

https://youtu.be/dUjNoIxQXAA

И собственно вот полный ролик от кучи 3д артистов :) https://youtu.be/JXrWPLNp9tw

Крутой ролик разбирающий многие артефакты и аспекты подготовки графики, полезный не только в VR проектах. Но самый часто встречающийся косяк в тех же VR проектах, который прям бесит. Specular Aliasing :)

Хотя я бы к ролику относился, как к описанию проблем, так как часть решений данных в видео трудно назвать оптимальными и можно решать элегантнее на уровне шейдеров. Хотя dynamic cubemap soft shadows — очень крутая техника, которую я бы рекомендовал в общем взять на вооружение и для 3д мобильных проектов)

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

https://youtu.be/xqgt9W4Zrjg

Прикольный тутор по VFX следа от удара) Полезно для всяких слешеров и подобных игр :) https://www.youtube.com/watch?v=9Nv28O2OIoQ

Как работает рендер?

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

https://www.haroldserrano.com/blog/how-to-develop-a-rendering-engine-an-overview

Пост с книжкой: https://news.1rj.ru/str/dyadichenkoga/117