Карта листов с огромными данными набора плиток для рендеринга OpenGL (текстура как изображение не подходит)

Question

У меня большой двоичный файл. Он содержит плитки размером 32x32 пикселей. Каждый пиксель имеет цвет RBG 32 бита. Из-за структуры двоичного файла его нельзя отобразить в текстурное изображение.

В прошлый раз, когда я пытался загрузить сгенерированную текстуру с SFML со следующими размерами 40 416 x 512 пикселей, возникает исключение, что такие текстуры не поддерживаются.

Как я могу рендерить плитки на экране без манипуляций с текстурой и координатами?

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

Двоичный файл имеет следующие разделы: Массив мегаполисов. Массив мегатил. Массив мини-файлов. Цветовая палитра.

Каждая группа мегаполисов является массивом с 16 мегапиксельными единицами. Каждый мегапиксель - это массив 8x8 с минимальными значениями. Каждый мини-файл представляет собой массив значений цвета 4x4 из палитры. Палитра представляет собой массив из 256 32-битных цветов RGB.

Например:

First megatile group just contains 16 0:
[0, 0, ..., 0] (0 x 16)
0-indexed megatile is array with minitile indexes size of 8x8. All its elementes are 0.
[0, 0, ..., 0] (0 x 64)
0-indexed minitile is an 4x4 array. Each element represent color from palette. All its elements are 0.
[0, 0, ... 0] (0 x 16)
0-indexed color from pallete is just black color in 32 bits rgb.

Ячейка тайловой карты определяется индексом мегаполисной группы и индексом мегаполиса в группе. Таким образом, в любой точке для некоторого тайла (определяемого парой мегаполисной группы и мегаполиса из этой группы) из файла тайпла я могу получить массив 32x32 пикселей. Как я могу отрисовать тайл карту?

Answer 1

Как я могу нарисовать много ГБ образ OpenGL, когда недостаточно памяти GPU?
Первая идея: кусками.

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

Но, подождите, все ГБ действительно?

Для монитора 4K 3840x2160 = 8,3 МПикселя требуется 8,3 x 4 = 33,2 МБ данных RGBA.
Вопрос в том, как выбрать 33,2 МБ среди стольких ГБ необработанных данных.

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

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

Оба улучшения могут быть достигнуты с quadtree лучше, чем массив.
В нем хранятся указатели или идентификаторы на плитках. Но также для промежуточных узлов a репрезентативных точек со средним цветом его подузлов. Или репрезентативная плитка, которая «сжимает» несколько плиток.

Пройдите по дереву. Откажитесь от узлов (и, следовательно, их ветвей) из fustrum. Визуализируйте репрезентативные точки / плитки вместо текстур, когда плитка слишком далеко. Рендеринг всей плитки, когда какой-то край больше 1 пикселя.

Вы не будете отправлять только 33,2 МБ, но что-то меньше 100 МБ, с чем довольно легко справиться.