Пока закину небольшое превью без особых оптимизаций (хотя сильно оптимизировать я пока и не хочу) Spring Embedded алгоритм укладки графа. Конечно граф который я нашёл — сильно связный. Надо какую-то синтетику сгенерировать. Так как когда связность очень высокая этот алгоритм на 10к ребёр не поедет. Это 1к ребёр :) (граф хранится чисто рёбрами на сайте) Собственно цвет вершины выбирается в зависимости от числа её соседей

Очень крутой репозиторий с PathTracer с помощью Compute Shader https://github.com/Pjbomb2/Realtime-Compute-Shader-Unity-PathTracer

Визуал прям кайф :) Надо будет протестировать насколько быстро работает, но в любом случае любопытно будет на досуге поковырять :)

Интересное видео по face tracking https://youtu.be/V9bzew8A1tc :)

Сходил на круглый стол в Совет Федерации. Обсудили аспекты регулирования метавселенных. Было интересно, собрались очень крутые эксперты :)

Прикольный туториал по простенькому эффекту https://youtu.be/rB4YMQmO8Mw

Выступление на MIXR 2022 #mixrconf

https://www.youtube.com/watch?v=oHzWLasRMys
Наконец-то подъехала запись выступления с MIXR 2022 :) Где я рассказываю про графику в мобильном AR и в чём отличия от мобильного геймдева :)

Ссылка на презентацию

(Сорри за нотификацию лишнюю, думаю одним постом вся инфа будет удобнее) :)

Метавселенные и их проблемы

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

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

Я в целом не верю, что метавселенные полетят, и что они кому-то так уж нужны в первую очередь) Потому что пресловутая иммерсивность это конечно замечательно, но вопрос всегда в комфорте и удобстве. И играть сидя за компьютером или же лёжа на диване с геймпадом в разы удобнее, чем ходить в VR шлеме с контроллерами) В первые разы это прикольно, есть вау эффект, но потом нет разницы) Поэтому я пока до сих пор не верю, что VR/AR так важен в этой теме) Сублимация и жизнь в другом мире отлично проходит с дивана с джойстиком, без сложных технологических устройств и полного погружения) А в VR и устройства неудобные, и контента по уровню погружения хотя бы приближенного к взрослому геймдеву тоже нет. Особенно мультиплеерного) Возможно это конечно вопрос времени, но пока мне в это не верится :)

Blippar SDK + Unity

Любопытно, надо будет потыкать, как будет свободное время. Новость в том, что WebAR сдк от blippar в котором даже есть SLAM выпустили плагин для Unity. Интересно будет поковырять, как работает их SLAM и что с ним можно делать. Оно вроде сильно подешевле 8стены, но вопрос как всегда в качестве. В общем надо посмотреть, а то вдруг WebAR со SLAM меня станет бесить в разы меньше :)

В Unity теперь есть свой мультиплеер

https://www.youtube.com/watch?v=ecyK0vHmbpQ это видео отлично разбирает, что там нового. Плюс что самое крутое — есть примеры)

В целом любопытно, как оно будет работать. Из платформ не поддерживается только WebGL, но тоже одна из новых штук, которые надо будет потыкать :)

Забавные случаи

Сегодня что-то вечер ностальгии и хочется ещё повспоминать какой фигнёй я страдал в студенческие и около студенческие годы :) Помню на втором или третьем курсе, когда я был ещё студентом партнёром Microsoft, я написал такую статью. И чтобы правомерно юзать картинки я написал ряду блогеров чьи профили проанализировал: «можно ли взять их в статью». Собственно ответил мне Виталий Голованов, за что ему огромное спасибо :) Это был прикольный момент раз, как меня начало затягивать в программирование (особенно по фану, а не по работе)

Самым знаковым моментом я всё ещё считаю победу на хакатоне правда :) Ведь как же круто заучит «На хакатоне игромира побеждает зло» :) И мы пусть и сделали прикольный концепт, но по сути полную фигню за ночь, этот момент я запомню навсегда) Плюс я там познакомился с игровой индустрией и кучей крутых ребят из неё. Олегом Чумаковым, Сашей Мезиным :) Но там было всё, как в лучшей истории) По утро мы вообще хотели сдаться и уйти, так как ничего не работало, а в итоге забрали первое место :)

Ну и конечно же. Как я сделал за 3 дня шуточную игру про «блокировку телеграма». Когда было модно быть «цифровым сопротивлением» и попал в обзор к вилсе) Тоже забавный момент прошлых лет и как некая странная ачивка)

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

WebAR — QuickLook (IOS) и SceneView (Android)

Есть довольно старый прикольный способ посмотреть 3д модельки в дополненной реальности. Это USDZ и GLB. Я до сих пор считаю, что при всей прекрасности 8 стены, я не хочу отдавать почку за AR контент. Поэтому люблю изучать всякие альтернативы. Базовый гироскопический трекинг и т.п. И сегодня наткнулся на прикольный исчерпывающий сайт по GLB и Scene Viewer https://modelviewer.dev/

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

Моя теперь новая "большая идея", я хочу сделать медленно и тихо OpenSource SLAM. А то все SLAM технологии, которые были Open Source, вроде выкупили. И теперь SLAM, кроме родных ARKit и ARCore, стоят каких-то ну прям заоблачных денег. Пора начинать снова бороться с корпорациями силами открытых технологий! XD А то платить 1250$ в месяц за 25к просмотров AR — ну очень дорого :) Ведь со временем технологии должны дешеветь и демократизироваться, становиться удобнее для разработчиков, чтобы на них строились более крутые инструменты и продукты. А 8wall уже лет 5 на моей памяти столько стоит) Ну и ребята молодцы, сделали крутую технологию, но как говорится пора делать снова Open Source SLAM)

Из всяких таких историй я никогда не прощу Apple покупку IKinema Orion и моментально убранную после покупки лицензию за 400 фунтов за лучшую кинематику в мире :) Ну да ладно, речь была не о том. Советую полистать сайт — он прям прикольный :) И особенно примеры https://modelviewer.dev/examples/

Полезные ссылки про SLAM

Возвращаясь к теме SLAM. Вот пара сборников алгоритмов и инструментов для компьютерного зрения. Вдруг кому-то пригодится :)
https://github.com/marknabil/SFM-Visual-SLAM
https://github.com/tzutalin/awesome-visual-slam

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

Минусы подхода «делать всё на ассетах»

В современной разработке всё чаще проекты делаются интеграционными. Я уже про это говорил, но не раскрывал почему это плохо и в каких случаях. А об этом думаю стоит поговорить. Сразу скажу, что речь не про «не использовать ассеты», а помнить про опасности при использовании.

Это удивительное везение, когда готовое решение работает «как надо» без допила или хотя бы из него нужна большая часть функций. Инструменты стоит разделить на три вида: фреймворки, большие плагины и мелкие утилиты.

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

Пример хорошего большого плагина — это AVPro. Выделенная функция, которая не делает ничего лишнего. Она не прошивает всю систему, но выполняет большую и важную функцию.

А мелкие утилиты — это обычно сниппеты из интернета, которые выполняют одну совсем небольшую задачу. Типа перемножения матриц :)

Утилиты — можно использовать сколько угодно, у них реализацию легко и править, и поддерживать, так как она микроскопическая)

Большие плагины — имеют проблемы если опираются на какие-то библиотеки типа гугл сервисов (привет фаербейс) Тогда может случиться ад версий. И их в них уже в свою очередь важна поддержка

А вот фреймворки надо юзать с большой осторожностью)

1. Устойчивость системы

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

2. Сложность системы

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

3. Баги в ассетах

Некоторые ассеты имеют баги, которые сложнее поправить, чем сделать разработку с нуля.

4. Проблемы интеграций

Это так же относится к аду dll. Делая всё на ассетах рано или поздно появится проблема разведения зависимостей. Если несколько ассетов опираются на разные версии библиотек — это становится большой проблемой.

Почему оптимизация и качество это долго

В работе мне иногда надоедает объяснять заказчикам, особенно у которых есть своя разработка, почему что-то делается не «5 минут» ведь их ребята могут. В целом оценивать сколько другой человек делает задачу Х не надо никогда, это очень плохой тон и никому не советую так делать. Я сам с этим очень часто борюсь, как лид на проекте или техдир. У каждого своя скорость

Но что такого долгого в качественной работе. Скажем мы умеем заворачивать веб билды в Unity под мобилки, делать так чтобы они грузились несколько секунд и работали супер шустро, а весили в пределах 8 мб. Но благодаря чему? Такая степень оптимизации — это уникальные инструменты и набор экспериментов + кастомный процесс под каждую конкретную задачу.

Скажем есть у вас 3д. Там есть текстуры. Их нужно грамотно пожать, чтобы посмотреть «видно артефакты или нет» и делается это в ручную и зрительно. И это время. Едем дальше, можно оптимизировать меш, значит мы подбираем опять-таки в ручную сжатие каждой модели, чтобы посмотреть где вылезут артефакты. Дальше если мы взрослые, то мы не юзаем стандарт шейдер и пишем свой кастом. При этом иммитируем эффекты экономля вертексные параметры (скажем пишем шейдеры, которые не используют тангенты и нормали). В последний раз я вообще писал утилиту + шейдер, которые брали карты Roughness, AO, Dissolve Mask и Metallic из одной текстуры)

В итоге в ходе часов 12 оптимизации вес веб билда с 25 мб снизился до 7 :) Так как я заменил одной текстурой хитрыми способами 8 текстур всё изрядно пожав. И это при том, что у меня в этом огромный опыт. Я не беру ещё всякие трюки на этапе создания 3д моделей, которые скажем позволяют экономить засчёт тайл материалов, или скажем эмиссии сделанной специально через геометрию, а не текстурой. Которые ещё надо обсудить и сделать :)

В общем, советую не судить работу «по себе». Так как все делают по разному, разными инструментами и обладают разными уровнями скилла. Поэтому это контрпродуктивно, а ещё часто раздражает :)

Какая нормаль в вершине конуса?

Я сейчас решил заморочиться посидеть и спроектировать VFX тулсет. Набор простых утилит, которые позволяют генерить всякие примитивы для VFX (сферы, полусферы, торы, конусы, сплайны), шумы и градиенты. Смешивать текстуры по каналам. Чтобы выкинуть в опенсорс потом тулзу для всех простую и удобную. А то моделить это всё долго, да и не все умеют. Проще параметры покрутить)

И столкнулся с тем, о чём не задумывался. Мало того, что конус это по сути частный случай цилиндра (но это логично как раз) Видимо его надо и делать цилиндром. Но тут прям косёрн оптимизации. Так как как для корректного pbr света нужны корректные нормали, а это значит конус прям цилиндр и в его вершине будет на самом деле ни одна, а множество вершин, чтобы свет правильно ложился на треугольники. Но вот если вам нормали не нужны, то достаточно одной вершины в вершине конуса. Думаю, стоит ли на уровне тулсета закладывать такие оптимизации или это уже оверинжиниринг, так как все возможные случаи всё равно покрыть трудно) В общем так "анонсируем" для подписчиков канала, что скоро появится прикольная штука :)

P.S. Меня просто задолбало моделить полусферу, четверть цилинда и писать отдельный шейдер с параметром куллинга в нужную сторону, если моделлер сделал их не в ту сторону. Да и такие вещи весить ничего не будут в отличии от моделей, если сделать скриптами

Больше чатов богам чатов

Завёл группу по XR разработке на Unity в телеграм. Если интересуетесь XR — присоединяйтесь

Эффект матрицы

Всегда интересно искать на просторах гитхаба что-то прикольное. Нашёл вот интересный трипланарный шейдер с эффектом как в матрице :) Выглядит довольно круто, подобное очень интересно разбирать "а как сделано" :) https://github.com/IRCSS/MatrixVFX