opengl-es - que - webgl supported browser
¿Cómo funciona WebGL? (2)
Esperemos que este pequeño artículo te sea de utilidad. Hace un resumen de una gran parte de lo que he aprendido sobre WebGL y 3D en general. Por cierto, si me equivoco, alguien me corrige, ¡porque todavía estoy aprendiendo!
Arquitectura
El navegador es solo eso, un navegador web. Todo lo que hace es exponer la API de WebGL (a través de JavaScript), con la que el programador hace todo lo demás.
Tan cerca de lo que puedo decir, la API de WebGL es esencialmente un conjunto de funciones de JavaScript (proporcionadas por el navegador) que envuelven la especificación de OpenGL ES. Entonces, si conoces OpenGL ES, puedes adoptar WebGL bastante rápido. Sin embargo, no confundas esto con OpenGL puro. El "ES" es importante.
La especificación de WebGL se dejó intencionalmente en un nivel muy bajo, dejando mucho que volver a implementar de una aplicación a otra. Depende de la comunidad escribir marcos para la automatización, y depende del desarrollador elegir qué marco usar (si corresponde). No es del todo difícil rodar el tuyo, pero significa una gran cantidad de gastos generales para reinventar la rueda. (FWIW, he estado trabajando en mi propio marco de WebGL llamado Jax por un tiempo).
El controlador de gráficos proporciona la implementación de OpenGL ES que realmente ejecuta su código. En este punto, se está ejecutando en el hardware de la máquina, incluso debajo del código C. Si bien esto es lo que hace que WebGL sea posible en primer lugar, también es un arma de doble filo porque los errores en el controlador de OpenGL ES (que ya he notado en un buen número) aparecerán en su aplicación web, y no lo hará. necesariamente, conózcalo a menos que pueda contar con su base de usuarios para presentar informes de errores coherentes que incluyan versiones de SO, hardware de video y controladores. Aquí es cómo se ve el proceso de depuración para tales problemas.
En Windows, existe una capa adicional que existe entre la API de WebGL y el hardware: ANGLE, o "Motor de capa de gráficos casi nativo" . Debido a que los controladores de OpenGL ES en Windows generalmente apestan, ANGLE recibe esas llamadas y las convierte en llamadas de DirectX 9 en su lugar.
Dibujo en 3D
Ahora que sabe cómo se juntan las piezas, veamos una explicación de nivel inferior de cómo todo se une para producir una imagen en 3D.
JavaScript
Primero, el código JavaScript obtiene un contexto 3D de un elemento de lienzo HTML5. Luego registra un conjunto de sombreadores, que están escritos en GLSL ([Open] GL Shading Language) y esencialmente se asemejan al código C.
El resto del proceso es muy modular. Debe obtener los datos de vértice y cualquier otra información que pretenda usar (como los colores de vértice, las coordenadas de textura, etc.) hasta la canalización de gráficos usando uniformes y atributos que se definen en el sombreado, pero la distribución y el nombre exactos de Esta información depende mucho del desarrollador.
JavaScript configura las estructuras de datos iniciales y las envía a la API de WebGL, que las envía a ANGLE o OpenGL ES, que finalmente las envía al hardware de gráficos.
Sombreadores de vértices
Una vez que la información está disponible para el sombreador, el sombreador debe transformar la información en 2 fases para producir objetos 3D. La primera fase es el sombreado de vértices, que configura las coordenadas de la malla. (Esta etapa se ejecuta completamente en la tarjeta de video, debajo de todas las API analizadas anteriormente). En la mayoría de los casos, el proceso realizado en el sombreador de vértices se ve así:
gl_Position = PROJECTION_MATRIX * VIEW_MATRIX * MODEL_MATRIX * VERTEX_POSITION
donde VERTEX_POSITION es un vector 4D (x, y, z yw que generalmente se establece en 1); VIEW_MATRIX es una matriz 4x4 que representa la vista de la cámara al mundo; MODEL_MATRIX es una matriz 4x4 que transforma las coordenadas del espacio de objetos (es decir, las coords locales al objeto antes de que se haya aplicado la rotación o la traducción) en coordenadas del espacio del mundo; y PROJECTION_MATRIX que representa la lente de la cámara.
La mayoría de las veces,
VIEW_MATRIXyMODEL_MATRIXestánMODEL_MATRIXy se denominanMODELVIEW_MATRIX. Ocasionalmente, los 3 están precomputados enMODELVIEW_PROJECTION_MATRIXo simplementeMVP. En general, se trata de optimizaciones, aunque me gustaría encontrar tiempo para hacer algunos puntos de referencia. Es posible que la precomputación sea en realidad más lenta en JavaScript si se realiza en cada fotograma, ya que JavaScript en sí no es tan rápido. En este caso, la aceleración de hardware que se obtiene al hacer los cálculos en la GPU podría ser más rápida que hacerlo en la CPU en JavaScript. Por supuesto, podemos esperar que las futuras implementaciones de JS resuelvan este posible error simplemente por ser más rápidos.
Clip de coordenadas
Cuando todos estos se hayan aplicado, la variable gl_Position tendrá un conjunto de coordenadas XYZ que oscilan entre [-1, 1] y un componente W. Estos se llaman coordenadas de clip.
Vale la pena señalar que las coordenadas del clip es lo único que el sombreado de vértice realmente necesita producir. Puede omitir completamente las transformaciones matriciales realizadas anteriormente, siempre que produzca un resultado de coordenadas de clip. (Incluso he experimentado con el intercambio de matrices por cuaterniones; funcionó bien, pero deseché el proyecto porque no obtuve las mejoras de rendimiento que esperaba).
Después de proporcionar las coordenadas del clip a gl_Position WebGL divide el resultado por gl_Position.w produciendo lo que se denomina coordenadas de dispositivo normalizadas. Desde allí, proyectar un píxel en la pantalla es simplemente cuestión de multiplicar por 1/2 las dimensiones de la pantalla y luego agregar 1/2 de las dimensiones de la pantalla. [1] Aquí hay algunos ejemplos de coordenadas de clips traducidas a coordenadas 2D en una pantalla de 800x600:
clip = [0, 0]
x = (0 * 800/2) + 800/2 = 400
y = (0 * 600/2) + 600/2 = 300
clip = [0.5, 0.5]
x = (0.5 * 800/2) + 800/2 = 200 + 400 = 600
y = (0.5 * 600/2) + 600/2 = 150 + 300 = 450
clip = [-0.5, -0.25]
x = (-0.5 * 800/2) + 800/2 = -200 + 400 = 200
y = (-0.25 * 600/2) + 600/2 = -150 + 300 = 150
Sombreadores de píxeles
Una vez que se ha determinado dónde se debe dibujar un píxel, el píxel se transfiere al sombreador de píxeles, que elige el color real que será el píxel. Esto se puede hacer de muchas maneras, desde la simple codificación de un color específico a las búsquedas de texturas y el mapeado de paralaje y normal más avanzado (que son esencialmente formas de "hacer trampa" de las texturas para producir diferentes efectos).
Profundidad y el tampón de profundidad
Ahora, hasta ahora hemos ignorado el componente Z de las coordenadas del clip. Aquí es cómo funciona eso. Cuando se multiplicó por la matriz de proyección, el tercer componente del clip resultó en algún número. Si ese número es mayor que 1.0 o menor que -1.0, entonces el número está más allá del rango de vista de la matriz de proyección, correspondiente a los valores de matriz zFar y zNear, respectivamente.
Entonces, si no está en el rango [-1, 1], entonces se recorta por completo. Si está en ese rango, entonces el valor Z se escala a 0 a 1 [2] y se compara con el búfer de profundidad [3] . El búfer de profundidad es igual a las dimensiones de la pantalla, por lo que si se usa una proyección de 800x600, el búfer de profundidad es de 800 píxeles de ancho y 600 píxeles de alto. Ya tenemos las coordenadas X e Y de los píxeles, por lo que se conectan al búfer de profundidad para obtener el valor Z almacenado actualmente. Si el valor de Z es mayor que el nuevo valor de Z, entonces el nuevo valor de Z está más cerca de lo que se dibujó anteriormente y lo reemplaza [4] . En este punto, es seguro iluminar el píxel en cuestión (o en el caso de WebGL, dibujar el píxel en el lienzo) y almacenar el valor Z como el nuevo valor de profundidad.
Si el valor de Z es mayor que el valor de profundidad almacenado, entonces se considera que está "detrás" de lo que ya se haya dibujado, y el píxel se descarta.
[1] La conversión real utiliza la configuración de gl.viewport para convertir las coordenadas del dispositivo normalizadas a píxeles.
[2] En realidad, se escala a la configuración de gl.depthRange . Por defecto son 0 a 1.
[3] Suponiendo que tienes un búfer de profundidad y que has activado las pruebas de profundidad con gl.enable(gl.DEPTH_TEST) .
[4] Puedes configurar cómo se comparan los valores de Z con gl.depthFunc
Estoy buscando una comprensión profunda de cómo funciona WebGL. Estoy deseando adquirir conocimiento a un nivel que a la mayoría de las personas no les importa, porque el conocimiento no es necesario para el programador de WebGL promedio. Por ejemplo, ¿qué papel desempeña cada parte (navegador, controlador de gráficos, etc.) del sistema de renderizado total para obtener una imagen en la pantalla? ¿Cada navegador tiene que crear un motor / entorno javascript / html para ejecutar WebGL en el navegador? ¿Por qué Chrome es la cabeza de todos los demás en cuanto a ser compatible con WebGL?
Entonces, ¿cuáles son algunos buenos recursos para empezar? La especificación de kronos es algo deficiente (por lo que vi navegando por unos minutos) para lo que estoy buscando. Estoy deseando sobre todo cómo se logra / implementa esto en los navegadores y qué más necesita cambiar en su sistema para hacerlo posible.
Yo leería estos artículos
http://webglfundamentals.org/webgl/lessons/webgl-how-it-works.html
Suponiendo que esos artículos son útiles, el resto de la imagen es que WebGL se ejecuta en un navegador. Representa a una etiqueta de lienzo. Puede pensar en una etiqueta de lienzo como una etiqueta img, excepto que utiliza la API de WebGL para generar una imagen en lugar de descargarla.
Al igual que otras etiquetas HTML5, la etiqueta de lienzo se puede diseñar con CSS, debajo o sobre otras partes de la página. Está compuesto (mezclado) con otras partes de la página. Ser transformado, rotado, escalado por CSS junto con otras partes de la página. Esa es una gran diferencia de OpenGL o OpenGL ES.