Доброй ночи неспящим 👀
Построение деревьев для просчёта коллизий, хоть и реальное, но очень сложное и вычислительно дорогое дело, а значит необходимо кэширование построенного дерева в чанке без изменений. К тому же, применение чистой ecs архитектуры совсем не упрощает задачу, а даже наоборот.
Как бы я не ходил вокруг, мне не хватает одного единственного пазла, который бы склеил всю картину. Возможность помечать данные любого компонента как "грязные" или изменённые. Такая фича позволила бы следить в системах за компонентами и действовать только если они были изменены.
Вводить компонент тэг - грустно, потому что это не решит проблему системно на уровне движка.
Была мысль внедрить флаг прямо в компонент менеджер, но тогда любое изменение в компоненте должно было бы делаться с помощью специального метода Set() который бы также отмечал, что компонент был изменен. Вроде решение, но проблема в том, что текущее апи позволяет обратиться к ячейке с данными по указателю, а значит и менять напрямую. И как бы я не старался, я не могу придумать элегантное и перформантное решение, которое бы следило за изменениями в памяти каждого компонента, каждого элемента.
Складывается ощущение, что при действительно полной и идеальной системе это показало бы невероятные результаты обработки бесконечных миров, позволяющих очень быстро проходить по большому объему данных. Но как будто эта технология начинает влиять на ядро движка, которое изначально было создано с наилучшим подходом к производительности.
Возможно, стоит подумать об альтернативных методах поиска коллизий на широкой фазе или убедиться, что переработка апи изменения значения компонентов не приведет к значительному снижению производительности.
Кажется, эту ночь я проведу в мучительных снах о выборе между алгоритмами spatial hash + bvh и spatial hash + sweep and prune.