Пишем собственный воксельный движок

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

Забей. Все, кого я читал и кто на практике пытался прикрутить к воксельному движку октодерево, от него отказывались. Для сжатия чанков используй RLE ― примитивно и эффективно за счёт линейного доступа к памяти.

У меня даже была мысль, что можно данные чанков хранить в памяти в сжатом виде и распаковывать/запаковывать на лету когда надо. Попробовать не довелось, т.к. в моём движке блоки хранились не в отдельных чанках, а большом общем для всего видимого мира закольцованном 3д-массиве.

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

Основной проблемой было эффективное создание из фрагментов рендерящихся VBO, но мне удалось реализовать на C++ собственную версию «жадного создания мешей» (greedy meshing),

Тут я не совсем понял, что именно в итоге получается. Вот картинка:
http://i.piccy.info/i9/3ed4fab4365bebb9fb194162e75f4b84/1573063991/63783/1346249/collider_mesh.jpg Голубыми линиями показана сетка, которая рендерится, а зелёными ― упрощённая модель для физического движка. У тебя в итоге получается какой вариант?

Когда решал, стоит ли заморачиваться и оптимизировать сетку для ренедринга, для проверки взял и продублировал всю геометрию. Вершин и треугольников стало в 2 раза больше, но fps не уменьшился. Я тогда сделал вывод, что если стану сетку упрощать, то генерировать её буду дольше, а fps нихрена в итоге не увеличится.

При рендеринге сцены из 5x1x5 фрагментов в окне, не развёрнутом на весь экран, я получаю в среднем около 140 FPS (с отключенным VSYNC).

На каком железе?