Relict Engine: VBS/HS. Часть 1. Бэкенд⁠⁠

Все еще нарабатываю теорию по проблематике функционала.

Как я когда-то, еще в прошлом году, говорил, Relict Engine использует структуру сценических объектов, похожую на компонентную систему в Unreal Engine. т.е. эта структура представлена в виде нисходящего дерева, где каждая ветвь является частью сцены, наследуя трансформацию от родительской ветви. Иными словами, только ствол, или рут компонент имеет сразу трансформацию в мировом представлении. Все дочерние объекты будут пересчитывать свою трансформацию основываясь на матрице этого рутового объекта.

Задача бэкенда в контексте VBS/HS это хранение объектов в мировом пространстве VBS/HS. Иными словами, если мы захотим поставить звезду в координатах [ 2 световых года, 0, 0 ] относительно глобального центра координат, она там и должна быть. Без всяких но. И, если к этой звезде мы привяжем планету на расстоянии 8и световых минут от нее, то это так-же должно быть отражено в пространстве VBS/HS как есть. Даже, если в матрице трансформации звезды мы задали масштабирование. Иными словами мы должны всегда знать точную позицию того или иного объекта в пространстве VBS/HS, независимо от того, какие преобразования мы ему задали в родительском объекте.

Так-же абсолютно ясно, что хранить координаты таких объектов в "чистом" виде не выйдет из-за ограничений float и double (а long double с размерностью 128бит, пока еще не все компиляторы умеют). Тут можно подумать о комплексном представлении. Система Continius Calculation, упомянутая в прошлом посте (далее просто CC) сработает, однако, т.к. она держит числа в единицах с наименьшем битовым заполнением, для работы она будет постоянно эти хранимые числа перегонять в разные, удобные для расчета единицы. Иными словами - система надежная, но относительно медленная. Вчера довольно долго и обстоятельно общался с Gemeni на эту тему - по итогу (правда, я его сломал в конце) вектор для размышлений он дал довольно интересный. Он предложил разделить мир на кубы размером в 1Мм (мегаметр), а их в свою очередь на более мелкие кубы по 20километров каждый + локальное смещение. И объединить их в такую виртуальную сетку, где каждая координата будет состоять из 3х компонент вида [ Macro, Index, Offset ]. Система более внушительная и сложная для реализации, но для CPU с ней проще работать, а значит она будет быстрее.

Иными словами, если систему CC можно использовать, например в каких-то небольших проектах, то для движка это будет уже как стоп кран. Поэтому за основу мы возьмем систему с разбиением. CC, правда тоже не выбросим. Она пригодится для расчета линейных расстояний в более простом виде, т.к. система кубов эту проблему решить не может. И, по прикидкам, комбинация из этих двух систем даст нам на выходе сцену с ребром примерно равным 2000000000 (2 миллиарда) световых лет и с точностью позиционирования объектов на любом участке этой сцены вплоть до 1 миллиметра (неплохо, да?). Конечно такие размеры нам нафиг не сдались, а если говорить конкретно о Cold Fusion, то там будет задействован ничтожный кусочек этого диапазона меньше чем в 1 000 световых лет, но тут важен сам факт.

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