Directrices para optimizar el rendimiento de WebGL, reduciendo al mínimo los cambios de sombreado / estatales

Question

Estoy tratando de tener una idea de la viabilidad de WebGL para la prestación de grandes escenas de interiores, que consta de 100 K de los triángulos. Estos triángulos se distribuyen en muchos objetos, y hay muchos materiales en la escena. Por otro lado, no hay partes móviles. Y los materiales tienden a ser bastante simple, sobre todo basado en los mapas de textura. Hay una gran cantidad de mapa de textura compartir .. por ejemplo, todas las sillas en escena compartirán un mapa común. También hay algo de multitexturas -. Hasta tres texturas superpuestas en un material

He estado haciendo un poco de experimentación y de la lectura, y que recojo que los materiales de conmutación de frecuencia durante un pase de renderizado se ralentizar las cosas. Por ejemplo, una escena con 200K triángulos tendrá diferencias significativas de rendimiento, dependiendo de si hay 10 o 1000 objetos, suponiendo que cada vez que un objeto se visualiza un nuevo material está configurado.

Así que parece que si el rendimiento es importante la escena se debe ordenar por materiales con el fin de minimizar el cambio de material. Lo que estoy buscando es directrices sobre la manera de pensar de la sobrecarga de varios cambios de estado, y dónde puedo obtener el mayor retorno de la inversión. Por ejemplo,

• ¿cuáles son los costos de rendimiento relativo de, por ejemplo, gl.useProgram(), gl.uniformMatrix4fv(), gl.drawElements()
• debería intentar escribir ubershaders para minimizar la conmutación de sombreado?
• ¿Debería tratar de geometría agregada para reducir al mínimo el número de llamadas gl.drawElements()

Me da cuenta de que el kilometraje puede variar en función de navegador, sistema operativo y hardware de gráficos. Y estoy tampoco en busca de medidas heroicas. Sólo algunas pautas de personas que ya han tenido alguna experiencia en la fabricación de las escenas rápidas. Voy a añadir que, si bien he tenido alguna experiencia con-ducto fijo de programación OpenGL en el pasado, soy bastante nuevo en el WebGL / OpenGL ES 2.0 forma de hacer las cosas.

Answer 1

¿Ha leído por lotes , por lotes, por lotes ? Es cierto, se centra en DirectX, pero el razonamiento se aplica en menor medida a Abrir / WebGL también: Cada llamada a la API tiene una sobrecarga significativa en la CPU. El consejo es utilizar todas las opciones de la API para compartir texturas, el uso de instancias (si está disponible), escribir shaders complejos para evitar muchas llamadas de sorteo. Por lo que si se puede dibujar toda la casa como una única malla en una sola llamada, eso sería mejor que 1000 llamadas para cada habitación. Escribiendo ubershaders está recomendado, pero sobre todo porque puede permitir que usted pueda eliminar dibujar llamadas, no porque la conmutación del estado GPU es caro.

Esto supone reciente de hardware. Para los chips plataformas de gama baja (IPAD?) O Intel GMA, los cuellos de botella será en otro lugar (como en el procesamiento de vértices de software).