Что интересного было в 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, менять провижен, добавлять доверенные устройства по идее тоже вариант. Но просто любопытно, что это за механизм "недоверенных корпоративных приложений")

Собираем новый пакет

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

Animation Curve в текстуру

Как всегда для своих ссылочку пораньше чем я напишу на эту тему статью и причешу. Собственно преобразование Animation Curve в текстуру с пробросом в материал. Можно ещё в рендереры потом сделать и т.п.

В репозитории можно посмотреть, как сделать кастомный инспектор для всяких шейдер проперти в скрипте и т.п. Но главное "а зачем это надо?". На самом деле не всегда удобно математикой задавать кривые. Иногда удобно это делать руками. На примере того же поста повыше про подбор альфы в depth маск для вытравки человека. Думаю напишу статейку в котором покажу ряд применений такого подхода. А так сгенерировать текстуру скажем 256х1 ничего не стоит, но при создании какого либо эффекта или передаче в шейдер данных может сэкономить просто уйму времени :)

Да в особенности это про режим Repeat и Mirror. Так как задать сложную периодическую кривую и регулировать её в шейдере, это задача не для слабых духом. А делать тоже самое через курв и тайлинг uv легко и интуитивно понятно

Нейросети и контент

Я уверен, что нейросети не заменят художников, но станут шикарным инструментом для художников. Концепты, баннеры и т.п. набрасывать и докручивать будет просто кайф :) И вот какую красоту тут сделал один художник :) https://dtf.ru/gamedev/1439137-hudozhnik-sozdal-interaktivnyy-koncept-art-pri-pomoshchi-neyroseti-midjourney-i-unity

А вы знали, что в Unity есть Device Simulator?

Конечно никакого отношения к "настоящему симулятору устройства" он не имеет, но я вообще как-то пропустил эту фичу. Но оказывается в юнити теперь есть что-то на подобие функции в Google Chrome, только удобнее засчёт нарисованных бровок и т.п. https://docs.unity3d.com/Packages/com.unity.device-simulator@2.2/manual/index.html

Подсветка сейф зоны, информация о гпу и цпу, эмуляция событий Low Memory, эмуляция событий тача. И это просто режим геймвью. Симуляция классов Screen, Application, SystemInfo)

В общем забавно, я как-то упустил когда эта фича вообще появилась и заехала в редактор :)

Давайте обсудим, что такое плохой код?

С утра комментарием к старому посту меня снова заинтересовали этой темой. Все часто говорят про плохой код, а что это на самом деле? Вы уверены, что однозначно это знаете и понимаете?

Мы не идём от того, что такое хороший код. Что там код должен быть компактным (класс в 1000 строк это как минимум вызывает вопросы). Что код должен быть модульным и т.п. А так же не берём вкусовщину, вроде мантры солида :) И соответственно если ты нарушаешь Single Responsibility то это очень плохой код. Почему? Потому что если у класса нет стейта, это функциональный объект, который занимает 200 строк, но логика поведения его функциональна, то к каким проблемам ведёт нарушение пресловутого S?

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

Можно придумать наверное ещё короткий список простых и понятных критериев не привязанных к какой-то архитектурной парадигме. Но как? Почему? Ведь солид это важно? Да потому что парадигмы, солид и прочее — это уже как религии, а не как инструменты. Нарушил в одной точке где вот вообще насрать, как это будет реализовано, чтобы не тратить время на размышления. Скажем модуль общения с нативом, который занимается сошиал шейрингом, доступом к галерее и т.п. Где скажем зачем-то тупо функциональный объект с интерфейсом для доступа ко всему и ифдефами. Можно сколько угодно в курилке сраться "какой же это говнокод". Но почему он плохой? Он не ведёт к багам, его не придётся менять если он оттестирован (интерфейс со стороны юнити для доступа к шейрингу или галерею я за 8 лет не переписывал ни разу) он не требует поддержки и оперирования. Это пример блекбокса, где вот вообще плевать. Если сформулировать ряд тезисов.

Если в классе описаны 2 и более стейтов или кроссстейтов — это очень плохо.
Если реализация кода не позволяет написать клиент в консоли — это плохо. (самая простая проверка отделения отображения от поведения)
Если любая ссылка пробрасывается через иерархию вызовов в методах больше 3 раз — это в среднем плохо. В таком случае надо выносить ссылку в статический контейнер

Кто хочет может в комментарии докидать свои, потому что я описал явно не всё.

Чем мы занимались последние годы?
https://www.youtube.com/watch?v=yjWZHJTndGk

Наконец-то мы доделали небольшой рил с нашими работами, которые не за 10 печатями тайны. Тут конечно далеко не все проекты и не всё, что мы сделали за 4 года работы. Но тем не менее теперь будет проще кидать кому-либо видео и объяснять "чем мы занимаемся". И когда смотришь на такие вещи прям ностальгия по тому, как делался каждый проект :)

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