Полезные ссылки про 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

Unity + React

Я открыл для себя очень прикольный подход для веб проектов. Связка Unity + React. Это очень удобно и решает проблему отрисовки шрифтов в WebGL.

Собственно пока я не доделал (так сказать как всегда WIP для канальчика) https://noxatra.ru/demos/webgl-runner-game/

Но уже можно посмотреть в репозиториях:

https://github.com/Nox7atra/unity-react-container-example — пример интеграции в виде веб проекта
https://github.com/Nox7atra/simple-web-runner-game — проект простенькой игры раннера

Надо ещё сделать:

1. Пример "отлетающего текста"
2. Управление для мобилок (оно запускается с мобилки, но там не пофикшен скролл и нет управления)
3. Загрузчик и прочие мелочи
4. Сделать какой-то базовый дизайн интерфейса :)
5. И самое важное статью полноценную + документацию

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

Плюс в репозитории можно посмотреть настроенный проект с такой простенькой 3д игрой весом в 5.5 мегабайт :)

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

Детективная игра с телеграм ботом

Интересно. Может кто-то уже такое делал. Подумал что достаточно забавно к какой-нить детективной игре прикрутить бота с мессенджере. Типа подсказки и какие-то улики тебе передаются в сообщениях там. С одной стороны «зачем игрока выводить из игры, это же можно сделать прям в игре». А с другой прикольно. Лежит рядом с тобой телефон и кто-то пишет тебе прям на него)

Понятное дело стоит делать такие механики опциональными, но интересно насколько это влияет на восприятие) Типа «прошёл квестовый триггер» и тебе вместо попапа в игре приходит сюжетное голосовое сообщение в боте :) Думаю можно сделать атмосферно :)

Хотя со всем этим надо экспериментировать, а то получится как Tom Clancy: EndWar :) Я возлагал такие большие надежды в детстве на голосовое управление в стратегии, а в реальности это оказалось не так прикольно. Хотя может потому что оно работало так себе :)

Unity WebGL + React


Итак, как я вчера и обещал. Репозитории доделаны, статья дописана. Превью конечно слабоватое получилось, но за два дня ударной работы по статье у меня иссякли силы и фантазия. Ну и на дизайн игры сил тоже не хватило. Но всё что я хотел я в примере доработал и в статье постарался расписать не сильно углубляясь в контекст конкретных фреймворков

https://habr.com/ru/post/693534/

Продолжаем работу над тулкитом

Всё-таки я решил, что будем делать сразу верно для реалтайма. Чтобы не было каких-то урезанных оптимизированных версий. Это тонкие настройки, которые вообще не нужны среднему разработчику. Поэтому в вершине конуса куча вершин на самом деле. Зато свет теперь ложится корректно. Плюс свет не единственная причина. Без Дополнительных вершин нельзя грамотно положить uv. На видео корректные uv, а на скрине некорректные

Плюс я отделил генератор от мешрендерера, и сделал отдельный скрипт для проброса результата генерации в рендер, чтобы была возможность юзать GPU Instancing в VFX. Мало ли какой-то процедурный объект надо будет размножить :)

Возможность убрать нормали или UV, чтобы они не шли на гпу в качестве вертексных параметров — поддержу везде. Думаю это будет удобно

Как-то странно тг выложило картинку поэтому перевыложу

Хах, я теперь старожил хабра :)

Тестируйте апдейты (особенно оптимизационные)

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

1. Ничего не меняем перед релизом

Даже если очень хочется, даже если это очень оптимизирует или что-то ещё делает. Правило перед релизом всегда простое. Правятся только криты. Всё остальное не трогаем

2. Обновив настройки, версию, юнити — прогнать тест

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

3. Работа маленькими изменениями

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

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

Argo Lite

Пока ковырял алгоритмы укладки графов и искал разные материалы для статьи по 3д укладкам нашёл прикольный опенсорсный инструмент для визуализации графов в браузере https://github.com/poloclub/argo-graph-lite Выглядит достаточно прикольно, хотя немного и сложноват. Я не нашёл какие-то разные схемы укладки и отображение, но как простенькая тулза с несколькими прикольными фишками выглядит интересно :)

Мануал для тех артистов от Unity

Сама книжка тут https://resources.unity.com/games/unity-for-technical-artists-key-toolsets-and-workflows. А сказать хочется вот о чём) Круто что юнити начали делать мануалы с обзором функций для разных задач. Допустим из мануала по 2д я был не в курсе о ряде функций которые подвезли. Давно с 2д не работал. Хотя меня удивляет, что это называют иногда прям книгами. Это не книги — это мануалы :)

Dark Asset

Прикольный пост о применении Unity в кинематографе. Так сказать рассказ от VFX артиста :) Такие штуки с "виртуальным продакшеном" и трекингом камеры для съёмки + совмещением с изображением с хромакея я разок делал. Технологически это сейчас довольно просто. В целом забавно как игровой движок который я ещё помню воот таким с 4-ой версии стал применяться в самых разных задачах :) Хотя понятны преимущества реалтайма для продакшенов. Когда в реальном времени можно прикинуть, как будет выглядеть кадр без недели рендера или не подгонять кадр под то, что "было снято"

https://blog.unity.com/entertainment/dark-asset-vfx-previs-to-final-pixel

Классный туториал с VFX дракона https://dtf.ru/u/35827-evgeniy-seregin/1405100-povyshaem-socialnyy-reyting-delaem-nefritovyy-drakon-unity-vfx

Как подготовится к собеседованию :)

Просто великолепный видос и канал. А если говорить серьёзно я не собеседовался уже 6 лет, так что даже не знаю что там спрашивают. За это время только собеседовал разработчиков :) Помню только собеседование в мейле когда-то давно, меня зачем-то на рендер программиста спрашивали свойства хеш функции. Прошло 8 лет, а я до сих пор не знаю зачем ответ на этот вопрос может пригодится рендер разрабу :)

https://www.youtube.com/watch?v=5bId3N7QZec