Нужна помощь в реализации VBO с Frustum Culling

Question

В настоящее время я разрабатываю свою первую 3D-игру для школьного проекта, игровой мир полностью вдохновлен Minecraft (мир, полностью состоящий из кубов). В настоящее время я пытаюсь улучшить производительность, пытаясь реализовать объекты буфера вершин, но я застрял, у меня уже есть реализованные методы: Отбор Frustum, только отрисовка открытых граней и отбор расстояний, но у меня есть следующие сомнения:

1. В настоящее время у меня есть около 2 ^ 24 кубов в моем мире, разделенных на 1024 порции по 16 * 16 * 64 кубов, сейчас я делаю рендеринг в режиме немедленного режима, который хорошо работает с отбраковкой усеченного конуса, если я реализую один VBO на чанк, нужно ли обновлять этот VBO каждый раз, когда я перемещаю камеру (чтобы обновить усеченный конус)? Есть ли снижение производительности с этим?

2. Могу ли я динамически изменять размер каждого VBO? Или я должен сделать каждый максимально большой размер (кусок полностью заполнен объектами)?.

3. Должен ли я хранить каждый посещенный фрагмент в памяти или я мог бы эффективно удалить это VBO и воссоздать его при необходимости.

Answer 1

1. Первый наивный (не обязательно в плохом смысле) подход действительно заключается в обновлении VBO каждого кадра на основе результатов усеченного контура и скрытого лицевого отбора.Хотя это может показаться злым, имейте в виду, что использование немедленного режима на самом деле делает то же самое (отправка каждой вершины в GPU каждый кадр), но с миллионом вызовов драйвера (не стоит недооценивать glVertex) вместо нескольких буферовфункции и один вызов отрисовки.

   Таким образом, использование VBO (с использованием GL_DYNAMIC_DRAW или даже GL_STREAM_DRAW, конечно), скорее всего, все равно будет быстрее, чем непосредственный режим.Это не только возможное хранение в графическом процессоре, но и уменьшенное количество вызовов драйверов, которые делают VBO (или вершинные массивы в целом) быстрее, чем непосредственный режим.

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

2. Поскольку вы обновляете весь буфер каждый кадр (ипоэтому в любом случае следует вызвать glBufferData), изменение размера абсолютно не проблема.Просто позвоните glBufferData еще раз с другим размером.

3. Это зависит от того, сколько у вас кусков.Но если их число становится больше, хорошей техникой может быть некоторая техника кеширования (удаление VBO на расстоянии, отбракованное расстояние, куски).

Answer 2

1. Изменение VBO при каждой смене камеры не может быть хорошей идеей. Затраты на непрерывную буферизацию данных, вероятно, перевесят любой выигрыш в производительности, который вы получите, если будете рисовать меньше полигонов. Вам, вероятно, будет лучше отбирать целые VBO, когда они полностью выходят из-под контроля. В итоге вы получите больше полировок, чем строго необходимо, но это будет более чем уравновешено тем, что рисование из VBO значительно быстрее, чем рисование в непосредственном режиме.
2. Вы можете изменить размер VBO, но только сделав новый вызов на glBufferData, который может быть дорогим, если вы отправляете данные на видеокарту.
3. Лучше не хранить в памяти все фрагменты, для которых вы создали VBO, что быстро выйдет из-под контроля. Лучше всего сохранять память о ближайшем окружении и отбрасывать их, когда вы уходите.