Cómo obtener la mayor calidad gráfica en tu simulador

[PA_Willy]

Antes que nada, ten presente al leer esto que no podrás mover el juego a aceptables FPS con según qué configuración y en función de tu hardware, filtros, resolución y opciones activadas. El propósito de este tutorial es poner de manifiesto cómo obtener el máximo de tu juego en cuestión gráfica. Luego será decisión de cada uno usar todos o alguno de los parámetros indicados.

1.- Resolución:

Asumiendo que tienes un monitor TFT, debes volar siempre a resolución nativa para obtener los mejores resultados. Dicho lo anterior, es universalmente aceptado que en este simulador los contactos se verán menos o no se verán cuanto mayor sea la resolución utilizada. Este es un problema con el LOD del juego, que a ciertas distancias utiliza un pixel para representar el aparato. Lógicamente un pixel entre 1920*1200 es mucho más difícil de apreciar que ese mismo pixel entre 1024*768. Pero recuerda, aquí hablamos de calidad gráfica.


Para modificar la resolución en tu simulador, sólo tienes que editar unas líneas en tu conf.ini:

[window]
width=2560
height=1600
ColourBits=32
DepthBits=24
StencilBits=8
ChangeScreenRes=1
FullScreen=1
DrawIfNotFocused=0
EnableResize=0
EnableClose=1
SaveAspect=0
Use3Renders=0

Las líneasen negrita son las que definen la resolución. Simplemente introduce ahí tus valores de resolución nativa.

La línea en rojo es necesaria si tu monitor es panorámico (16:9 ó 16:10). Si es 4:3, el valor correcto es "1".

Veremos más adelante que hay mods que además nos permiten sacar más partido a la resolución panorámica.


2.- Driver gráfico (sólo para gráficas Nvidia).

Asumid que no siempre el último driver gráfico es el mejor. A menudo lo es, pero no siempre es así. Yo suelo hacer pruebas con uno u otro driver y compruebo la calidad gráfica y las prestaciones (FPS). Si tienes un sistema dual (multiGPU) además tendrás el hándicap de hallar el driver que más jugo saque a tu potencia gráfica instalada y menos microstuttering genere. El microstuttering se produce cuando varias GPU,s trabajan conjuntamente para renderizar frames. En IL2 si tienes un sistema SLI debes asegurarte de que corra en SFR (Split Frame Rendering). Una GPU renderiza la parte superior de cada frame y la otra la mitad inferior. Si lo corres en AFR (Alternate Frame Rendering) que es lo que recomienda Nvidia, conseguirás un uso de hasta el 99% de cada GPU y gran cantidad de FPS, pero sufrirás microstuttering en función de los filtros empleados, de si la sincronización vertical está activada y del triple buffer activado o no). Mi recomendación: usa SFR. El sistema Crossfire (ATI/AMD) no funciona en IL2, así que lo anterior sólo es válido para Nvidia.

Mis drivers favoritos a fecha actual, son los dirigidos a OGL Developers (ten presente que IL2 usa la API OpenGL) que puedes hallar aquí (elige según tu SO):

OGL 280.36

win7/vista x32

win7/vista x64

winxp x32

winxp x64

Recordad que antes de instalar un nuevo driver gráfico hay que desinstalar el anterior y usar un programa como Driver Sweeper para borrar cualquier rastro de él en el sistema. Y por supuesto nos tocará reiniciar el sistema al menos tres veces (al desinstalar, al limpiar con Driver Sweeper y tras terminar de instalar el nuevo driver).

Para sacar todo el partido posible al driver (y por ende al simulador), recomiendo instalar Nvidia Inspector. Esta sencilla aplicación es imprescindible para los propietarios de gráficas Nvidia. Permite realizar todo lo que permite el panel de control del driver y mucho más.

Todas las opciones que indique las referiré a este programa, aunque para algunas de ellas podréis utilizar el panel de control (para muchas otras no).


3.- Opciones de configuración a través de Nvidia Inspector.

En primer lugar deberíais enredar un poco con el programa para familiarizaros con él. Es muy sencillo. Recordad que hay que aplicar los cambios para que surtan efecto y que hay que lanzar el juego de nuevo tras cada cambio realizado.

Estas son las opciones con que jugar:



- En primer lugar, la variable "Antialiasing Compatibility" es la que le dice al driver como aplicar el filtro antialiasing en el juego. Ocurre en IL2 que cuando activas el antialiasing, hay partes de la escena a las que no se le aplica, como por ejemplo algunos objetos distantes, las costas, cables, etc. Este modo de compatibilidad le dice que debe aplicar el filtro a todos los objetos que sean renderizados. No es perfecto, pero trabaja más eficientemente.

- El filtro antialiasing es fundamental en el juego. Como veis en la imagen, el máximo es x32S, lo que te otorga una gran calidad. Pero es muy difícil por no decir imposible moverlo en estas circunstancias a altas resoluciones y con frames aceptables. Lo que se le dice al driver es que renderice la imagen al doble de la resolución establecida para el juego y que luego la presente en la resolución demandada. Es decir, si vuelas a 1920*1080, por ejemplo, con este filtro, además de aplicar un multisampling de x8, aplicas un supersampling de 2x2. La gráfica renderizará la imagen al doble de la resolución, es decir, 3840*2060 pixels, aunque tu la verás a 1920*1080. En ese ínterin, los dientes de sierra (aliasing) dejan de ser perceptibles. Es algo parecido al downsampling, que si no conocéis, puedo explicar algún día.

Hay un filtro supersampling gemelo (x16S) que cuenta únicamente con 4 multisampling. Entre éste y el anterior no hay diferencias visibles (porque el supersampling es idéntico, y es este filtro el que en realidad da esa calidad a la escena).

Veréis que no podéis aplicar ninguna clase de filtro supersampling a través del panel de control original de Nvidia. Son opciones ocultas para los que tendremos que trabajar con Nvidia Inspector (con drivers anteriores al 250.XX podíamos también emplear el viejo nHancer).

Como obviamente es muy difícil poder volar en esta configuración supersampling x32S, os recomiendo algo más "realista": 8xS, que básicamente combina un filtro multisampling x4 con otro supersampling de 1x2 (sólo duplica el renderizado en la altura). Los resultados son formidables. Hace falta potencia de hardware suficiente.

Cualquier filtro menor que estos, supone un multisampling. Este sistema de filtrado es muy eficiente y consume muchísimos menos recursos, pero no permite la calidad gráfica del supersampling ni de lejos. En todo caso, a mi juicio el mínimo antialiasing aceptable para disfrutar de nuestro simulador es x4 (MS). Se que hay gente que vuela incluso sin AA, pero yo quiero disfrutar gráficamente del vuelo.

[continuará]

[PA_Steiner]

Sin comentarios Willy. Me encantan estos artículos

[Asis]

Primeros retoques y parece que va mejor. Gracias Willy

[PA_Willy]

Continuamos.

La variable antialiasing transparency hace referencia al alisado de bordes en texturas transparentes, como por ejemplo, las cabinas, ventanillas, árboles (entre las hojas), etc. En el clásico panel de control del driver podemos activarlo como Multisampling o Supersampling, o simplemente desactivarlo. En Nvidia Inspector nos permitirá a su vez definir el nivel de supersampling (hasta x8). Para obtener un excelente alisado de bordes en texturas transparentes hemos de elegir Supersampling. Cualquier valor superior (x2, x4 ó x8) consumirá recursos desproporcionados para los resultados. La combinación de este filtro con el antialiasing del que hablaba en el post anterior (x8S) da una calidad excelente.

- El anisotrópico. Tiene truco en IL2, porque a diferencia de otros juegos, en este sí consume muchos recursos. El juego, por defecto, permite aplicar (a través de su propio motor) un filtro aniso de x4. Basta con marcar en el conf.ini los siguientes valores resaltados:

[Render_OpenGL]
TexQual=3
TexMipFilter=3
TexCompress=0
TexFlags.UseDither=0
TexFlags.UseAlpha=0
TexFlags.UseIndex=0
TexFlags.PolygonStipple=0
TexFlags.UseClampedSprites=0
TexFlags.DrawLandByTriangles=0
TexFlags.UseVertexArrays=1
TexFlags.DisableAPIExtensions=0
TexFlags.ARBMultitextureExt=1
TexFlags.TexEnvCombineExt=1
TexFlags.SecondaryColorExt=1
TexFlags.VertexArrayExt=1
TexFlags.ClipHintExt=1
TexFlags.UsePaletteExt=1
TexFlags.TexAnisotropicExt=1
TexFlags.TexCompressARBExt=0

TexFlags.TexEnvCombine4NV=1
TexFlags.TexEnvCombineDot3=1
TexFlags.DepthClampNV=1
TexFlags.SeparateSpecular=1
TexFlags.TextureShaderNV=1

El juego lo aplica, pero en un valor bastante bajo. A través de Nvidia Inspector (o del panel de control del driver) podemos decirle que, a pesar de la configuración interna del juego, el driver aplique su propio anisotrópico (echad un vistazo a la captura de Nvidia Inspector, veréis que está en "Definido por el usuario" y con valor "X16"). Pero, al simulador no le gusta esto (para eso tiene su propio aniso). Consume recursos y con valores de water=4 genera stuttering a baja cota. Podéis comprobarlo. La solución más aceptable es dejar el water=2 en vez de "4". Así podemos activar el aniso sin demasiados problemas.

El anisotrópico revitaliza todas las texturas del juego, sobre todo las del terreno (porque le juego ya las aplica en los modelos de aviones). Pero además tiene otro efecto interesante: permite distinguir más nítidamente los contactos enemigos que vuelan bajo nosotros con el terreno de fondo. A menudo no podemos verlos. El aniso ayuda en ese sentido.

- LOD bias. Este valor se refiere a las texturas, su "relieve" y nitidez. A través de Nvidia Inspector podemos establecerlo en -3 has +3, pasando por muchos valores intermedios. Un valor por debajo de 0 hace parecer las texturas más vivas, más nítidas y más detalladas (algo parecido a lo que hace al anisotrópico), pero a su vez genera dientes de sierra en los bordes de dichas texturas cuando hay movimiento. Este es el mayor inconveniente con esta variable. Hay juegos que fueron diseñados con un valor negativo buscando ese efecto. No obstante, con el siguiente parámetro podemos bloquearlo para evitar ese aliasing extra:

- Negative LOD bias. Con dos valores "Allow" y "Clamp". Si establecemos "Allow", le decimos al driver que permita al juego funcionar de acuerdo a su diseño, incluso aunque use valores negativos de LOD BIas. Si lo dejamos en "Clamp", le decimos que no permita valores negativos (eliminará cualquier aliasing extra de las texturas). Como hemos visto que el filtrado anisotrópico ya da una nitidez y relieve semejante a las texturas, se suele recomendar dejar este valor en "Clamp" si hemos activado el AF (Anisotropic Filter). Pero podéis experimentar con ello. Yo lo hice por aquí.

- Calidad de las texturas: como sabéis, el driver puede dejar las texturas en su tamaño original o bien aplicar algún algoritmo de compresión para reducir la carga gráfica. La única recomendación posible es dejar este valor en "High Quality". En realidad se pierde poco dejándolo en "Quality", pero recordad que estamos buscando al máxima calidad gráfica dentro de lo posible.

Además tenéis que tener presente que el motor del juego ya trae compresión de texturas. Para desactivarla hay que dejar los valores de conf.ini como sigue (resaltados):

[Render_OpenGL]
TexQual=3
TexMipFilter=3
TexCompress=0
TexFlags.UseDither=0
TexFlags.UseAlpha=0
TexFlags.UseIndex=0
TexFlags.PolygonStipple=0
TexFlags.UseClampedSprites=0
TexFlags.DrawLandByTriangles=0
TexFlags.UseVertexArrays=1
TexFlags.DisableAPIExtensions=0
TexFlags.ARBMultitextureExt=1
TexFlags.TexEnvCombineExt=1
TexFlags.SecondaryColorExt=1
TexFlags.VertexArrayExt=1
TexFlags.ClipHintExt=1
TexFlags.UsePaletteExt=1
TexFlags.TexAnisotropicExt=1
TexFlags.TexCompressARBExt=0

TexFlags.TexEnvCombine4NV=1
TexFlags.TexEnvCombineDot3=1
TexFlags.DepthClampNV=1
TexFlags.SeparateSpecular=1
TexFlags.TextureShaderNV=1

Si por cantidad de VRAM instalada o por problemas con el juego os veis obligados a activar la compresión, es mejor activarla desde el motor del juego que desde el driver gráfico. Y no recomiendo menos de S3TC. Para ello debéis cambiar los valores anteriores a:

TexCompress=2

TexFlags.TexCompressARBExt=1

Hay que hacerlo con ambos valores o no funcionará.

[continuará]

[ton414]

Gracias Willy, muy buena idea este tutorial.
En mi caso, como mi gráfica es una GTS 250 aún utilizo los drivers 197.45 y nHancer.

[PA_TJ17]

Gracias Willy, necesitaba este tutorial para mejorar un poco más mi grafica.

Lo probaré este finde.

Saludos.

[PA_Willy]

Continúo.

- Triple buffer y Vsync. Ambos factores van de la mano. En vuelo no es imprescindible tener activada la sincronización vertical, pero a menudo eso nos producirá tearing, que es la sensación de ver fotogramas partidos o sin sincronización en pantalla. Por ejemplo, volando en cabina viras rápidamente la cabeza y ves como partes de la escena (con el bastidor de nuestra carlinga) se actualizan antes que otras, viendo fotogramas partidos en diferentes extremos/zonas de la pantalla (efecto más agudo con TrackIR). La solución pasa por habilitar la Vsync o sincronización vertical, que equipara el número de frames generados por la gráfica con los de máximo refresco de nuestro monitor. Pero dado que los valores de sincronización vertical van en escalas y no son valores contínuos, podemos encontrarnos con que en alguna ocasión en que la capacidad de renderización de la gráfica no llega a 60fps, aparezcan sólo 30fps en pantalla (auqnue la GPU era capaz de 45, por ejemplo). Para evitar estos "saltos" en la presentación de frames, existe el Triple buffer. Básicamente es una memoria a muy corto plazo que permite almacenar unos pocos frames por delante de los presentados en pantalla, de forma que la GPU renderiza a una velocidad y presenta a otra. Ese buffer va entregando las imágenes sincronizadas mientras la GPU va renderizando las siguientes y permite así valores intermedios de presentación de frames diferentes a los valores fijos de Vsync.

El triple buffer es para aplicaciones OpenGL. No funciona nativamente en DirectX (aplican un double buffer). Para estas últimas aplicaciones existe un programita llamado D3DOverrider que permite el triple buffer.

Ahora bien, todo tiene un precio: el input lag. Dado que las imágenes que vemos en pantalla no son las últimas renderizadas sino unas anteriores almacenadas en el buffer, nuestra respuesta a los mandos ante lo que vemos en pantalla está retrasada respecto a lo que realmente ocurre en el simulador. Digamos que ralentiza durante unas décimas de segundo (que pueden ser vitales) nuestra respuesta. También se nota en cualquier periférico de entrada como nuestros joysticks, pero sobre todo se nota en el deslizamiento del ratón por la pantalla. Por eso los pilotos más competitivos no vuelan con Vsync o triple buffer.

¿Hay solución?

Sí. Decirle a la GPU que no renderice adelantadamente ningún frame. Eso se hace mediante otro parámetro que es "Minimum prerendered frames" y que podéis ver también en mi captura de Nvidia Inspector. Si lo dejáis en cero, teóricamente el buffer trabaja únicamente con el frame anterior al actualmente generado. Basta para eliminar el tearing porque nos permite activar el Vsync y el triple buffer. Leeréis en algunos sitios que el Minimum prerendered frames no funciona en OGL. Sin embargo yo creo que sí lo hace en IL2. Es relativamente sencillo comprobarlo. Juega con los valores de 0 a 8 y comprueba la carga de la GPU, la carga de VRAM (el buffer ocupa espacio) y el input lag.

Otra forma más ineficiente de reducir el tearing (que no eliminarlo) sin tener que activar Vsync y triple buffer, es utilizar un software limitador de FPS como éste que ya os recomendé. Simplemente ordena al driver de la gráfica que no renderice más frames que el límite que establezcais. Y funciona.

Cuando con un método u otro le ordenas a la GPU que renderice menos frames de los que podría, también la descargas de trabajo y de temperatura. Es fácilmente observable monitorizando estos datos como hago yo en un segundo monitor o en una pantalla LCD con el software adecuado (MSI Afterburner o AIDA64).

[Continuará]

[PA_Arba]

Muchas gracias. No no tiene precio

[PA_Arba]

Tenía una pequeña heridita en la punta de la nariz y en la barbilla; ya no los tengo al cambiar algún valor y eliminar los dientes de sierra en cabina
Gracias

[PA_Willy]

Continúo.

4. Sistemas SLI (multiGPU de Nvidia).

Sólo para NVidia, puesto que el Crossfire de ATI/AMD no es compatible con este título.

Si tienes un SLI hay varias cosas que debes saber. Hay tres modos de renderizar cooperativamente para tus GPU,s:

--- AFR (Alternate Frame Rendering):una GPU renderiza un frame y la otra el siguiente. Es el método estándar y más compatible. Cada gráfica tiene una similar carga de proceso que puede observarse en % de trabajo vía software como MSI Afterburner o AIDA64.
--- AFR2: es una segunda alternativa al anterior. Se utiliza en aquellos juegos no especialmente compatibles con SLI pero que en este segundo método correrán bastante bien en dos GPU,s o más.
--- SFR: Split Frame Rendering. Cada GPU renderiza la mitad de cada frame (una la parte superior y otra la inferior).

El perfil oficial de Nvidia para el juego ha variado con el tiempo. Inicialmente en sus drivers era "Single GPU", o lo que es lo mismo, desactivar el SLI y correr la aplicación en una sola GPU. Posteriormente el perfil oficial ha cambiado a AFR2. Sin embargo, mi recomendación es que useis SFR. Explico por qué:

- En el juego las columnas de humo proyectan sombras. Tanto de explosiones como de barcos, etc. Con AFR y AFR2 verás un molesto flickering (parpadeo rítmico y continuado) en el lugar de esas sombras. Esto ocurre porque una GPU renderiza bien el efecto y la otra no. Ese parpadeo viene de que el frame generado por ambas GPU,s es incosistente: una genera la sombra y la otra no. Y como cada una renderiza un frame consecutivo, el resultado es el parpadeo descrito.
- En AFR/AFR2 se produce microstuttering. Sobre todo cuando obligas a grandes esfuerzos vía antialiasing u otros filtros. Es molesto. También ocurre en momentos de intensa carga gráfica, como combates entre nubes densas, etc. Y el problema se agrava cuando introduces Vsync y triple buffer.
- En SFR se obtiene menor rendimiento MultiGPU por la sencilla razón de que una gráfica renderiza la parte superior de cada escena que suele corresponderse con el cielo, y la segunda renderiza nuestro avión, el terreno y todos lo objetos que vemos abajo (mucha mayor carga gráfica). Implica una diferencia de porcentaje de trabajo de cada GPU (no renderizan lo mismo y no se esfuerzan lo mismo). También una diferente temperatura (lógicamente la que más trabaja más se calienta). Sin embargo, es el sistema que otorga mayor suavidad de vuelo y es totalmente compatible con Vsync y triple buffer.

Para decirle al driver que renderice en SFR tienes que mirar la captura de mis mensajes anteriores, donde verás señalado con una flecha verde el valor de Nvidia Inspector correspondiente.

En algunos casos, con algunos drivers antiguos, en SFR y teniendo desactivado el Vsync, se ve una molesta línea horizontal en la pantalla que parte el frame en dos. Es tearing. Pero provocado por el SFR. La línea que vemos es la que limita la mitad del frame que renderiza cada GPU. Actualmente no ocurre, y menos con Vsync.

En SFR tampoco hay problema alguno con las sombras proyectadas del humo. Realmente el único inconveniente es que no sacamos el 100% de rendimiento al sistema, dado que las GPU,s no se reparten equitativamente el esfuerzo. Con AFR/AFR2 podemos garantizarnos casi el doble de frames en situaciones de enorme carga gráfica. En SFR podemos ganar entre un 20 y un 60% de rendimiento extra gracias a la segunda GPU.

Por último, recordad que los sistemas multiGPU son enormemente dependientes de CPU. Por tanto necesitaréis la CPU más rápida que podais permitiros y/o un alto nivel de overclock al procesador. Además es interesante que los usuarios de Windows 7 64bits, sepais que deberiais dejar al SO gestionar la carga de CPU y no limitarla vía sección rts en el conf.ini. Hace tiempo y en sistemas operativos anteriores, sobre todo de 32bits, se recomendaba que IL2 corriera en un único core, para lo cual se introducía en el conf.ini el correspondiente valor (ver este hilo).

Actualmente, a los usuarios de W7 64bits les recomiendo encarecidamente que anulen ese valor del conf.ini y dejen al SO que trabaje a su modo. Tengo comprobado que se obtiene mayor rendimiento y ya no se sufren los microparones de hace años, cuando el forzar procesamiento multi-hilo no daba mayor rendimiento y sí más quebraderos de cabeza. Para conseguir lo que recomiendo, navegad por vuestro conf.ini hasta la sección [rts] y dejadla como sigue:

[rts]
;ProcessAffinityMask=X

Como véis, hay un ";" delante de la línea. Es lo que impide que sea el juego el que diga al SO en cuantos hilos/cores correr. Así dejamos al muy eficiente SO de 64bits que lo corra en multicore. Donde veis la "X" irá un valor numérico. El que teniais configurado antes. Para el listado total de los posibles valores, echad un vistazo al hilo antes precitado. Pero ya os digo que recomiendo que sea el SO y no el juego quien lo gestione.

Esto lo explico en este área multiGPU porque estos sistemas entregan muchísima potencia gráfica, y a menudo el principal lastre que sufren (cuello de botella) es la CPU. Bien por frecuencia, bien por una mala gestión de su soporte multihilo.

Por último, recordaros que en SLI, tenéis que molestaros en hacer pruebas con diferentes drivers. IL2 es un juego antiguo. Normalmente el mejor driver suele coincidir con alguno de los últimos lanzados (sobre todo los dirigidos a mejorar prestaciones en OGL). Pero en función de tus gráficas, su antigüedad y del sistema en general, podrías encontrarte con que drivers más antiguos hacen un mejor trabajo.

Mi favorito para una GTX295 y para un SLI de GTX 480 es el que cito en el primer post: 280.36 (anteriormente dejé el link para descarga).

[Continuará]