Поговорим про метавселенные

Почему я не верю в метавселенные, как в концепт? По тому, как его формулируют :) Многие кто работают с метавселенными с точки зрения бизнеса не знают «истории». Я люблю как примеры тот же децентраленд (тупо пузырь с аудиторией в 10к пользователей) Но есть пример в разы лучше) Роблокс :) И что с ним не так?

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

Если мы возьмём тот же майнкрафт, то средний возраст аудитории там 24 года, хотя есть миф, что это школьники :) И это неплохо, но это значит, что это не самая платящая аудитория. Но засчёт чего эта аудитория формируется? По сути за счет контента, который аудитория создала. То есть отличие от того же WoW и т.п. Не в свободе действий, не в каких-то технологиях)

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

Но бизнес почему-то упорно пытается продать успешность этих платформ за заслугу VR :) Единственный проект который можно так рассматривать — это VRChat, но там и аудитория соответствующая, ниже чем во многих паблик каналах дискорда :)

Интересное упражнение

Я люблю заниматься всякой фигнёй для разминки. Так как делаю кучу всякой фигни (разве что удивительно, что не выпустил пока ни одной именно своей игры за 8 лет работы на Unity) я люблю иногда разминаться старыми стартаперскими замашками. И для проектов часто нужно оценивать целевую аудиторию :) Но чаще всего люди оценивают от «позитива» типа кто пользователь моего проекта, игры или продутка. Иногда забавнее пойти от обратного «кто точно не будет пользоваться моим продуктом». Скажем любители ААА и графена точно не будут играть в небольшую инди визуальную новеллу :) И так сегментировать и вычёркивать циферки. Точную цифру остатка так получить нельзя безусловно, но просто полезно бывает понимать свои проблемы и слабые стороны. Часть их них даже бывает решаема :)

Дженерики очень опасная штука

Эххх, помню я несколько лет назад, когда в коде у меня ещё были всякие мысли типа "ух как я придумал" и когда было желание писать "красивые конструкции". Сколько я весьма странных вещей строил на дженериках. Я не люблю и почти не используют дженерики. Нет, конечно мы все используем дженерики в сетевых методах, во всём что связано с десериализацией, с коллекциями (типа объектного пула). Но дженерики чаще зло.

Но почему? Ведь удобно реализацию определять ниже по иерархии вызовов нежели делать это в самом классе, если есть такая возможность. И у меня тогда встречный вопрос. А чем это отличается от: Object, абстрактного класса и интерфейса? (как можно понять варианта три из-за параметров аля where) За исключением того, что их вы можете конкретизировать и определить на любом шаге и в любом уровне иерархии? Выигрыш в производительности на дженериках без кастов обжекта к конкретному типу конечно будет, но тем не менее

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

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

Enemies меня расстроили конечно

Но в целом Adam тоже лагал, так что я не удивлён особо. Но речи о реалтайме тут нет. https://unity.com/demos/enemies

7 фпс на самом низком разрешении и самых низких настройках. На средних и выше в этой сцене краш.

Что интересного было в Keynote Unite 2022?
https://www.youtube.com/watch?v=wdmiPPjcBSA

Кейноут мне чем-то напомнил по структуре презентации эпла. В целом не скажу, что та было что-то прям интересное. Надо смотреть конкретные доклады. Но ролики в перебивках с играми и проектами красивые.

XRI Toolkit — если сделать удобным круто, но я до сих пор не особо в восторге от новой Input System.
UI Toolkit для редактора — ну ничего нового, некие общие слова на тему того "как будет удобно"
URP — что-то интересное с реатлайм светом и декалями, но надо будет посмотреть "на бою"
HDRP — прикольная штука для неба и энвайромента, волюметрические облака. Сцена с водой красивая. Надо посмотреть сессию по свету, когда она выйдет на ютубе
DX12 — будет не экспериментальным
DevOps — ну не знаю даже кто использует связку Plastic SCM + Unity Cloud Build. А не гит/префорс + team city/jenkins. И уж тем более зачем использовать Unity Remote Config. Но и по сути ничего интересного не сказали, что теперь будет панель для управления всем CI&CD в дешборде Unity
Netcode и сетка — тоже ничего нового, кроме примера Photon Fusion с батл роялем, который интересно будет поковырять
DOTS — не пользовался, не могу ничё сказать. Суть "Дотс классный, вот стек инструментов для него"
Realistic Charactres — ничё особо нового. Оба пакета и так были доступны. И для волос, и для кожи.
ZIVA Face Trainer — очень интересная тулза для реалтайм лицевых анимаций.
Демка Enemies в виде Exe билда — на моей 3060RTX и i7 с разрешением 2560х1440 на лоу настройках 6 фпс, на медиум и выше — просто краш. Ссылка тут. Ралтаймового чуда не произошло. https://unity.com/demos/enemies

И снова Sakura Rabbit

Шикарный эффект появления мира. И опять ведь сделано простыми средствами, но со вкусом :) https://80.lv/articles/real-time-space-distortion-in-unity/

Вообще надо будет тоже подумать чего подобного можно сделать. Выглядит вдохновляюще :)

А что не так с графикой в VR проектах?
https://blog.unity.com/manufacturing/metaverse-minute-the-versatility-of-vr-featuring-cas-and-chary

Конечно покрытые топики "метавселенная" и "цифровой двойник" — это скорее кликбейт, чем правда. Но тем не менее забавная подборка концептов VR механик. Сами продукты мне непонятны, и по рендеру я не устану удивляться тотальным проблемам с графикой. Я то наш проект трёхлетней давности считаю не шибко красивым, так как сделан он был за 3 недели с интеграциями трекинга рук и т.п. И тогда я и умел в разы меньше, но он по графике в разы симпатичнее среднего VR проекта в подборке. И это не квест, а Oculus Go, которые по производительности можно даже не сравнивать :)

Но смотришь сейчас на средний VR проект и имидж юнити "графика в юнити говно" начинает играть новыми красками. Какие-то банальные вещи, глупые косяки, странные решения. Иногда кажется что в некоторых проектах достаточно было бы купить приличных ассетов и уже было бы хотя бы симпатично. Вспоминаются проекты которые даже на юнайте выступали, которые прям круто сделаны. Хотя я помню, что с точки зрения дроуколлов там были те же ошибки, что я когда-то допускал не понимая, как разумнее строить сцену, чтобы утилизировать максимум из гпу :) Например засунуть всю статичную геометрию в один меш (а не юзать статик батчинг или динамик батчинг) Это рисуется конечно в один dc, и там если хитрости как это рисовать одним материалом. Но как легко догадаться оно рисует даже то, что у нас за спиной и мы не видим :) Но в общем советы полезные. Ещё был прикольный доклад про LUT Color Grading через шейдер :)

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

uGUI Debug Console

Ещё один из крутых авторов среди делающих Open Source на Unity — yasirkula. У него тоже много прикольных гитхаб проектов, один из которых удобная консолька https://github.com/yasirkula/UnityIngameDebugConsole Все кто работают с айос должны ненавидеть смотреть логи в Xcode. И поэтому бывает удобно просто смотреть логи прямо внутри проекта.

В целом у любого проекта часто есть всякие внутренние dev инструменты. Они скрыты несколькими нажатиями на какой-то элемент интерфейса и паролем, чтобы тестеры, да и разработчики могли удобно посмотреть fps и другие вещи. И собственно если лень писать свою консольку с логами, можно взять сделанную yarsirkula :)

Проблемы работы с текстурами и графикой в Unity

Сижу я и ковыряю, как мне вытащить Depth текстуру из ARKit, чтобы не страдать фигнёй на устройстве. Решил заливать её на сервер (возможно нормализовав красиво пиксели) и потом забирать, и обрабатывать уже в юнити. Скажем я хочу её размывать, а потом обрабатывать размытие, чтобы получить границу вытравления размытую, но чётче. Это делать проще всего через animation curve. А делать свой интерфейс для animation curve — геморно)

Хорошо. Вроде текстура от апи есть, есть метод у текстуры encodeToPng. Делаем. Не работает. И тут мы сталкиваемся с главным приколом Unity связанным с графикой. Вообще нет гарантии работы ряда методов)

Идём в логи. Смотрим, текстура рисуется через шейдер, у текстуры есть разрешение (у аркита depth 256x192), пытаемся получить пиксель и получаем '' texture has no data. Конечно так как текстура рисуется, я понимаю воркэраунд, который позволит решить нужную мне задачу. Но как же такое бесит. Так как по сути я делаю дев тул то не страшно, что прийдётся скриншотить по сути через RT текстуру и потом уже её конвертить и заливать. А нормализовать значения depth шейдером. Но кажется, что когда ожидаешь работу апи какого-то оно должно работать или выдавать хотя бы понятные ошибки. Но в целом в юнити и сложными штуками связанными с AR или графикой я уже к этому так привык, что даже не удивляюсь :)

Продолжаем ковырять аркит

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

P.S. Глубина у аркита просто отвратительного качества. Но мне кажется, что я что-то считываю не так, надо перепроверить. Потому что в арките глубина + human segmentation везде имеет будто бы одинаковые значения. А это уж очень странно

Как же я б*** люблю гадание на галочках

Итак, пошёл который день проекта на ARKit сложнее Plane Tracking или же Image Tracking, и что я могу сказать. Есть много вещей которые я люблю в программировании, и немного которые я откровенно ненавижу. И в данном случае это гадание на галочках. В любой новой фигне всё задокументировано так себе. Я так и не нашёл, как насильно менять конфигурацию ARKit на нужную мне. В Unity есть ConfigurationChooser в ARSubsystems который лучше меня знает, что я хочу. Но начнём историю с самого начала.

Как я уже говорил в прошлых постах в арките не работает одновременно AR Occlusion и Human Body Tracking. Сначала я грешил на Unity, но нет — это сделано так на уровне аркита (да, я настолько низко пал, что прочитал документацию на свифте). Перед началом проекта (как опытный аутсорсер), я проверил базовые сценарии поведения. Конкретно что включая и выключая AR Occlusion оживает система Human Body Tracking. Збс. Едем дальше, всё работает, остальное в контексте проекта можно обыграть. Кайф же

И вот разработка фичей, отправки скриншотов, полной логики сообщений, весь бизнес флоу собран. И трекинг начал отваливаться. Почему? Непонятно. Всё же работало. Ничё нового не делалось. Были попытки в ручную включать сабсистемы, покрутить то, что мы включаем-выключаем. Всё бестолку. Как только Occlusion один раз включится — трекинг не работает.

Окей, мы опытные и не сдаёмся. Обкладываемся логами по горло, чистим архитектуру, чтобы модули были независимы, откатываем на старые версии скриптов (без обработки что скелет может быть один, так как может там продолбалось чего) — не работает. Я разве что до примера обратно откатиться не успел, но даже в этом случае я бы не догадался так быстро, как в итоге додумался.

Внимательно читаем все логи аркита. И вот что мы видим. На старте приложения у нас включается ARBodyTrackingConfiguration. Трекинг работает. После включения Occlusion конфигурация автоматом переключается на AROrientationTrackingConfiguration с frameSemantics="Segmentation with Depth" и так далее. А при выключении Occlusion та же конфигурация AROrientationTrackingConfiguration только почему-то остаётся поле Depth Smooth что-то там.

Так Smooth, где-то я это б**ть видел. Где же была такая галочка. И тут я вспоминаю, что в Occlusion Manager есть галочка Temporal Smoothing. Как обычно в эти моменты ты думаешь: "Да ну н.... Да не может так быть". Выключаю эту галочку. И чудо, всё работает. И ладно бы это было первое сдк, которое так себя ведёт. Но я каждый раз вспоминаю проблемы обобщённых SDK. Из-за отсутствия прямого контроля желаемого и таких вот тонкостей в выборе конфигурации какой-то автоматической системы часто тратится уйма времени на "угадай какие галочки я хочу, чтобы получить то, что ты хочешь". Тоже самое бывает с рендер апи и много с чем, где "а ты угадай, что в таком-то контексте будет тут". При том, что на нативе логика пишется ясно и в одну-две строчки. В общем я просто сгорел

Жаль телега не индексируется. Но если вдруг кто-то задастся вопросом "почему у меня после включение AR Occlusion Manager не работает Human Body Tracking что ты не делай?" То вероятно дело в галочке Temporal Smoothing, мало ли кому-то сэкономит времени. Всем доброй ночи!

Одна из любимых картинок на все времена

Кто-нибудь знает как собираются приложения под IOS в обход trusted devices?

Гугл говорит, что это невозможно. Документация эпла говорит что так нельзя. Самое похожее на такой механизм — это AdHoc (хотя с автоматической подписью вообще непонятно какой провижен оно использует) Но вот что интересно. Я встречал и без jailbrake приложения которым телефон "не доверяет". Скажем приложения покер румов. Там просто дают ссылку, которую если расковырять, она очень похожа на AdHoc, но вместо IPA, там идёт ссылка на зип архив под названием инсталлер. И крайне интересно, как это сделано и работает? Это какой-то воркэраунд или механизм от эпла? Непонятно

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