Это зависит от используемого вами метода пространственного разделения, хотя все методы разделения (как и любой метод сжатия) в конечном итоге оказываются там, где дальнейшее сжатие невозможно, из-за издержек структуры данных и других логических / математических факторов. Пример можно найти в октреях. Для каждого узла в октрее необходимо сохранить указатель на его родителя и / или потомков (в зависимости от того, как вы работаете с архитектурой структуры данных), чтобы обеспечить значимый обход. Любая древовидная структура может содержать n детей. Чем ниже соотношение 1: n, тем более эффективно используется пространство, которое вы получаете, и, следовательно, тем больше накладных расходов при обходе дерева, поскольку у вас должно быть больше узлов-предков, чтобы содержать такое же количество листовых вокселей (в вашем случае, примерно 510 триллионов из них представляющих площадь поверхности).
Учитывая, что в вашем случае основными проблемами являются стоимость хранения и рендеринг всей планеты (или ее частей) с достаточного расстояния, нет структуры данных, которую я бы порекомендовал бы за октри. Mipmapping является необходимостью: диаметр 12,8 миллиона метров при ближайшей более высокой степени 2 составляет 2 ^ 24 = 16,8 миллиона. 24 уровня восхождения на октаву означали бы огромное количество ветвлений - очень дорого для GPU и CPU. Но при условии, что вы все делаете правильно, вам нужно будет пройти только несколько уровней за раз. Однако, учитывая количество места, которое требуется, альтернативы немногочисленны и далеко друг от друга (см. Ниже).
Возможности mipmapping в ocerees делают его таким невероятно мощным инструментом для больших объемов, которые вы описываете. В отличие от всех других известных методов деления (за исключением KD-деревьев), октроя сохраняет деление на уровень минимальным, что означает, что визуальные и физические различия между уровнями mipmap также сохраняются минимальными, что означает гораздо более тонкие различия в детализации при переходе вверх и вниз по дереву.
Если, с другой стороны, вы хотите создать мир, в котором обход иерархической сетки сведен к минимуму, вам нужно будет обменять пространство на увеличение скорости.
Говоря об идеальном соотношении 1: n, в этом отношении нет более тонкой структуры, чем kd-дерево. Если октри делится на 2 для каждой оси, в результате чего 2 ^ 3 = 8 отдельных дочерних ячеек, дерево kd разделяется ровно один раз на уровень подразделения. Проблема в том, что вы должны выбрать гиперплоскость для разделения, и эту гиперплоскость можно выбрать вокруг любой из 3 осей. Несмотря на то, что он является оптимальным с точки зрения пространства, он делает 3D-обходы (например, во время лучевых меток, основной операцией при использовании октодеев для физики или рендеринга) гораздо более трудными, чем в октодереве, так как для записи необходимо сохранять динамическую структуру типа портала интерфейсы между отдельными узлами дерева kd.
RLE - это другой подход к сжатию, но его во многих отношениях сложнее применить к такой проблеме (где основа операций сферическая), поскольку сжатие RLE является одномерным, и вы должны выбрать ось, в которой оно работает. планета, можно было бы выбрать полярную ось, но любой одноосный выбор привел бы к определенным проблемам с обходами для рендеринга и физики при действии с определенных неоптимальных углов. Конечно, вы можете также запустить RLE по 3 осям одновременно, утроив стоимость хранения или по 6 осям (-x, + x, -y, + y, -z, + z) в качестве дополнительной оптимизации.
Так что ответить на ваш вопрос (или нет!)
Я не собираюсь прямо отвечать на вопрос о том, какое оборудование, но я думаю, что рассмотрение этого вопроса с точки зрения октодерева начинает давать вам представление о том, что на самом деле возможно на каком типе оборудования. Я бы посоветовал вам пойти по этому пути, если вы действительно хотите знать, может быть проще всего реализовать простое разреженное октри(см. статью Лейна в ссылках) и поместите в нее сферическую оболочку поверхностных вокселей и посмотрите, каково полученное в результате использование пространства. Шаг вперед оттуда. Посмотрите, как далеко вы можете пройти, прежде чем ваша системная память начнет выдавать. Это не требует написания рендерера, если вы не хотите визуализации. Также имейте в виду, что это лучше всего делать на процессорах - графические процессоры в целом не имеют емкости памяти для решения проблем такого масштаба. Это одна из причин, по которой Intel рассматривает переход к массово параллельным процессорам: преимущества GPGPU, который лучше в этом деле, могут быть применены к гораздо более обширному пространству памяти без узких мест системной шины. Есть, вероятно, другие здесь или на mathematics.stackexchange.com,
Конечно, с точки зрения вашего требования к расстоянию до бесконечности, но вопрос всегда сводится к тому, «сколько деталей на каком расстоянии». Рендеринг бесконечных деталей потребовал бы бесконечных ресурсов. Вот тут-то и вступают в игру переменные на сцену. Также имейте в виду, что все структуры данных воплощают некоторый компромисс скорости для пространства или наоборот. Это означает меньше / медленнее рендеринг, если вы хотите больший мир за то же количество инженерных усилий.