33bits

Versión completa: Explicaciones de efectos gráficos, incluido megatexturing
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
He encontrado una web interesantísima en la que explican efectos gráficos.

Por si os interesa, el megatexture va a ser un estandar porque lo incluye DX 11.2 con los tiled resources, y las gpus de ps4 y one lo soportan directamente por hardware, con lo que amd llama "partial resident textures". Todo esto al fin y al cabo es lo mismo, memoria virtual para texturas dejando la mayoria en una memoria mas lenta (disco duro) y las de uso inmediato en una memoria mas rapida, lo que deja en la practica mucho mas espacio de memoria para texturas siendo estas mucho mas pesadas, de mayor resolucion y menor compresión.
Ademas ayudaba a alcanzar 60 fps en consolas porque se hacen muy pocos accesos a ram para texturizar, la mayoria de los fotogramas solo con 3 llamadas a ram, lo que ahorra mucha latencia.

Ademas artisticamente en rage se usó para hacer cada metro cuadrado del mundo único, y mejoraba la productividad al hacerlo porque los grafistas pintaban a su aire el terreno sin estorbar a nadie.

He aquí la web:

http://sabia.tic.udc.es/gc/Contenidos%20...hp?page=32


Y aqui habla de cell shading


http://sabia.tic.udc.es/gc/Contenidos%20...hp?page=52

Tambien hay otro apartado que habla de raytracing...


Unreal engine 3:


http://sabia.tic.udc.es/gc/Contenidos%20...ne%203.htm


Otros motores:


http://sabia.tic.udc.es/gc/Contenidos%20...index.html


http://sabia.tic.udc.es/gc/Contenidos%20...index.html

Corona Radiata

Woah, buena info.

Gracias.

Muy interesante este "árbol genealógico":

[Imagen: quake1_4.jpg]
De nada hombre  mola


Cita:Como se ha visto, el método de Gouraud no aporta resultados demasiado bueno, pero es eficiente. El motor de Quake busca más calidad en la representación de la escena, pero el hardware de la época no se podía permitir utilizar métodos más costosos de iluminación para procesar toda la escena, por lo que se optó por utilizar Gouraud sólo para iluminar las entidades móviles, ya que consistían en pequeños triángulos siempre en movimiento, lo que que permitía esconder los relativamente pequeños errores de iluminación.

Sin embargo, para las entidades inmóviles, a Carmack se le ocurrió un método diferente: desacoplar iluminación y rasterización. En un rasterizador tradicional de Gourad, hay un paso previo de pre-proceso off-line en el que la base de datos del mundo se construye, y durante la que se calculan los valores de la iluminación para cada vértice. En tiempo de ejecución, si se necesita iluminación dinámica se modifican estos valores de iluminación, y entonces se aplica el método de Gouraud.

En Quake, el pre-proceso es diferente: añade un paso extra de renderización, en el que se utiliza un lightmap. Un lightmap es una estructura de datos de luz en 3D que contiene el brillo de las superficies de un videojuego. Los lightmaps son preprocesados y se aplican a objetos estáticos.

Quake fue el primer juego en los que se emplearon para optimizar el render y evitar que los pisos se viesen distorsionados, así se solucionaba el problema de shimmering de Gouraud Shading, utilizado hasta el momento para paredes y pisos.

Los métodos mas comunes de lightmapping son para preprocesar la iluminación de vértices usando la distancia de cada uno de ellos a la fuente de luz, o usando multitexturing para aplicar una segunda textura que contenga los datos lumel.


En la creación de lightmaps, se puede utilizar cualquier modelo de iluminación, puesto que la iluminación se preprocesa completamente y el funcionamiento en tiempo real no es siempre una necesidad. Tradicionalmente se utiliza radiosity, pero los juegos utilizan modelos más directos de iluminación. En todos los casos, las sombras suaves para geometrías estáticas son posibles si un simple test de obstrucción (como ray-tracing) determina que luxels son visibles a la luz. Sin embargo, la suavidad actual de las sombras es determinada por como el motor interpola los datos del lumel a través de una superficie, y puede dar lugar a un look pixelado si los luxels son demasiado grandes.

Los lightmaps se pueden calcular también en tiempo real, para efectos de iluminación (coloreado) de alta calidad que no son propensos a los defectos de Gouraud shading, aunque la creación de la sombra se deberá hacer utilizando algún otro método, como ray-tracing en tiempo real siguen siendo demasiado lentos para realizarse en el hardware moderno en la mayoría de motores 3D.


Los lightmaps se escalan utilizando luxels: cuanto más pequeños sean estos, más alta será la resolución (y calidad) pero esto depende del coste de procesado. Por ejemplo, una escala de 32 luxels por unidad de mundo puede dar peores resultados que un lightmap escalado a 16 luxels por unidad de mundo, aunque puede mejorar la ejecución in-game. De lo anterior, se pone en evidencia la importancia del compromiso funcionamiento-calidad. Si una escala pequeña de luxels por unidad de mundo se fija frecuentemente, el juego puede sufrir de lag. El tamaño de luxel se puede limitar, también, por la cantidad de espacio del almacenamiento en discos o de tiempo de la transferencia directa (para el mapa) o de memoria de la textura disponible, aunque algunos juegos procuran embalar múltiples lightmaps juntos para evitar estas limitaciones.

Surface caching

Surface caching fue una técnica inventada por Carmack para la iluminación basada en superficie y utilizada en Quake por primera vez. Básicamente consiste en que si una superficie iba a ser visible en el próximo frame, sería reutilizada, en lugar de reprocesada.



Radiosidad precalculada en Quake 2

[Imagen: quake2_2.th.jpg]



y ademas soluciona los tirones de quake 1:

Cita:Siempre ha sido un problema para Quake poner una puerta ante un área compleja pues hace que la escena funcione lentamente, a diferencia de Doom. En glquake se hizo perceptiblemente más lento la aproximación a la puerta debido al giro en descubierto. Relacionado con esto, existía el problema de que los monstruos escuchaban los sonidos a través de las puertas aunque estas estuviesen cerradas. Todo ello era debido a que el mecanismo de desecho utilizado por Quake, el PVS (Potentially Visible Set), conocía cualquier cosa que se pudiese ver potencialmente desde la posición actual. En el caso de la puerta esto se debe, a que aunque la puerta esté cerrada, el PVS también contiene todo lo que se podría ver si la puerta estuviese abierta.

Quake II ahora permite recortar grandes cantidades de mapa con independencia al PVS. Un mapa ahora es dividido en áreas mediante entidades ÔÇ£areaportalÔÇØ, normalmente situados en los frames de las puertas.