Para el renderizado de vóxel, ¿qué es más eficiente: VBO prefabricado o un sombreador de geometría?

Dada una matriz de vóxel bastante estática, lo que es más eficiente: usar la CPU para pregenerar un VBO para renderizar las caras de vóxel (ignorando formas más avanzadas de renderizado como los cubos de marcha por el momento) o usar un sombreador de geometría en la GPU para generar el rostros sobre la marcha?

No estoy tan preocupado por actualizar los voxels cambiantes, pero por supuesto eso es un beneficio de la versión de GPU ya que no tiene que reconstruir los VBO. Además, el enfoque GS se siente un poco más moderno :)

Por otro lado, no he visto los detalles sobre cómo un GS realmente funciona con la tubería de rasterización en las GPU modernas. ¿Produce los vértices en una especie de caché de flujo o los vértices se escriben en la memoria normal de la GPU en el medio? Si es lo último, supongo que la generación sobre la marcha podría reducir el ancho de banda disponible y la potencia de procesamiento del resto de las tareas de GPU, supongo, y sería más beneficioso hacerlo en la CPU.

Estoy pensando en una escena tipo minecraft, donde por voxel te refieres a un mundo de bloques que en realidad se representan usando polígonos:

Si usa un sombreador de geometría, será difícil evitar tener exactamente tres caras (o lo que sea) por vóxel.

Si tiene muchos bloques adyacentes que tienen la misma textura, puede usar el mosaico de las texturas para tener mucho menos triángulos en su tira (degenerada) en un enfoque VBO. Quiero decir, si hay un área grande y plana de 6x6 de vóxeles de hierba, puedes dibujar toda la parte superior en solo 2 triángulos en lugar de 64.

Con el enfoque GS no puede hacer el sacrificio trivial de caras ocluidas por vóxeles adyacentes que es muy sencillo con un enfoque VBO.

No he probado el enfoque GS, pero puedo decir que el enfoque VBO con la combinación de mosaicos adyacentes repetidos funciona muy bien. Descubrí que jugar con los índices de elementos es mucho más lento que simplemente repetir los vértices. Si divide su mundo en bonitos cubos pequeños, generalmente puede usar solo un byte por componente por vértice e incluso empacar la información de textura y las normales (una cara en un cubo alineado con un eje tiene solo 3 posibles normales), etc.en un cuarto byte para hacer 4 bytes por vértice, que es agradable y rápido.

He usado VBO por separado para cada una de las 6 caras: solo es necesario dibujar como máximo 3 de ellas obviamente. Esto encaja muy bien con las diferentes texturas que generalmente se usan en las partes superiores de los vóxeles estilo minecraft. Porque para cada conjunto lo normal y tal es entonces uniforme.

Con el uso de pixmaps en mosaico vertical en un atlas con GL_REPEATel eje horizontal y con versiones rotadas de 90 grados de los pixmaps en el mismo atlas, descubrí que puedo dibujar cantidades masivas de bloques aparentemente diferentes usando el mismo VBO en la misma llamada. En el ejemplo del área de césped 6x6, lo habría dividido en 12 triángulos ya que solo tengo repetir en una dimensión en mi atlas.

Principalmente he estado haciendo que esto funcione en el extremo más bajo de los chips gráficos integrados y dispositivos móviles, donde GS es algo con lo que puedo soñar algún día jugar.

¿Qué pasa con la tercera opción, usar matrices instanciadas? Básicamente, usted dibuja muchos cuadros (hechos de un simple cubo de 8 vértices) con una sola llamada de dibujo, obteniendo las posiciones (y otros datos) como atributos por instancia del VBO de datos de vóxel (usando glVertexAttribDivisorOpenGL, estoy seguro DX también tiene eso). Esto podría ser más rápido que el enfoque del sombreador de geometría, aunque el código de aplicación (sin sombreador) debería ser bastante similar, ya que recuerdo que los sombreadores de geometría tienen una reputación de ser lentos, aunque no tengo experiencia con ellos (o instancias) ya que todavía me siento en hardware 2.1.

Pero de todos modos, los sombreadores de geometría o los arreglos instanciados deberían ser más adecuados que la geometría de vóxel construida por la CPU, especialmente cuando los datos de vóxel están sujetos a cambios. Junto con la retroalimentación de transformación (¿salida de flujo en DX?), Es posible que pueda configurar una buena técnica de eliminación basada en GPU.

La versión del sombreador de geometría me suena mucho mejor. Solo puede tener el punto vbo y el cuadro de construcción sobre la marcha (punto de entrada, flujo de triángulo de salida). Será rápido (incluso más rápido si va a usar la unidad de teselación en el modelo de sombreador 5 eq. DX11) y reducirá el ancho de banda extremadamente, será una solución agradable y limpia.

Sobre GS Se coloca entre el sombreador de vértices y el sombreador de píxeles y modifica el flujo de vértices (primitivos) salidos. Mientras que el sombreador de vértices funciona solo en los vértices, el sombreador de geometría funciona en primitivas enteras. La salida de esta secuencia solo va al sombreador de píxeles (y se rasteriza antes de eso fuera de curso :)) y no hay forma de guardarla. (Tal vez por un renderizado loco a la textura y luego analizarlo ... pero no existe una posibilidad real simple)

Nota de rendimiento: debe poder hacer todo en el sombreador de geometría y omitir (solo pasar datos) el sombreador de vértices. Pero no es la mejor manera. Mejor (más rápido) es hacer la mayor parte de la transformación posible en el sombreador de vértices e intentar minimizar el programa de sombreador de geometría. No tenga miedo de usarlo para el ciclo si lo necesita (por ejemplo, para la creación de cajas). El compilador lo desenrollará por usted.