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

Красивый эффект «появления» мира

Обожаю технически простые штуки, но сделанные со вкусом :) По сути трипланарный dissolve с подсветкой edge на маске, но выглядит очень эффектно https://80.lv/articles/real-time-space-transformation-in-unity/

Что почитать по рендеру?

Таки я собрался с силами и написал статью с полезным, на мой взгляд, списком литературы чтобы разобраться или прокачаться в реалтаймовой компьютерной графике. Одну книжку я недавно увидел как раз в чате https://news.1rj.ru/str/unity_cg и она мне понравилась, если рассматривать её "для начинающих". В общем мало ли кто-то искал что почитать. Надо будет собрать такое же по ИИ и прочим разделам тяжкого труда Unity разработчика :)

P.S. Ну и превьюшка теперь мне нравится, не просто картиночка, а "со смыслом" :)

Unity всё ещё работают над интеграцией .Net CoreCLR JIT runtime

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

Поговорим немного про рантаймы Unity. По сути сейчас их два. IL2CPP и Mono. С первым ничего не случится. Посмотрим какие платформы будут поддерживать Core CLR, но точно на него переедут десктопные платформы. А в чём разница?

1. Моно мёртв

Конечно Unity поддерживает свою версию моно по сути, так что это не совсем тот моно. Но CoreCLR — это будущее .Net которое активно развивает Microsoft. Он кросплатформенный, он в х2-х10 раз быстрее чем Mono и оперативно получает все последние фичи .Net. Он лучше, чем .Net Framework по множеству причин и т.п.

2. А что с IL2CPP?

Так как его трудно поддерживать под несколько платформ он может быть недостаточно оптимизирован и в данном случае так же проигрывать CoreCLR в производительности.

3. Span

Это есть в статье, но Span<T> супер полезная штука. Это возможность безопасно работать с неуправляемой памятью (в отличии от того же unsafe) что бывает достаточно полезно и открывает возможности для множества безопасных оптимизаций

Так же улучшенный GC и много чего ещё. В общем работа над интеграцией CoreCLR судя по всему идёт и это круто)

Репликация в сетевых играх

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

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

У автора ещё классная серия статей про то, как он делал MMO

Вообще множество технологий и топологий сети были придуманы во времена до broadband и оптимизируют траффик максимально. Ведь когда-то нельзя было гнать несколько мбит в секунду. И используются до сих пор, так как зачем трафик грузить зря. Хотя требования к сетевому коду со временем сильно снизились

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

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

Ну в общем детали завтра в статье, а пока "из первых рук" для подписчиков репозиторий с примером и ссылка на результат (работают только на мобилках) :) Так что если вам нравится эстетика праздника, но тыквы нет, то я вам подогнал AR тыкву :)

Дополненная реальность в Tilda
https://habr.com/ru/post/696300/

Статья конечно вообще никак не связана с Unity, зато связана с моей областью интересов — дополненной реальностью. Конечно помучаться с тильдой мне пришлось, и делается там это по сути "костылём", так как свой сервер всё равно пригодится бы. Но делается :) У меня несколько проектов и лендосов на тильде. Что сайт компании https://foxsys.pro/ (пока, скоро будет его большой апдейт), что сайт календаря http://gamedev-calendar.ru/ Ну и всем весёлого хеллоуина, кто тоже любит эстетику этого праздника :)

Децентрализация как высшее благо

Я не фанат криптовалют, DAO, Web3.0 и прочего. Я всё никак не могу понять зачем делать неэффективно то, что работает эффективно централизовано. На VC была отличная статья на тему того же NFT. Но меня скорее удивляет тотальная маркетинговая мантра децентрализации. Помню тот же старый аргумент, что международные переводы банками идут 3 дня, а крипта несколько минут. И всё это ногами идёт из непонимания технологий. Банковские переводы так долго идут из-за законодательств и трансграничных переходов, а не так как это так долго считается. Крипта просто пока не соблюдает законы :)

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

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

Ну как говорится посмотрим, что из этого выйдет :)

Перфекционизм — это зло

Многие в работе падают жертвой перфекционизма. Своего или чужого. Чтобы много успевать и делать — рецепт довольно прост. Не мучать результат до посинения)

Иногда мучать результат полезно, да и когда время или бюджеты есть, то почему бы и нет. Мне по работе приходится периодически набрасывать какие-то картиночки. Да, что тут далеко за примером ходить. (Картинки будут ниже) Сейчас я конечно визуалы получше набрасываю, но первый логотип календаря я сделал за 10 минут. И с ним я набрал 300 подписчиков в этот канал.

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

К чему это я? Да, концепты, которые неделю делали дизайнеры. Вроде такого раннера, концепта игры квеста или такого концепта виртуального тура — визуально круче. Они много раз были полезны команде без портфолио (из-за NDA) чтобы объяснить, что "что-то мы таки умеем". Но как показала практика нескольких лет, и то что собрано на коленке за час отлично работало. Зато такое я мог собирать под каждого клиента и быстро. А не отправлять в ожидание на неделю)

И такое встречается во всём. Правда в том, что всем плевать насколько вы старались. Особенно на старте. Это просто проще объяснять на визуалах, но не стоит забывать такие вещи и разработчикам. Заказчику или бизнесу плевать насколько оптимально работает функция, если это до этого удовлетворяло пользователя. Пользователю плевать насколько красивая у вас архитектура. Если тех лид парится, что у него сессия вылетает по памяти через 3 часа, а средний пользователь играет в игру 2 минуты — бизнесу плевать. Если арт лид парится, что у персонажа какая-то не такая поза, а 85% пользователей этого даже не заметит — бизнесу плевать. Пока 15% пользователей — это не миллионы. Перфекционизм полезен уже в успешных продуктах и там он нужен, особенно на стадии оперирования. На запуске же вы без таких заморочек будете двигаться в разы быстрее.

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