El artículo que leeréis a continuación es una traducción que he realizado del siguiente artículo en inglés: edusworld.org/ew/ficheros/2006/paginasWeb/making_of_sotc.html.

Creo que es tremendamente interesante para cualquier jugador con un poco de curiosidad sobre cómo hacer las cosas. Empezamos.

Anteriormente había realizado una primera parte de la traducción. Para mayor facilidad, recopilo lo anterior y lo nuevo para tener el artículo completo traducido.

Quisiera pedir disculpas de antemano por no haber realizado antes la traducción completa, pero no ha podido ser.

Con la PlayStation 3 anunciada para la primavera de 2006, podríamos pensar que PlayStation 2 está en una situación en la que se ha alcanzado su límite. En este momento, la atención del mundo tiende a fijarse en la máquina de nueva generación, pero es realmente ahora donde toda la tecnología adquirida a lo largo del ciclo de vida de la máquina actual da sus frutos, y es el momento en el que las obras maestras aparecen.
Se podría decir que este invierno, en el que Shadow of the Colossus (en adelante SOTC) aparece, representa ese periodo de recogida de frutos para PS2.

SOTC es un buen  juego de por sí, pero es la tecnología que subyace bajo él, ejecutada sobre una PS2, la que le da la apariencia de juego next-gen.

Así que es hora de recopilar la información sobre el desarrollo de SOTC, porque hemos discutido sobre la tecnología empleada y deseamos presentarla.

Fumito Ueda: No estoy seguro desde dónde podría comenzar a hablar (riendo). El trabajo acumulado paulatinamente en SOTC, al recopilarlo definitivamente, parecía completamente natural.

Hajime Sugiyama: Me esforcé en hacer que el mundo fuese natural a la vista. No estoy seguro si lo conseguí, pero es difícil de decir, porque no parece de dibujos animados, ¿no es cierto? (risas)

Takuya Seki: Más que el programador diciendo cómo hacer las cosas, nos esforzamos

El renderizado HDR y la exposición dinámica / algoritmo tone mapping

Tras comenzar con SOTC, el primer golpe visual está en el magnífico paisaje visto desde dentro del Santuario. El escenario exterior se tiñe, visto desde el interior, de blanco, y la luz inunda la estancia a través del espacio entre los pilares que soportan el Santuario. Éste es el tan en boga renderizado HDR (High Dynamic Range, renderizado de alto rango dinámico)
Cuando sales del oscuro interior del Santuario al exterior, la escena exterior está casi completamente dibujada en blanco, que se ajusta rápidamente a su balance adecuado de brillo. Esto es el denominado Dynamic Tone Mapping , que es parte del efecto HDR.

El método en el que SOTC realiza el render HDR no es físicamente correcto, pero el algoritmo empleado funciona y crea un impresionante resultado visual.



El efecto del renderizado pseudoHDR puede verse en todo el juego. Implica que el balance del brillo se centra en el protagonista bajo el cañón y, de la misma forma, el relativamente brillante cielo tiende a representarse casi blanco.









El renderizado HDR y el Tone Mapping se explica en éste artículo sobre Half-Life 2: The Lost Coast, pero a continuación se detalla una breve pincelada sobre su funcionamiento.

Con el fin de renderizar una imagen HDR sin estar limitados por el posible rango de color de la pantalla de televisión, el renderizado HDR realiza un proceso donde el Tone Mapping se usa para conseguir el balance de brillo adecuado en la pantalla del televisor.
Originalmente, el propósito de los gráficos 3D obtenidos a través de un ordenador era conseguir una imagen cercana al mundo real. Hay una enorme variación de brillo en la realidad, desde una claridad cegadora hasta la más negra oscuridad, pero el ojo humano y la cámara se adaptan a ello ajustando la exposición, variando la velocidad de obturación de la cámara y el grado de apertura de la pupila, entre otros. En lo que atañe a los gráficos 3D, procesamos la intensidad de la luz de la realidad usando un gran rango parecido con gran precisión (renderizado HDR) , y la simulación de la cámara y del ojo se realiza a posterior, mediante el Tone Mapping.

Es dificil afrontar un renderizado con el algoritmo HDR real en tarjetas gráficas anteriores a la generación Direct X 8, que es el que usan la mayoría de las consolas actuales [DC/PS2/GC/XBOX, N. del T] debido a que renderizan sólo mediante un framebuffer de 16 millones de colores, conteniendo canales RGB de 8 bits. (Técnicamente no es imposible, pero sería demasiado lento en términos prácticos).
Debido a ello, el algoritmo pseudo-HDR se ha hecho popular en los gráficos de los juegos.

Con Xbox360 y PS3, es posible que cada canal RGB pueda tratarse en coma flotante con una precisión de 16 bit (FP16), debido a que el hardware se ha diseñado desde el principio para trabajar con renderizado HDR. Sin embargo, este no es el caso de PS2. Cuando pensamos en los gráficos de Shadow of the Colossus, el concepto del renderizado pseudo-HDR sale a la palestra.

Hablando del renderizado pseudo-HDR, el efecto destello, en el que la luz inunda las áreas colindantes durante el postprocesado de la imagen (el efecto bloom), se enfoca como un efecto de propósito general. La implementación realizada en el juego trabaja con la exposición y simulación de la pupila con el brillo adecuado, lo que no se realiza habitualmente. Además, con Shadow of the Colossus, esto se realiza de acuerdo con la escena en la que se encuentra el jugador.

Renderizado Pseudo-HDR



En la imagen puede verse cómo el exterior tiende al blanco, pero los efectos en tiempo real gradúan el brillo hasta su valor correcto. El ojo sigue ajustando…

“A decir verdad, usa los mismos principios básicos que nuestro anterior juego, “ICO”. En cierto modo, es justo decir que [SOTC] es un desarrollo de aquél”
Takuya Seki, SCE lead production department.

Con Shadow of the Colossus, el escenario se divide en cajas (cajas interruptor) que cubren todo el mapa. (en este artículo, se decide denominarlas “cajas de escena” por conveniencia), en las que se sitúa el jugador. Las cajas determinan el efecto en esa área.

En otras palabras, si volvemos al ejemplo del Santuario, “porque el interior del Santuario está siempre oscuor, cuando miras hacia el exterior brillante, parece saturado”, esto es porque la definición de la escena determina “haz esto”
“El proceso de renderizado se realiza con normalidad. Después, dependiendo del efecto de escena que se haya definido, simplemente se aplica que la luz inunde el escenario exterior” (Seki)

El algoritmo, grosso modo, puede definirse así.

1. Dibujar la vista lejana, y guardarla en el framebuffer.

2. Dibujar la escena cercana.

3. Se compone la imagen final mediante la combinación del plano cercano y el lejano. Se usan los contenidos del Z-buffer (la distancia al punto de vista) como una máscara.

4. De nuevo empleando el Z-buffer, se genera una imagen aparte de la máscara patrón.

5. Se reduce a una imagen de 64x64 pixels, usando un filtro bilineal (lo que crea una resolución ultra-baja). Esto se reutilizará en el paso 8.
6. Se combina el frame anterior (del paso 7), usando un porcentaje determinado por la caja de escena.
7. Se almacena la imagen para usarla en el paso 6
8. Se escala la imagen del paso 5 a la resolución adecuada, empleando un filtro bilineal. Por ello, se convierte en la base para el efecto bloom donde la vista lejana comienza a ganar protagonismo con respecto a la vista cercana.

9. Se combinan 7 y 8 según los parámetros fijados por la caja de escena.


Ocasionalmente, cuando el personaje pasa de un sitio brillante a un sitio oscuro (y viceversa), parece que el efecto gradualmente ajusta la escena al brillo adecuado. ¿Cómo se ha realizado este tipo de Tone Mapping dinámico?

Cuando el personaje se mueve desde el interior del santuario al exterior, debido a que ha abandonado la caja de escena del santuario, el efecto cesa de aplicarse. Esto se realiza mediante un parametro binario (1/0, encendido/apagado), pero si la escena cambiase de repente, se vería artificial. Por ello, cuando el jugador abandona la escena, hay un pequeño intervalo de tiempo en el que hay una transición al efecto de la siguiente caja de escena.

El falso Tone Mapping se realiza cambiando suavemente desde “dentro del santuario, la escena exterior es brillante” a “fuera del santuario, la escena se dibuja normalmente”

“El inconveniente del método de las cajas de escena, que hace sufrir a PS2, es que el tiempo necesario para determinar los parámetros de las cajas es muy alto. Shadow of the Colossus tiene un enorme mundo que ha sido totalmente parametrizado a mano” (Hajime Sugiyama, SCE lead production department)

Motion blur, con efecto “afterglow” y el frame rate.

En SOTC, cuando la cámara se mueve, se produce el efecto “motion blur” [desenfoque de movimiento]
El Motion Blur (que se puede realizar de distintas formas, pero con SOTC, ajustamos el fotograma actual tras realizar el renderizado del mismo, por medio de la velocidad de la cámara y, simplemente, acumulamos estas imágenes. En PS2, en dónde hay poca memoria y su acceso es lento, es una técnica realmente razonable.

Concepto del desenfoque de la cámara.


Cambiando el fotograma actual según la velocidad, se acumula debido a la trasparencia.

Dos escenas con el fotograma original y el resultado tras el desenfoque.




Además, este desenfoque por la cámara no se aplica al personaje. Si así se hiciese, el personaje se haría demasiado difuminado y vago, que no es nada bueno en términos de jugabilidad.

Pero, si observamos detenidamente, en SOTC, cuando el personaje corre, vemos que el desenfoque se aplica dependiendo de la acción. Este desenfoque se produce por distintas razones de procesamiento.

Se realiza analizando las diferencias entre las posiciones de los huesos en el fotograma actual y en el previo, y formando un polígono desde ambas. Se aplica a la imagen del personaje en el fotograma actual como si fuese una textura.

En el caso de que el jugador se haya colgado de un coloso, y el coloso realiza un gran movimiento, la vista se mueve rápidamente desde el cielo a la tierra de modo desconcertante, pero el brillo del cielo permanece fuertemente visible. Cuando el punto de vista se mueve de forma extrema, un efecto similar se produce, pero esto es cuando el ojo humano mira a una luz brillante (lo que se conoce como el fenómeno afterglow [permanencia del destello]. Debido a esto, el motion blur y el pseudo-HDR retrasa el cambio de brillo, y la imagen permanece. Es necesario implementar en el programa una orden como “si el movimiento es excesivo, haz que la cámara permanezca inmovil.” Es algo que se tiene que asumir en el juego. Es un efecto colateral inesperado del paso (6) en el proceso de ejecución del HDR.

Este efecto “afterglow” está parametrizado en cada caja de escena. En el juego se puede observar, si se hace con detenimiento, que la permanencia del destello no acontece en ciertas áreas.

Sobre la tasa de refresco, SOTC se caracteriza por tener un frame rate que varía de forma salvaje. Realmente, se incorporó la tasa de refresco variable en el diseño del juego, aumentando y disminuyendo según el nivel de carga de procesos. Aunque hay ocasiones en que se alcanzan los 60 fps, también nos encontramos con casos en los que se disminuye hasta los 15 fps, pero el desenfoque de movimiento ayuda a suavizarlo, y la sensación para el jugador de que el frame rate varía se mantiene en límites razonables.

Desenfoque: El efecto blur aparece cuando el personaje se mueve rápidamente.





Según el movimiento del coloso, cuando la vista cambia de modo violento, se produce un fuerte efecto de desenfoque en donde la imagen completa aparece descentrada. Esto mejora en gran medida el aspecto visual.



Al girar la vista, se produce un desenfoque.



Generación de sombras gracias a la técnica de autosombreado mediante plantillas de volúmenes de sombra "self-shadowing stencil shadow volume technique"

Shadow of the Colossus genera las sombras del siguiente modo.

Con este tipo de generación de sombras es muy difícil computar las sombras con contornos definidos , pero se ha logrado general que la sombra se dibuje no sólo sobre el suelo, sino también sobre el propio personaje. Por ejemplo, la sombra de un brazo del personaje principal se proyecta sobre su cuerpo. Mientras que la mayor parte de los juegos de PS2 proyectan la silueta del personaje en el entorno, las sombras en SOTC son considerablemente más detalladas.

La generación de sombras en SOTC adopta la misma técnica de volúmenes de sombra que DOOM3 u otros juegos.


Con esta técnica, en primer lugar, se extrusiona el contorno del objeto 3D para formar el contorno, según la dirección de la luz, formando un área cerrada (volumen de sombra). La información sobre la profudidad de la escena desde la cámara es usa en cada pixel, para juzgar si ese pixel en concreto está dentro o fuera de dicho volumen. Los resultados se guardan en un buffer específico. Al finalizar, con esa plantilla de sombra, se realiza el proceso de aplicar el "color de sombra" a la imagen final.

En esta imagen se comprueba la visualización de la sombra en una escena.

La extrusión del contorno ser realiza mediante el VU1 de la CPU de PS2


La calidad de la sombra obtenida a partir de esta técnica es alta, aunque bastante costosa si hay mucho que dibujar: se tienen que dibujar muchos más polígonos de los que se ven en realidad. Afortunadamente, debido a que SOTC se centra, principalmente, alrededor del héroe, el caballo y el coloso, en lo que se refiere a las sombras, Seki nos dice que es posible limitar las sombras a lo que realmente se necesita.

Esta misma técnica de sombreado ya se empleó en Ico, aunque sólo se usaba para los personajes de Ico y Yorda.

En la generación del volumen de sombras, se determina el contorno del personaje 3D desde la fuente de luz y se extrusiona para formar una región sombreada, mediante el empleo del VU1 de la CPU de PS2. Sin embargo, con contornos complejos, de gran número de vértices, se consume mucho tiempo de computación.

En juegos como DOOM3 en PC, el modelo que genera sombras es prácticamente equivalente al modelo empleado para el personaje. Sin embargo, para aligerar el proceso, en SOTC se emplea un modelo simplificado con muchos menos polígonos.

El personaje principal se compone de unos 3.000 polígonos, mientras que un coloso ronda lo 18.000 (según el caso). Pero el modelo empleado para la generación de sombras contiene un número sustancialmente menor que esto. Por ejemplo, el modelo simplificado para el jugador sólo usa 1/40 polígonos del modelo original (unos 75)

En el juego, si se observa con detalle, la sombra del coloso es menos detallada que el modelo real, pero es muy difícil que la sombra del coloso y el modelo real del mismo puedan ser comparados en una escena real del juego, por lo que se considera admisible. ¿Tal vez sea esta labor de optimización el arte de un verdadero artesano?

Además, la sombra generada a través de la plantilla guardada en el buffer se suaviza mediante un algoritmo (blur) para conseguir sombras suaves. Aunque no es físicamente correcto (no tiene en cuenta la distancia desde el objeto a la sombra), la resolución a la que trabaja PS2 hace que el efecto funcione bien.

El modelo para las sombras:

En este caso, para la generación de sombras, que se aplica sobre la cara del personaje. Deliberadamente no proyecta sombras sobre él mismo, ya que sería visualmente desagradable.


El modelo para la generación de sombras del cuerpo del personaje. El número de polígonos ha descendido, aunque la forma es suficientemente aproximada.


A continuación, dos imágenes en las que se Súperponen el modelo para sombras (en modo alámbrico) y el modelo real. Nótese que modelo de la cara no proyecta sombra, como se comentó arriba.



Autosombreado

La generación de sombras en el modelo del coloso, en el que se han reducido en proporción 1/40 el número de polígonos. Como se observa, debido a su gran tamaño, no hay incongruencias.


A continuación, dos imágenes de un coloso. La primera de ellas, con el autosombreado desactivado, y la segunda con él activado.




El pelo en los colosos usando un fur shader
Al jugar a SOTC, el pelo en los colosos causa una impactante impresión. El término "fur shader" (sombreador de pelo, literalmente) se hizo popular con la generación de GPUs con shaders programables 1.x, y fue empleada en juegos de PC o  XBOX .

Con SOTC se implementó sin shaders programables. Durante la generación de los shader 1.x, una técnica popular para simular pelo fue usar una estructura multicapa, concéntrica a una Súperficie, como base.

El renderizado se realiza construyendo capas paralelas, desde la piel hacia el exterior, a una distancia determinada. Estos polígonos translúcidos se acumulan usando una textura del pelo distinta para cada capa, a modo de sección transversal del pelo, para conformar la sección completa del mismo. Se trata de una especie de efecto de renderización de volumen.

El aspecto suave y peludo, creado por el fur shader, aparece en estas imágenes. El movimiento, ondulación y espesor del pelo viene dado por esa "púa de pelo" que surge de la piel. Su aspecto es natural, ya que se ha ajustado para ello.





A continuación, varias capturas del proceso de desarrollo. Las múltiples capas a la piel del coloso, colocadas a una distancia dada, pueden observarse al mirar de cerca al modelo:





Con esta técnica, cuanto mayor sea el número de polígonos, más real parecerá el pelo. En SOTC, se tiende a limitar el número de capas a 3-6, debido a las limitaciones de procesamiento de PS2.

La técnica de la estructura multicapa realiza un buen trabajo para expresar la propia naturaleza del pelo, pero para imitar una alta densidad del mismo, es necesario emplear un mayor número de capas. Sin embargo, al intentar dibujar demasiadas capas de pelo, se sobrecarga la memoria de video, afectando al proceso de dibujado de la escena. Por ello, para conseguir un adecuado balance entre la calidad visual y la carga de trabajo, se dispusieron polígonos adicionales de pelo dibujados en sección longitudinal, que se colocan de modo perpendicular a la piel.
Combinando estas dos técnicas se obtiene una representación del pelo razonablemente natural.

Además, esta técnica puede ser empleada para representar zonas de hierba en campo abierto. He aquí una de ellas.


Cuando se implementó esta técnica de piel por capas en una GPU de la generación 1.x, empleamos un normal map para convertir la dirección en una textura, dando una impresión muy realista de iluminación por pixel. Además, algo que cambia de forma radical la sombra es la iluminación anisotrópica (es decir, la relación entre el ángulo de visión y la posición de la luz en cada pixel), que da al pelo su iluminación característica. Por supuesto, esto no es posible en PS2.

Sin embargo, en SOTC empleamos la unidad vectorial de PS2 para conseguir los mismos resultados en iluminación del pelo.

Además, cuando el coloso se mueve, ocasionalmente la piel se puede deformar de un modo exagerado, y cada capa de pelo ha de deformarse también en consecuencia. Por tanto, la correcta simulación del pelo no se realiza totalmente con los movimientos del coloso, para que no parezca artificial o incorrecta.

En cualquier caso, con PS2, el hecho de realizar el efecto pelo en tiempo real merece un especial reconocimiento. Estamos encantados de recalcarlo como uno de los efectos clave en los gráficos de Shadow of the Colossus.

A continuación, varias imágenes del pelo, en las que la iluminación se realiza a través de la unidad vectorial de PS2. Obsérvese los cambios en la sombra según la posición.





Unas imágenes del modelo de un coloso, en el que se pueden observar claramente las cinco capas de pelo:




Renderizado de paisajes.

En SOTC se han creado varios colosos, pero para encontrarse con ellos, el jugador ha de viajar alrededor del vasto entorno con Agro.

Es en este momento en el que se usa el sistema de renderizado del paisaje para dibujar lugares alejados, sin emplear trucos como niebla en la lejanía.

El paisaje se divide en tres regiones: la más alejada se trata como una imagen renderizada o una textura, pegada en un polígono en la lejanía. A este región se la denominó, en la jerga del equipo de desarrollo, "Súper Baja Resolución" (Súper Low)

Por consiguiente, la mayor parte de la región intermedia, que comprende desde el fin del entorno cercano al jugador hasta ese nivel de Súper Baja Resolución, se dibuja usando un entorno en baja resolución. El juego gestiona el mundo en unidades de 600x600 metros y, según el jugador se aproxima a una cierta distancia, se cambia este modelo en baja resolución por un modelo en alta resolución, que representa el entorno cercano. Este cambio se ha diseñado de forma gradual para que la transición no sea tan obvia o brusca.

Adicionalmente, antes de combinarse en una imagen para la zona de Súper Baja Resolución, la geometría del paisaje lejano se simplifica (aproximadamente, hasta 1/30 ó 1/100 de polígonos del modelo original). Debido a la escasa memoria disponible, normalemente se emplea el modelo en baja resolución para la mayor parte del escenario lejano. Gracias a esto, el modelo en baja resolución consigue una transición adecuada con la zona Súper Baja. La transición de las tres zonas resulta, finalmente, muy natural.

La vista lejana, en Súper Baja, se gestiona en 2D, pero se actualiza empleando el renderizado en tiempo real. Por esto, el cambio entre Súper Baja y la zona intermedia, en baja resolución, se realiza sin transición aparente.


La zona verde alrededor del árbol pertenece al modelo en alta resolución, el acantilado se dibuja en baja resolución y la parte alejada se dibuja en Súper Baja resolución


Los árboles tras la montaña pertenecen al área de Súper Baja Resolución


Además, el entorno cercano al jugador se dibuja en alta resolución, en cuadrículas de 100x100 metros.

El coloso es extremadamente grande, pero su dibujado no se gestiona de igual forma que el paisaje, a través de un sistema basado en la distancia a la cámara, ya que no hay memoria suficiente. Incluso en la lejanía, el coloso se dibuja sin simplificaciones.

Un aspecto a remarcar es la ausencia total de tiempos de carga mientras se recorre el entorno. Esto se consigue mediante una gestión adecuada de recursos, cargando dinámicamente, en un proceso en segundo plano, el paisaje.

Al entrar en una nueva zona, la geometría, las texturas y otros elementos de esta zona se cargan, y la información de anteriores zonas se desecha de la memoria. Tras repetir este proceso, la memoria se fragmenta en porciones en uso y sin emplear. Debido a esto, la eficiencia de la gestión de memoria se compromete.

En SOTC, durante el periodo de redibujado vertical, y si el tiempo de ejecución lo permite, se realiza un proceso de reordenamiento de la memoria fragmentada empleada para la gestión del paisaje. El programa recoloca adecuadamente los datos, de forma que se mantiene la optimización inicial de la memoria. Ésta no es una tecnología tan visible a primera vista como los gráficos, pero supone una gran optimización del resultado final del juego.

Colisiones con los colosos, y el sistema de deformación para colisiones.

Normalmente, cuando acontece una colisión en un juego con un gran final boss, la interacción entre éste y el jugador suele ser bastante "plana": es decir, si un gigante te pisa, simplemente mueres, o cuando le disparas, simplemente le inflinges daño... y ya está.

En Shadow of the Colossus, se ha intentado que esta interacción se realice de un modo más íntimo, permitiendo que el jugador se agarre al Coloso, planteando un sistema de gestión y control bastante poco convencional. A esto se le denomina "Sistema de deformación por colisiones"

Las dinámicas de Shadow of the Colossus vienen dadas del íntimo contacto entre protagonista y coloso:




Usualmente, en juegos 3D, el cálculo de colisiones se separa de los gráficos en tres dimensiones. Por ejemplo, un personaje puede escalar por una cara de una pared, pero el modelo 3D no es necesariamente el mismo que el modelo de colisiones de la misma.

Por un lado, si el juego es un shooter 3D, en el que el jugador dispara al enemigo, la detección de colisiones se realiza tomando una aproximación grosera de la forma del enemigo, usualmente mediante un cubo o una esfera por cada extremidad del modelo 3D, y se considera suficiente.

Sin embargo, el modelo del coloso en SOTC tiene una extensión tal que es necesario considerarlo como el propio entorno, ya que cuando el coloso mueve una pata o retuerce todo su cuerpo, si empleamos la misma filosofía de cálculo de colisiones anteriormente vista, bastante poco flexible, sería demasiado inexacto cuando estuviésemos en una vista cercana al coloso. Es necesaria otra aproximación.

De este modo, con SOTC, deberemos afrontar las colisiones con un modelo muy cercano a la forma real del coloso. Cuando éste se mueve, el hueso del coloso también lo hace, y el modelo de colisiones, lógicamente, deberá moverse de acuerdo a ese movimiento, es decir, consideramos un modelo deformable para el cálculo de colisiones. De ahí el nombre del sistema de deformación para colisiones.

Debido a la dificultad para realizar una detección de colisiones tan compleja en la unidad vectorial de PS2, es necesario simplificarla para acometerla en PlayStation 2

Para el cálculo de colisiones, por tanto, consideramos a todo el jugador como una esfera, a esos efectos, y realizamos un test "punto a polígono" [N. del T: un cálculo de la distancia entre el centro de la esfera y el modelo de colisiones del coloso]. Y para la colisión entre el coloso y el escenario, operamos de igual forma, considerando al coloso una esfera y realizando el mismo proceso con el modelo de colisión del escenario. Se desacoplan los dos cálculos de colisiones, por tanto.

Modelo de colisiones de un coloso.

La imagen siguiente muestra el modelo de colisiones de un coloso que, como vemos, se adapta razonablemente bien al modelo que se renderiza en pantalla.


A continuación, varias imágenes comparativas entre el modelo para colisiones y el modelo para renderizado de un coloso:









De igual forma, aquí vemos cómo el modelo de deformación del coloso se adapta según el movimiento del mismo.





Control del movimiento del coloso mediante cinemática inversa

En un juego 3D sencillo, el movimiento del personaje se traza calculando, desde la posición actual del mismo, aplicando un algoritmo dado por la animación diseñada por el artista. Sin embargo, esto puede ocasionar un efecto como si se anduviese por la luna, deslizando los pies.

Debido a que SOTC emplea personajes de un tamaño realmente considerable en relación al protagonista, se haría totalmente artificial usar una manera de animar tan sencilla. Es necesario, por tanto, conseguir que la pata del coloso, literalmente, se pose directamente sobre el suelo.

Por tanto, se plantea el uso, en tiempo real, de un algoritmo de cinemática inversa para el movimiento del coloso.

Por cierto, el método convencional, la cinemática directa, se construye a partir de una junta "hija" y una posición, que se modifican con el tiempo de forma relativa a otra junta "padre", con un ángulo dado. La cinemática inversa realiza el proceso contrario: se trata de calcular qué ángulo y qué posición tendrá la pieza padre a partir de la posición en la que coloquemos la pieza hija. Este campo de estudio es muy activo en la Robótica comom tema de investigación, pero recientemente ha cobrado interés en el desarrollo de juegos 3D.

En SOTC se emplea la Inteligencia Artificial del coloso para calcular la dirección del movimiento y su posición, y a partir de ahí determinar la posición necesaria de cada pata para realizar cada paso.

La animación de un coloso al andar parte de una base que ha animado un artista a mano, pero para calcular la posición de cada pata ha de ser calculada y ajustada al vuelo.

Debido a que el terreno no es plano, sino que presenta irregularidades, necesitamos ajustar el ángulo de apoyo de la pata del coloso según dónde pise (de lo contrario, aparecerían incoherencias). Así, con la posición de la pata, el ángulo y dirección de cada hueso se calcularán en cada paso. De igual modo, la cinemática inversa para el ajuste dinámico de peso de cada jueso no sólo se usa en los colosos: también en el personaje principal y en su caballo.

La dinámica de movimientos de un coloso es creada por un diseñador:





Para el movimiento del jugador, se combina la rutina de animación con la interacción con el escenario



De igual modo, el coloso posee sensores a su alrededor, cubriendo diversas zonas del escenario. Cuando el jugador entra en contacto con dicho sensor, pone en funcionamiento una determinada acción. Por ejemplo, si el jugador está frente al coloso, a una cierta distancia, el coloso atacará. Si acomete al coloso por detrás y se agarra a su lomo, intentará quitarse al jugador de encima... depende, por tanto, de la condición que se haya determinado.

El ajuste y la programación de los sensores son llevadas a cabo por el scripter, no por el programador, y puede ser ajustada con facilidad a cada escena.

Los sensores de IA del coloso:



En los últimos juegos 3D, la simulación física suele estar presente. La más usada en SOTC, sin duda, es la simulación del péndulo.

Cuando el jugador se agarra al coloso, y éste se agita violentamente para intentar tirarlo, el jugador se balancea desde su mano, donde se agarra, simulando el movimiento del péndulo

Varias imágenes de ejemplo:

Movimiento del personaje colgado del coloso:




El movimiento pendular y la deformación del modelo de colisiones:



Cinemática inversa y movimiento pendular:







Cinemática inversa aplicada al movimiento del caballo:
Posición básica en terreno llano


Solución tras aplicar un modelo de dos extremidades y cinemática inversa. La pata trasera está excesivamente doblada, pareciendo muy artificial


El mismo modelo, ajustado a mano por el diseñador


El falso volumen en las partículas y la falsa dispersión de luz en una iluminación de alta calidad.

En Shadow of the Colossus se ha cuidado enormemente el realismo del polvo y del humo. De forma habitual, este efecto se diseña mediante una textura con una imagen de humo, y se genera un gran número de partículas (un sprite 3D con textura), usando polígonos mapeados con esa textura. Sin embargo, es necesario perfeccionar esta técnica.

En SOTC se emplea una truco para dotar de volumen (falso, por supuesto) a las partículas que forman el humo o el polvo.

Para ello, se realiza un cálculo de iluminación, partiendo de la relación entre la dirección de la visión y las luces que afectan a la partícula, modificando adecuadamente la textura para que esté iluminada correctamente. Este proceso es muy caro, computacionalmente hablando, para ser realizado por la unidad vectorial, pero Fumito Ueda consideró que era necesario.

Esquema conceptual: una partícula, representada como una simple textura



Con esta técnica, se modifica la iluminación (y, por tanto, la textura de la partícula) según los parámetros anteriores y se obtiene un efecto más realista.



Sin aplicar el efecto...



y con él aplicado: