Я рисую поверхность, состоящую из тысяч кубов. Однако, когда я смотрю в позитивном направлении Z - вот где свет, я получаю низкие fps и артефакты. Вот как это выглядит, когда я смотрю в отрицательном направлении Z: 
Вот как это выглядит, когда я смотрю в положительном направлении Z, также падает фпс заметно: 
Opengl low FPS при взгляде в определенном направлении
Вы, вероятно, зависит от порядок, в котором отображаются ваши кубы. Это объясняет, почему существует разница между поиском + Z или -Z. При рендеринге назад, каждый фрагмент каждого куба визуализируется. При визуализации спереди назад с помощью теста глубины большинство фрагментов будут отброшены. Что касается артефактов, которые вы видите, может быть Z-борьба, но это длинный выстрел.
Это имеет смысл. Есть ли другой способ включить визуализацию спереди назад, отличное от ручного? – user1760770
Существует несколько способов оптимизации рендеринга. Это действительно зависит от того, какое РЕАЛЬНОЕ применение вашего кода (я предполагаю, что вы действительно не хотите использовать несколько тысяч кубов только для рисования пола). Но в этом конкретном случае вам не нужно воспринимать окклюдированные лица (запрос окклюзии, отбраковка, отрисовка назад, удаление только одной большой сферы ...). Нам потребуется дополнительная информация, чтобы помочь вам в дальнейшем. Но я думаю, вы уже можете попробовать их. Надеюсь, это поможет –
Большое спасибо :) – user1760770
Насколько плохо это падение производительности? Если вы выполняете предварительный проход вашей геометрии Z-only, пропуская записи в буфере цветов (и используя очень простой сквозной шейдер фрагмента), вы можете значительно повысить производительность в ситуациях, когда у вас плохо упорядоченная/несортированная геометрия и ограничение заполнения ограничено. Однако это помогает, когда вы выполняете сложную обработку фрагментов; он вводит в два раза избыточное преобразование вершины, поскольку вы в основном рисуете все дважды. Ваша ситуация может быть как вершинной, так и фрагментированной, поскольку компоновка поверхностей кубов не является наиболее эффективным способом рендеринга больших плоских поверхностей.
Мое другое предложение, так как вы упоминаете, что рендеринг сцены, состоящей из «тысяч кубов», будет реализовывать нечто похожее на обрушение вокселя. Все ваши кубы в этом примере, кажется, находятся в одной плоскости, вы можете легко заменить грани для коллекции таких кубов с меньшим количеством граней, которые объединяют смежные кубы. Minecraft делает это, периодически переставляя динамически обновляемые части сцены, используя жадный алгоритм сетки.
Конечно, пространственное разделение - это еще одна проблема, но я предполагаю, что у вас уже есть какая-то система на месте?
Да, я знаю. Проблема, с которой я столкнулась в оригинальной записи, была так же, как Жан-Симон Брочу, предложив с возвратом к рендерингу. Я уже изменил это, и он отлично работает. Спасибо за понимание. – user1760770
Вы реализовали какую-то отбраковку? Как вы делаете кубы, когда они касаются? Низкие fps обычно указывают на множество вычислений, которые могут произойти, если вы не уменьшаете количество вершин, когда это возможно. – Femaref
Я включил отбраковку задней поверхности. Кубики оказываются при касании, когда они одиноки. – user1760770
Как точно выглядят артефакты? – Femaref