Effective Classifiers for Text Classification

Inicialmente se realiza una operación de frustum culling sobre todos los objetos de la escena. Debido a que la arquitectura de software se apoya en la programación orientada a datos resulta más eficiente realizar una técnica de fuerza bruta (Collin, 2011) que complejos algoritmos como el propuesto en (Bittner, Mattausch, & Wimmer, 2009). Además, se consideró implementar un esquema eficiente de occlusion culling (Collin, 2011; Valient, Practical Occlusion Culling in Killzone 3, 2011), pero esta tarea no se llevó a cabo porque era muy compleja debido a que el frustum culling realiza gran parte del descarte de objetos no visibles, el Z-Buffer previamente generado permite evitar el procesamiento de los fragmentos no visibles y las técnicas de occlusion culling no son completamente automáticas y pueden requerir tareas de ajuste manuales en la etapa de producción.

La etapa de G-Buffer calcula y almacena el mapa de profundidad, el mapa de normales y el valor de poder especular (glossiness) del material del objeto. XNA 4.0 estipula que un Z-Buffer debe estar asociado a un render target (o varios en configuración múltiple) y esta asociación no puede ser alterada, por lo que resulta necesario copiar la información de profundidad del Z-Buffer en un render target dedicado que puede ser accedido en otras etapas del pipeline; esto impide aprovechar la posibilidad de utilizar el contenido de un Z-buffer en etapas posteriores, una funcionalidad implementada a partir del hardware con soporte para

shader model4 o superior (Thibieroz N. , Ultimate Graphics Performance for DirectX 10 Hardware, 2008). Si bien con este esquema es posible almacenar la información de profundidad en el espacio lineal, lo que simplifica la manipulación de estos valores, se debe utilizar un buffer extra que típicamente requiere entre 24 y 32 bits por pixel; a esto se le debe sumar una pérdida de eficiencia por escribir un buffer extra y la posibilidad de prescindir de alguna optimización por hardware relacionada con el almacenamiento u operación del Z-Buffer. El tamaño de la EDRAM de la Xbox 360 impone indirectamente restricciones en la cantidad de información que puede ser almacenada en el G-Buffer, por lo que, por ejemplo, anexar la información de albedo de los objetos visibles por la cámara podría provocar la ejecución de una operación de predicatedtiling y, por consiguiente, una disminución de la performance.

Figura 8-2 Capturas de pantalla utilizando el framework. La primera imagen calcula sólo iluminación local, la segunda incorpora iluminación ambiental por armónicos esféricos y la última incluye además oclusión ambiental en espacio de la pantalla.

En la implementación realizada se almacena la información de profundidad en un canal de 32 bits, pero se analizó almacenar la información de profundidad en tres canales de 8 bits y utilizar los 8 restante para una máscara que permita mantener y mezclar dos luces ambientales. Típicamente esta información se almacena en el Z-Buffer, el cual tiene operaciones por hardware para almacenar y leer eficientemente los valores de profundidad y operaciones esténcil que permiten la generación de la máscara de forma sencilla y eficiente. Asimismo se planteó como alternativa realizar una Z-Pre Pass, para generar el mapa de profundidad por separado y disponer información temprana para descartar fragmentos en el G-Buffer, reduciendo el tamaño de éste a expensas de procesar una vez más cada uno de los vértices de los objetos opacos renderizados. Se generó un shader que lee información de un mapa de profundidad y a partir de éste genera un Z-Buffer; hasta el momento no se pudo realizar una prueba que evalúe el costo de separar en dos etapas la generación del G-Buffer.

El mapa de normales se almacena utilizando el método de compresión best-fit normals (Kaplanyan A. , CryENGINE 3: Reaching the Speed of Light, 2010) que permite almacenar esta información en tan solo 24 bits con una precisión aceptable y que solo requiere una operación de normalización para su descompresión. Los 8 bits restantes se utilizan para almacenar el poder especular y se comprimen utilizando el método propuesto en (Valient, Deferred Rendering in Killzone 2, 2007).

Como trabajo futuro se plantea almacenar adicionalmente en el G-Buffer el color albedo de las superficies, lo que permitiría adaptar algoritmos de iluminación global dinámicos; debido a que es deseable evitar el predicated-tiling que realiza la Xbox 360 cuando la EDRAM no puede contener los buffers, se deberá desacoplar previamente la generación del mapa de profundidad del G-Buffer, aprovechando en el proceso la posibilidad de hacer un Z Pre-pass.

En la etapa light pre-pass, se renderizan las luces utilizando volúmenes apropiados y con la posibilidad de utilizar volúmenes definidos por el usuario para evitar light bleeding. Además, se crean máscaras utilizando el Z-Buffer junto con operaciones esténcil para evitar la generación de fragmentos innecesarios. Como se introdujo anteriormente, XNA 4.0 no permite desasociar el Z-Buffer del G-Buffer, pero es posible recrearlo utilizando un shader de espacio de pantalla que utiliza la información de profundidad del G- Buffer. En la implementación realizada en el framework se decidió usar la versión inversa del esquema de renderizado de luces (sección 7.3.1), en la que el caso especial se encuentra cuando se intercepta el plano lejano de la cámara. De esta manera se eliminan los casos especiales, a costa de realizar dos pasadas por luz cuando la luz intercepta la cámara, momento en el cual típicamente el radio de influencia de la luz cubre la mayor parte del espacio de pantalla visible.

El framework soporta mapas de sombras para luces direccionales y spot, cascaded shadow maps para luces direccionales y mapas de sombras cúbicas para luces puntuales. Las sombras se calculan de forma diferida, lo que permite aplicar filtros en espacio de pantalla a un costo computacional menor. Es posible que la técnica de reducción de fragmentos antes propuesta haga atractiva el realizar el filtrado directamente en el shader de iluminación de la luz; sin embargo, dado que la generación del mapa de sombras se descarta para luces puntuales y spot lejanas y dado que el resto de las luces cubren un área significativa en espacio de pantalla se decidió mantener el esquema diferido por simplicidad y eficiencia. En esta etapa también se ejecutan, de forma diferida, los algoritmos de iluminación global de tiempo real.

En la etapa de renderizado de objetos se renderizan los objetos opacos utilizando la información de iluminación de la etapa anterior y ejecutando uno de los BRDFs implementados. La variedad de BRDF está limitada por la cantidad de información de iluminación disponible derivada de la etapa anterior, aunque puede ser sorteada realizando el cálculo del BRDF en esquema forward. Luego se renderiza el cielo (este orden de renderizado permite descartar fragmentos innecesarios), los sistemas de partículas, los objetos transparentes (en esquema forward), las líneas, los textos y los sprites en el espacio del mundo y en el espacio lineal. El sistema de partículas tiene varios parámetros de control (duración, dirección de gravedad, tamaño inicial y final, etc.), permite renderizar partículas duras o suaves (Rosado, 2009) y texturas animadas (en esquema de mosaicos).

La etapa final de post procesamiento realiza la calibración del color, la adaptación dinámica de la exposición, el mapeo tonal, bloom, color grading, ajuste de niveles de brillo y film grain. También ejecuta un filtro MLAA en espacio de pantalla que reduce el aliasing de la imagen producida y que puede utilizar la información de profundidad, la información de color o ambas. Por último se renderizan las líneas, los textos y los sprites en el espacio de mundo y en el espacio de color gamma y se renderizan las líneas, los textos y los sprites en el espacio de la pantalla y en el espacio de color gamma.