Загрузка буфера вершин и индексов в GPU

Обычно вы разделяете свою местность на несколько небольших участков, которые вы транслируете по мере движения игрока. В моем движке ландшафта я никогда не помещал индексный буфер в объекты буфера, так как механизм LOD постоянно меняет отрисовываемые вершины и порядок отрисовки для улучшения раннего Z. 256×256 — разумный размер патча, особенно если вы используете структура, подобная quadtrees.

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

   |   |
---+---+---
   | C |
---+---+---
   |   |

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

 A |   |
---+---+---
 B | X-> C
---+---+---
 C |   |

переназначит плитки A, B, C на

       |   | A'
    ---+---+---
       ->C | B'
    ---+---+---
       |   | C'

Где A', B', C' повторно используют память A, B, C, но наполняют ее новым содержанием. Поскольку игрок перемещается в новый патч C с дальнего конца, т. е. просто может видеть более близкие части новых патчей, вы можете загружать содержимое A', B', C' в течение нескольких кадров.

Чтобы ответить на ваши два вопроса:

1. загрузка геометрии на самом деле является довольно быстрым процессом, так что это не мешает шоу. Вы не увидите мерцания, так как загрузка данных происходит между кадрами рендеринга, и только после обновления данных начнутся команды рисования.

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