Проблемы работы с текстурами и графикой в 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 Да и на сайте давно уже не все проекты, которыми можно похвастаться :)

И ещё про моё понимание плохого кода

Плохой код — это не тот который сложно расширять в первую очередь. Сложно расширяемый код может быть вполне себе норм. Просто не рассчитанный под такое резкое изменение бизнес требований. Плохой код — это тот который сложно понять и сложно переписывать. Я знаю, что некоторые лиды истерят на тему скажем вызовов Camera.main в апдейте, и считают это плохим кодом. Это тупо ошибка, но которая правится легко, обнаруживается легко. Дал пару раз человеку линейкой (хорошей такой, металлической) по рукам и всё хорошо. А когда человек считает, что он непризнанный гений и строит очень сложные конструкции потому что "он так видит". Это в разы опаснее. Можно нарушить SOLID, писать не по паттернам и код всё равно будет понятным. А можно по солиду такое чудовище искусства абстракционизма построить, что прийдётся идти за бутылкой джина, чтобы разобраться "а как это вообще работает то?"

Собственно в обсуждении плохого кода я показал неплохой пример своего "плохого кода", который может запутать в своей реализации. Так как единственный вопрос который может возникнуть по причине разделения паузы и состояния "А нахрена?" Но это ещё "ласковый" пример. Так как класс в 200 строк и в целом легко понять, что он в общем делает. А я прошу понять и простить, так как проект нужно было сдать за 7 дней, у меня была температура 38, и я был в целом не в себе :) А делать проект должен был уметь оооочень много. Но всё это делать он должен был всего два дня, так что как бы и ладно. Вот пример: https://pastebin.com/a9t7cFLX

Второй же пример. Хороший. Я опишу на словах, так как там нужно выкладывать репозиторий коммерческого проекта в паблик, чтобы объяснить всё элегантность решения. А так делать нельзя :) Есть у меня допустим проект по визуализации графов. И там используется подход того, что есть сторадж с данными о графах. Сам граф, вершины графа, алгоритм укладки знает только айди вершин и связи. Допустим вам нужна таблица всех вершин. Вы передаёте айди в скроллер, скроллер передаёт его карточкам, а карточки идут в сторадж чтобы забрать данные и их отрисовать. Тоже самое скажем с окном информации о вершине. Вы кликаете на вершину, вершина отдаёт айди окну, окно идёт в сторадж, забирает по айди объект и отрисовывает окно информации о вершине. То есть система вообще ничего не знает о характере данных. Вчера это был социальный граф, завтра это граф транзакций между пользователями. И для того, чтобы что-то изменить нужно просто будет переписать окна. А не переписывать во всей системе ссылки. Так как общая система манипулирует какими-то неизвестными циферками. Эта иллюстрация уже к примеру из публикации выше про "пробрасывать глубоко ссылки не стоит".

Просто часто плохим кодом почему-то называют ребята, особенно из других сфер, код который им непривычен и не нравится. Я встречал критику "что это за хрень" про Dirty Flag, хотя это вполне удобная себе штука в контексте Unity и является особенностью, а не плохим кодом. И пока я консультировал множество кампаний я повидал некоторое дерьмо. Самый ужасный код который я видел был для одной сине-голубой компании, в которой предыдущий подрядчик построил фабрику через фабрику на 10 фабрик создающих друг друга. Я 8 часов с логами тупо разбирался: "А как это вообще нахрен работает?" Просто есть особенности фреймворка, и в Unity нет такого, что он мотивирует писать плохой код. Просто написание кода в юнити имеет свои особенности к подходам и практикам. Так же как и в Entity, так же как и в ASP, так же как и в Xamarin :) Поэтому я не понимаю, когда мне говорят, что в Unity про плохой код. Плохой код пишут плохие программисты, а Unity просто инструмент, которым надо уметь пользоваться.

UPD. Даже не так. Плохой код пишут все, когда это нужно. Плохие программисты или ещё неопытные не видят, когда их код плохой :)

Лиды должны уметь говорить на языке бизнеса

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

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

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

Просто не понимая логику бизнеса и говоря на языке технарей очень тяжело защищать стабильность системы, сроки, идеи и т.п. Для того, чтобы бизнес понял, лучше всего либо предложить альтернативу, либо посчитать в деньгах. И важно понимать, что в случае некорректного решения ответственность должна быть на бизнесе, а вот если вы предложили альтернативу — ответственность на вас. И нельзя её избегать. Лид должен брать на себя ответственность, за идеи того что он защищает, чтобы иметь возможность договариваться. Иногда это будут ошибки. И это тоже нормально, так как никто не идеален. Но с опытом ошибки будут реже, а с бизнесом будет настроен именно диалог. Решает бизнес — его ответственность (если лид говорил "не надо"), решает лид — его ответственность. И проект движется в здоровом ритме, нормальной атмосфере и в среднем в таком диалоге получается лучше и быстрее, чем в монологе бизнеса или монологе технарей :)

Новая игра для White Label Games

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

Делаем крутые эффекты с помощью Animation Curve
https://habr.com/ru/post/699520/

А вот и время появилось таки написать статью про то, как Animation Curve в текстуру превращать и что с этим можно делать. Думаю это кому-то будет полезно.

Прикольная статья разбирающая аспекты настройки света в URP
https://blog.unity.com/games/shedding-light-on-universal-render-pipeline-for-unity-2021-lts

Когда-нибудь я и сам перееду на URP, буду писать шейдеры не кодом, а в шейдер графе и это всё будет супер полезно. Но это совсем другая история. Почему-то (возможно ошибочно) у меня до сих пор есть лёгкое недоверие к работе URP в мобильном WebGL. И что как только я начну туда переезжать, то огребу тонну... новых знаний. Но статья всё равно интересная.

Лучшая работа в мире...

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

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

Но я попробую показать в чём проблема примера хорошего кода. И что ко всему легко докопаться в статье про инвентарь. Как по вашему, это интересная тема? Ставьте 🔥 если да :)

Поговорил про AR технологии
https://tproger.ru/articles/tehnologija-ar-kak-rabotaet-i-na-chjom-sozdat-proekt/

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

Работает — не трогай?

И да, и как бы нет. Если проект не развивается, мёртв, никто его не тестирует и в целом "что-то работает и ладно". То лучше его не трогать. Один мой друг рассказывал смешную историю о том, как работа нескольких отделов встала, так как отдел разработки выключил VPN. Потому что никто не знал зачем он был нужен. Поэтому трогать такое бывает опасно. Да даже у меня бывало такое, когда я думаю что что-то работает (систему не трогали 3-4 месяца), отправляю клиенту, а потом узнаю что нет.

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