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

Вроде бы базовый список и все понятно, но улетело ппц куча времени на это все. Особенно куча времени улетела в тулзы вокруг всего этого: color picker, редактор градиента, рейнджи для курв и куча-куча фиксов-улучшалок базового редакторе.

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

Окей, что там под капотом, собственно. Здесь я попытался реализовать какое-то приближение DOD, ибо системы частиц как правило очень тяжелые на апдейт.

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

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

У частиц могут быть дополнительные параметры, необходимые для эффектов. Например кеш для поиска фрейма кривых или начальные параметры для эффекта. Они складируются в линейных массивах внутри самих эффектов

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

Рендер частиц привязан к контейнерам, которые получают список частиц и рисуют в зависимости от своей логики: просто спрайт, спрайт-шит, или другие кастомные рендеры (напр. когда частица - это актор на сцене). Контейнер получает сообщения о рождении или смерти частицы, а на этапе отрисовки получает актуальный массив частиц. Внутри себя он строит геометрию и рендерит ее. Для обычных спрайтов все просто - частицы это квады. Для спрайт-шитов дополнительно рассчитывается UV из атласа для натягивания на те же квады. Меши геометрии предсозданы заранее, но обновляются каждый раз. Аллокаций нет, только расчет вершин и отправка в рендер

Эмитирование происходит в апдейте. Существует буффер времени, который копится пока не нужно будет сэмитировать частицу (или несколько). Работает просто - на апдейте прибавляется время кадра dt, рассчитывается через какие промежутки должны эмитироваться частицы, и этот буффер "разгребается", пока он больше чем время эмитирования частицы.

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

При эмитировнии частицы оповещается контейнер (как писал выше), а так же все эффекты. Каждый эффект может сделать все что нужно с частицей.

Сама система частиц привязана к трансформации актора, на которой она находится. Геометрия привязана к размеру актора так же. То есть нет отдельных параметров типа ширины и высоты, они просто берутся из актора, т.к. в движке он уже обладает этими параметрами.

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

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

В игре, в обычном рантайме редко происходят такие вещи с анимациями, обычно они просто приоигрываются вперед. В таком случае достаточно простого апдейта частиц

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

Если такого кадра нет, то система ищет последний запеченый кадр и восстанавливает его состояние. Здесь важно что восстанавливаются не только состояния частиц, но и состояние эмиттера - напр. буффер времени эмитирования частиц. Далее происходит симуляция апдейта частиц до необходимого кадра Х, с одновременным запеканием кадров. Симуляция происходит с фиксированным delta time 1/60 секунды.

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

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

Для работы частиц в виде управляемого трека используется единый интерфейс движка IAnimation. Его суть проста - он умеет апдейтиться, стартовать и останавливаться, и обладает длительностью. Частицы обладают всем этим, и легко поддерживают этот интерфейс

Через него и работают дочерние треки анимаций. Просто делается специальный тип саб-трека, который содержит в себе ссылку на интерфейс IAnimation. Это может быть и другая такая же анимация. Все это позволяет "дирижировать" более простыми анимациями и эффектам, для создания чего-то более сложного, например кат-сцены или анимации UI

Пара слов о ткущей работе - прикрутил к движку spine. Это распространенная тулза и runtime для скелетных анимаций. Интересно то, что фактически в движке у меня уже есть аналогичная система скелетной анимации, в т.ч. с поддержкой скиннинга.

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

Своя система, конечно же интегрирована в движок более нативною Она построена на иерархии сцены и она более плотно интегрирована со всеми подсистемами движка: те же анимации и частицы. Мой классический пример: в UI есть скелетная анимация персонажа с эффектами частиц в руке (фаерболл например). Если пытаться все это связать из сторонних инструментов, получается франкинштейн: spine и UI не связаны, придется делать какие-то мокапы и подложки. То же самое с частицами, их не получится увидеть в редакторе spine. В этом плане свое решение гораздо более выигрышно, ведь все находится в одной экосистеме и нативно состыкуется друг с другом.

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

Тем не менее, я стараюсь сделать все чтобы тот же сторонний spine как можно лучше был интегрирован в экосистему движка. Его анимации для движка выглядят как реализация интерфейса IAnimation, соответственно их можно использовать как и нативные анимации движка - делать саб-треки, использовать из кода и т.п.

Так же сейчас делаю аналог Animator'а из Unity3D - граф анимационных состояний. Он сможет работать как с нативными анимациями, так и со spine.

Немного красоты 🤩

анимация переключения стейтов графа анимаций в редакторе. Синенькое - запланировано, красное - пройдено

Поговорим про уникальные идентификаторы, или UID'ы, и выясним, в чём их практическая полезность

Самое важное качество UID'ов заключается в их уникальности. Случайно сгенерированный 128-битный UID практически гарантирует абсолютную уникальность. Конечно, теоретически повтор возможен, но вероятность этого настолько ничтожна, что на практике, даже если генерировать по несколько идентификаторов в секунду, вы не столкнётесь с таким событием на протяжении всей своей жизни.

Дополнительно некоторые «взрослые» реализации UID'ов включают в себя временную метку (таймстемп) генерации, что ещё сильнее снижает вероятность дублирования. Также типичная реализация UID может включать информацию о версии UID (тип генерации: рандомный, с таймстемпом или на основе MAC-адреса), данные о машине или устройстве (например, MAC-адрес, идентификатор узла или процессора) и служебные или зарезервированные биты для совместимости и будущих расширений.

Но зачем вообще использовать UID'ы? Ответ прост: они незаменимы для идентификации уникальных сущностей. Например, в разработке игр и движков часто возникает необходимость чётко различать различные игровые ассеты.

Кажется, можно просто использовать строковый идентификатор на основе имени ассета. Такой подход удобен, но быстро проявляется проблема повторяющихся названий. Например, часто возникает необходимость назвать два разных объекта одинаково, скажем "door". Тогда можно было бы использовать префиксы и суффиксы (например, "door_left", "door_right") или включать в идентификатор путь по папкам и подпапкам (например, "rooms/left/door", "dooms/right/door").

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

Здесь идеально подходят UID'ы. Их уникальность достигается за счёт случайной генерации и большой разрядности, что исключает повторения даже при параллельной генерации.

Внутри же других ассетов (префабов, конфигов, сцен и т.д.) ссылки могут быть сохранены в виде UID'ов. Пользователям не важно, в каком виде хранятся эти ссылки, главное — удобство и понятность названий в редакторе. 

Ассеты — не единственная область применения UID'ов. Они отлично подходят для идентификации любых уникальных объектов, таких как ноды на сцене, ключи анимаций и многие другие.

ps: текст помогал генерировать GPT, интереса ради, как интереснее читать, когда автор сам пишет в своем стиле или все мысли укладываются и усредняются через AI?

Понабрасываем на хайповую тему - AI.

Нынче такое время, что из каждого утюга только и звенит "AI нас заменят, разработчики с AI в 10 раз производительнее, джун с AI лучше заменит трех сениоров" и так далее. У многих, не буду скрывать и у меня, это вызывает естественные опасения за свою профессию, достаток и свое будущее. Раньше мы смелись над таксистами, что яндекс и убер схавали их рынок, а скоро так вообще роботы заменят

Ладно, к чему я. Так ли все круто? Не тот ли это случай, когда какая-то новая штука так впечатляет своей новизной, что люди начинают верить в чудеса и светлое будущее которое настанет прямо сейчас? Ну, такое было, знаете, про VR шлемы и криптовалюты... Не буду даже вспоминать про 3D телики, которые уже скоро станут раритетом

Я попробовал поразмышлять, в более реалистичном и может быть даже пессимистичном ключе, насколько все хорошо в текущем AI, в разрезе программирования. Я с интересом наблюдаю за другими, провожу свои эксперименты и пытаюсь нащупать границу возможного

Расскажу свою точку зрения, на текущий момент. Да, черт возьми, меняется все так быстро, что нельзя загадывать даже на год вперед!

Итак, мы определенно идем в этом направлении: AI развивается и он уже имеет прикладное применение. Это невозможно отрицать и сопротивляться этому, это нужно просто принять. Иначе ты окажешься "за бортом", вопрос лишь в том насколько быстро

И насколько быстро? Да хер знает. Может быть generai AI (в моем понимании это AI, который может мыслить как человек) выкатят вот завтра, а может лет так через 20. Мне кажется сейчас две ключевые проблемы, которые осталось преодолеть:
- понимание как в принципе сделать general AI. Мы либо очень близки, либо уже умеем, но это не афишируется (рен-тв в чяте)
- вычислительные мощности

И мне кажется мы упремся во второй пункт, как ни странно. Где-то слышал, что тот жe OpenAI работает в минус, и доступные возможности заканчиваются (тут я очевидно дилетант, возможно несу чепуху). И что уже все доступные текста человечества стравили в сеть, то есть учить ее больше нечему. То есть, возможно, мы уже "уперлись". Мы определенно упираемся в текущий прогресс по чипам, используем максимум того что сейчас есть.

Здесь выплывает сразу два фактора:
- верхняя планка возможностей железа (точнее кремния, хех)
- экономическая целесообразность

Уверен чипы будут прогрессировать. Ну, прогрессируют пока что. А вот экономическая целесообразность - это прям то что будет определять заменить ли робот человека

Давайте представим, что УЖЕ изобрели general AI. Это точно он и все понимают что это работает. Но что если он будет занимать целую комнату и жрать гигатонну электричества ежесекундно, как первые компьютеры? То есть штука рабочая, но жутко затратная, и все таки офисный клерк, кушающий еду, спящий ночью и уходящий в отпуск на месяц в год тупо оказывается дешевле

Да, человечество поставит галку "искусственный интеллект", но экономически людей заменять будет не эффективно. Самый замес произойдет тогда, когда это станет выгоднее хотя бы на доллар, чем мясной скафандр для органической нейросети

А пока этого не произошло, можно не бояться что нас заменит яндекс или OpenAI

Моя "экспертная оценка пальцем в небо" - у нас есть 20-30 лет. Мы пройдем через стадии: изобретение general AI, наращивание мощностей и запихивание комнаты в наладонник, замещение человека на рабочих местах, матрица революция гххмм тут я думаю будет что-то вроде ассимиляции, то есть мы просто соединим свои мозги с электронными и продолжим развиваться дальше

Ладно, тут не рент-тв, а про программинг. Перейдем к конкретным кейсам

У меня, где-то год с лишним назад, когда ChatGPT вот вот вылупился, были пару экспериментов.

Первый - написать скрипт по граббингу банковскийх данных из csv в гугл-таблицу в определенном формате и с небольшой логикой: группировать покупки по дням не более 7 штук в день, с переносом на следующий если не влазит. Тогда ChatGPT фактически не справился и я буквально диктовал ему что нужно делать. Но, конечно, он снимал все проблемы по работе с google sheets api

Второй - рефакторинг движка с сырых указателей на умные, и там GPT тоже обосрался, выдавай хороший результат вперемешку с несусветной херью, из-за чего время на ручную фильтрацию было равносильно тому, чтобы сделать все самому вручную. О нем даже писал ранее

С тех пор многое шагнуло вперед, и сами сетки подросли и поумнели, и появились классные инструменты, например cursor. Если кто не знает, это форк от VS Code, в редактор текста которого плотно интегрирована работа с GPT. Он просто делает всю ту ручную херню, когда тебе нужно копипастить из ChatGPT в IDE

Уже давно я плотно подсел на copilot. Я никогда не ждал от него качественных решений, для меня это был умный автокомплит, просто ускоряющий набор текста для меня. Плюс справочник прямо на месте - либо комментом можно было спросить, либо он по контексту сам понимал что мне нужно и предлагал. Это очень полезно при работе с неизвестным API или языком, этап гуглежки сводится практически к нулю

microsoft утверждает что copilot может бустануть скорость программирования до 30%. Ну как мы понимаем до 30% может быть что угодно, хоть 29%, хоть 10%, хоть 0%. У меня по ощущениям это где-то 20%. И, вообще-то, это не мало!

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