Ничего давно не постил. Потихоньку делаю work-graph для работы с GPU в движке и эдиторе.

Сначала я хотел просто отображать графи рендерпассов, без возможности менять его в UI, так как он задается кодом.

Сейчас рядом с рендерграфом почти вырос более обобщенный WorkGraph, который можно собрать из джобов, которые плагины будут экспортировать. Джобы будут инстанциироваться и соединятся как угодно, в пределах типизации пинов.
В первом черновике входы и выходы типизировались растовыми типами и соотвественно в данных лежал TypeId, но так как плагины могут в рантайме перезагружаться, то TypeId может меняться.
Сейчас за неимением сильно лучшей альтернативы в нодах лежит kind: String. А в дженерик методах, где есть тип T: Target проверяется T::kind() == pin.kind. Если у вас есть идеи что будет лучше, милости прошу, оставьте в комментариях.

Но граф существует как граф только в редакторе.
В джижке он тут же превращается в тыкву очередь.
В самом деле, зачем нам хранить граф как граф, если нас интересует только его обход в dependencies-first или dependencies-last порядке. Можно просто сделать очередь и ходить по ней в двух направлениях.

В конструкторе WorkGraph на вход подаются джобы и их связи.
Портам, которые соединены с другим(и) назначаются target IDшки, так что бы у соединенных был одинаковый ID, а так же у update пар внутри каждой джобы.
Еще всем входам прописываются их джобы-зависимости. Почему портам а не джобам? Сейчас мы к этому придем.

WorkGraph в движке получается полу-статичный, при изменении набора нод или связей нужно пересобрать движковый WorkGraph. Это совершенно нормально, потому что меняется граф только когда разработчик руками его меняет, то есть очень не часто в разработке, а в проде вообще никогда.

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

Дальше то что идет каждый кадр.
1. Планирование. Берем все внешние таргеты и добавляем в сет selected все джобы ноды от этих выходов.
2. Потом идем с конца, пропуская джобы не из selected и собираем дескрипшны со всех входов, так мы узнаем например какого разрешение должен быть таргет картинка или размер таргета буфера.
В этот момент так же добавляются в selected джобы-зависимости каждого входного порта. Да, вот они где используются.
В конце получаем сет всех джоб, которые нужно запустить, что бы заполнить все внешние таргеты. А еще у каждого таргета, который нужно будет создать, собирается Target::Info для инициализации.
3. Наконец идем в прямом порядке и запускаем выполнение всех selected джоб. В этот момент создаются все нужные таргеты (берутся из кэша, если предыдущий Target::Info совпадает).
Кроме таргетов джоба аллоцирует нужное количество CommandEncoder -ов которые сразу кладутся в очередь, а джобе достается только ссылка. Так джоба не забудет сделать Queue::submit, потому что она и не должна.
К тому же перед тем как отдать первый CommandBuffer джобе, туда ловко вставляется синхронизация (в коде еще нет, но такой план).
Так же джоба вольна пользоваться Device для создания внутренних ресурсов и чего только ей не захочется.
4. В последний CommandEncoder вписывается синхронизация между джобами и внешним кодом для внешних ресурсов. Туда же добавится CommandEncoder::present. После чего все они сабмитятся в порядке аллокации.

Вот так примерно оно должно будет работать.

Кто досюда дочитал - молодец и умница, возьми угощение на полочке и поставь лайк.

Попался любопытный проект.
https://github.com/ronnychevalier/cargo-multivers
Наверное, с распоследними векторными оптимизациями какая-нибудь рапира сможет потянуть еще больше тел

Абсолютно неожиданно человек взял мой egui-snarl и noise (не мой crate для генерации текстурок шумов) и сделал красивый GUI.

Да еще и сказал "Overall the experience was fantastic and this crate made the whole thing possible".
Что ж, я получил +10 к уверенности в соих способностях и желанию продолжать делать опенсорс.

Добавил поддержку некоторых коллекций.
Массивы, вектора и хэшмапы.
Вектора и хэшмапы можно показывть замороженными с аттрибутом #[egui_probe(frozen)] над полем.
В таком случае нельзя добавлять/удалять элементы, за то убираются некоторые трейт-баунды.

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

Сделал пример использования egui-probe + edict.
Тут можно создать сущностей, добавить или убрать им компоненты и посмотреть на любую сущность с помощью EguiProbe имплементации компонентов.
Смотрящий код при этом знать не знает какие бывают типы компонентов вообще.
Кверит все &mut dyn Inspect что есть у сущности. Inspect реализуется через EguiProbe.

Всех с наступившим!
Желаю всем быстрой компиляции и благосклонного борроучеккера!

Пофиксил сегодня глупейший баг.

Нужно было из вектора пройтись по всем элементам и вызвать метод, возвращающий bool, и вернуть true если хотя бы один вызов метода вернет true.

Угадайте, что я сделал не так?

Зарефакторил плагины физики и движения.
Теперь для создания тел и коллайдеров не нужно тянуть ресурс физики, что упрощает API, так как с захваченным ресурсом физики нельзя было вызывать world.spawn и приходилось создавать тело и коллайдер заранее.
Теперь тело в физическом мире само проинициализируется перед следующим шагом симуляции.
Еще сделал возможность создавать коллайдеры для тел в дочерних сущностях. При дропе тела или сущности с телом дочерние сущности с коллайдерами будут уничтожены.
Плагин движения теперь не мешает прикладывать силу и импульс к телам из других источников.
А для кинематических тел корректно прикладывается не сила а скорость или позиция.
Так же добавил компонент флаг что бы отмечать позиционные кинематические тела, что бы только к ним применять изменения из компонента трансформа.
А после симуляции только от активных динамических тел пишется новая позиция в компонент трансформа.

На видео шарики при взрыве расталкивают соседей, прикладывая им мгновенный импульс.

В общем, чувствую, пора делать мини-игру, а не просто системами жонглировать.

И желательно прямо с этим обрубком SDF-рендера :)

Если у вас есть идеи, милости прошу в комментарии.

Ах да, точно, еще же я починил отображение нескольких игровых симуляций в ed!

Это не про Раст, но тем не менее, это гениально!

tldr
Используя символы из юникода, который разрешен в идентификаторах, но выглядят как больше/меньше, этот человек делает мономорфизацию с шаблона что бы писать утиный дженерик код в Go.
Да это почти не отличается от того как раньше работали шаблоны в С++ и вполне подошло бы для других языков.
Но вы еще найдите язык
1. Без дженериков
2. С юникодом
Кажется это только Go :)

Добавил возможность реагировать на сильные столкновения, а не на все вообще.
Коллайдеры не-сенсоры скорее всего только в таких и будут заинтересованны.

На этом я заканчиваю взрывать мячики.
Следующий шаг - завершить рендер пайплайн для пиксельной игры

Слегка подвыгорел и взял небольшую паузу в разработке движка.
Планировал чем заняться дальше в первую очередь.

И тут вот такой мотиватор пожаловал.
Наконец-то одобрили мой профиль на GitHub Sponsors
https://github.com/sponsors/zakarumych
Я буду капец как рад даже одному :)

Вспомнилось тут, что бусти у меня тоже есть
https://boosty.to/zakarumych