Repositorio Institucional de Documentos

Proyecto Fin de Carrera Rendering Ocean Wave Simulations Autor Javier Delgado Aylagas Director: Jeppe Revall Frisvad Ponente: Dr. Diego Gutiérrez Pérez Escuela de Ingeniería y Arquitectura 2013 Repositorio de la Universidad de Zaragoza – Zaguan http://zaguan.unizar.es Resumen Este proyecto ha sido desarrollado en el departamento DTU Compute de la Universidad Técnica de Dinamarca durante un intercambio Erasmus. El objetivo de este proyecto es construir un entorno de renderizado para el simulador oceánico desarrollado en el departamento DTU Compute de la Universidad Técnica de Dinamarca [EKBL09]. Dicho simulador permite generar olas oceánicas con una gran variedad de conguraciones almacenándolas en diferentes formatos de chero. Este proyecto utilizará dicho simulador y permitirá importar dichas simulaciones y renderizarlas proporcionando un aspecto realista al agua generada. Para ello se transforman las simulaciones al formato OBJ utilizando Matlab para que pueda ser leído por el entorno de renderizado. Posteriormente, se generará una salida visible de las olas generadas en el simulador, y es aquí donde se implementarán y aplicarán diferentes técnicas de renderizado para obtener un aspecto lo más realista posible. Esta parte se basa en su mayor parte en raytracing [App68], aunque se combina con otras propiedades como photon mapping para mejorar el aspecto del agua. Este apartado ha sido desarrollado en su totalidad sobre C++. Además, se incluirán como resultados diferentes simulaciones, tanto de imágenes como de vídeos, siendo una de las simulaciones proporcionada por la empresa Force Technology con sede en Kongens Lyngby (Dinamarca). Finalmente, se analizarán las limitaciones del proyecto y se plantearán mejoras para que pueda ser continuado en el futuro. ii Agradecimientos En primer lugar, quiero agradecer a mi supervisor Jeppe Revall Frisvad por toda su ayuda a lo largo del de desarrollo de este proyecto y también por facilitarme el entorno de trabajo, que ha simplicado considerablemente la implementación de la aplicación, y también a Diego Gutiérrez por sus comentarios para poder escribir esta memoria y por hacer de ponente para este proyecto. En segundo lugar, quiero agradecer a Allan P. Engsig-Karup por haberme facilitado el simulador y también toda su ayuda para poder utilizarlo correctamente, al igual que a Stefan Lemvig Glimberg, sin cuya ayuda no podría haber utilizado dicho simulador. También quiero agradecer al departamento DTU Compute el permitirme haber desarrollado mi proyecto, y especialmente a J. Andreas Bærentzen junto con Jeppe Revall Frisvad por sus comentarios y ayuda proporcionada en las reuniones semanales que se realizaron durante todo el desarrollo. Por otra parte, también quiero agradecer a Diego Gutiérrez sus comentarios para poder escribir esta memoria y por hacer de ponente para este proyecto. También quiero agradecer a la compañía Force Technology con sede en Kongens Lyngby su interés en este proyecto y su participación proporcionando algunos de sus modelos y simulaciones. Por último, quiero agradecer tanto a la Univesidad de Zaragoza como a la Universidad Técnica de Dinamarca el haberme permitido desarrollar este proyecto durante mi estancia Erasmus en Dinamarca. iv Índice general Resumen i Agradecimientos iii 1. Introducción 1 1.1. Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . 3 2. El proceso de renderizado 5 2.1. Elsimulador ............................. 6 2.1.1. Convirtiendo de binario a OBJ . . . . . . . . . . . . . . . 6 2.2. El entorno de renderizado . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. La ecuación de render . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Raytracing .......................... 8 2.2.3. Materiales........................... 9 2.2.4. El sol y el cielo . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Adaptación del entorno al simulador . . . . . . . . . . . . . . . . 11 2.4. Producción de vídeo . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Sombreado 15 3.1. Lambertian .............................. 16 3.2. Sombreador transparente . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Photonmapping ........................... 18 3.4. Absorción............................... 20 3.5. Modelo de reexión de Phong . . . . . . . . . . . . . . . . . . . . 22 3.6. Comentarios nales . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4 Introducción cionada con el simulador y el entorno de desarrollo. También explica en detalle las funciones de conversión de formatos creadas en Matlab y los ajustes realizados al entorno de renderizado. Sombreado. Este capitulo explica en detalle los diferentes sombreadores y técnicas utilizadas en cada uno de ellos. Resultados. Esta sección detalla la información de rendimiento de diferentes simulaciones. Para ello se han utilizado dos simulaciones que darán lugar a dos posibles vídeos, y otra procedente de una simulación realizada por la empresa Force Technology y que será renderizada en este capítulo. Conclusiones. Finalmente, en este capítulo se explican las conclusiones y posibles desarrollos futuros de la aplicación. Capítulo 2 El proceso de renderizado El agua es un elemento habitualmente crítico allá donde se utiliza, ya sea en videojuegos o películas, pero su nivel de detalle mejora enormemente el realismo de una escena. Además, es un problema computacionalmente complejo, y por tanto, es muy difícil de obtener en tiempo real [JL04] [Kry05]. Por esa razón, este proyecto se va a centrar en obtener una apariencia del agua realista dejando el hacerlo en tiempo real para futuros desarrollos. Este capítulo explica como ha sido organizado el trabajo en el proyecto. En primer lugar, el simulador genera matrices de puntos exportadas como cheros binarios. Después, estos cheros se han de transformar al formato Wavefront OBJ. Este paso se realiza en Matlab. Finalmente, los cheros OBJ se importan en el entorno de renderizado, el cual, utilizado según se detalla en el siguiente capítulo, generará los cheros de imagen. El proceso completo que se cubre en este proyecto se puede ver en la gura 2.1. En este capítulo se va obviar el proceso de sombreado, ya que, debido a su extensión, será explicado en un capítulo especíco. 6 El proceso de renderizado Figura 2.1: Proceso cubierto por este proyecto 2.1. El simulador Esta sección pretende situar al lector en el contexto del proyecto, cuyo objetivo es crear un entorno de renderizado para el simulador desarrollado por A. P. Engsig-Karup, Morten G. Madsen y Stefan L. Glimberg en el departamento DTU Compute de la Universidad Técnica de Dinamarca [EKBL09] [EKMG12]. El simulador utilizado ha sido desarrollado en FORTRAN y se utiliza sobre máquinas UNIX. Consta de dos versiones, una para CPU y otra para GPU. En este proyecto la versión utilizada ha sido la de CPU. Este simulador es el mismo que utiliza la empresa Force Technology en sus instalaciones, de manera que sus modelos serán compatibles y el entorno podría ser utilizado en sus instalaciones. De esta manera, en el capítulo 4 se ha utilizado una de las simulaciones generadas por Force Technology utilizando dicho simulador junto con uno de los modelos de barcos de los que disponen. Al utilizar el simulador, hay una gran cantidad de parámetros que se proporcionan en un chero de entrada y que permiten generar una gran variedad de resultados. Algunos de ellos tienen que ver con el tiempo de la simulación y también el tiempo entre dos fotogramas de una misma secuencia. En este caso, la frecuencia deseada es de 25 fotogramas por segundo, que es la utilizada en la mayoría de televisores actuales. 2.1.1. Convirtiendo de binario a OBJ La salida del simulador dispone de dos diferentes formatos que se eligen en el chero mencionado anteriormente. Los dos formatos posibles son en ASCII o en binario. Para este proyecto se ha elegido la salida en formato binario. Este chero contiene la información de todos los vértices de la matriz y también su energía, que se utiliza dentro del simulador para poder continuar la secuencia, pero en este proyecto de desechará. 2.1 El simulador 7 El siguiente paso es convertir estas matrices al mencionado chero OBJ para hacerlas compatibles con el entorno de renderizado. Este paso se realiza utilizando Matlab. La función de conversión carga todos los archivos que hay en el directorio actual y que sigan el formato especicado, que en este caso es EP_xxxxx.bin ya que es el nombre por defecto que devuelve el simulador. Entre otras cosas, el conversor también añade las líneas que van a determinar el grupo al que pertenece el objeto y también su material. El chero de materiales se llama ow.mtl y el material asignado deberá estar contenido en este chero. Este chero contiene los valores ambiental, difuso y especular del material, así como el valor illum que determinará el sombreador a utilizar en el entorno de renderizado. En este caso, el material a utilizar será seawater para las matrices que representan el agua. La función de Matlab desde el primer momento se encarga de convertir todos los cheros que se encuentren con el formato explicado anteriormente, ya que se necesitarán más adelante en el contexto del proyecto. El nombre de los cheros sigue el mismo nombre por defecto que anteriormente, de manera que los cheros EP_xxxxx.bin se transforman en EP_xxxxx.bin.obj. Figura 2.2: En esta gura se puede ver la geometría de una de las mallas del simulador visualizada en Maltab. La representación está realizada en unidades genéricas de longitud. El color de la malla está determinado por su magnitud en el eje Z. Además, se ha incluido una función que dibuja la malla en Matlab para comprobar la corrección del mismo. Un ejemplo de esta visualización en Matlab se 8 El proceso de renderizado puede ver en la gura 2.2. 2.2. El entorno de renderizado Esta sección detalla en qué consiste el entorno de renderizado facilitado por el departamento DTU Compute. Este entorno tiene algunas funciones básicas implementadas, aunque su parte principal, que son los sombreadores, no están implementados. Todas las referencias al entorno de rendering que se encuentren fuera de esta sección han tenido que ser implementadas, mientras que las funciones que ya estaban incluídas se detallan a continuación. 2.2.1. La ecuación de render En primer lugar, es necesario denir en qué consiste el proceso de renderizado. Renderizar el es proceso de generar una imagen mediante el cálculo de de la iluminación de una escena en tres dimensiones. Para determinar la iluminación en cada punto de la escena se utiliza la ecuación de render [Kaj86a]: L(x, ω o ) = Le(x, ω o ) + RΩfr(x, ω i , ω o )L i (x, ω i ) (ω i ·n) d ω i El resultado de la ecucación es la radiancia L(x, ωo ) , la cual viene determinada en función de la posición x y la dirección ωo , y es el resultado de sumar la radiancia emitida por la supercie Le (x, ωo ) y la radiancia indicente L(x, ωi ) en el punto x procedente de todas las direcciones, donde ωi es la dirección de incidencia. El término (n•ωi) representa la atenuación según el ángulo de incidencia y el término fr(x, ω i , ω o ) representa el BRDF (Bidirectional Reectance Distribution Function) en el punto x que determina la forma en la que es reejada la luz en la supercie. 2.2.2. Raytracing Este proyecto utiliza un entorno de renderizado basado en raytracing [App68]. Como crear un raytracer desde cero llevaría más tiempo que el propio proyecto, se ha proporcionado el utilizado en la asignatura Phisically Based Rendering del departamento DTU Compute, el cual contiene algunas funciones básicas ya implementadas aunque no incluye ningún sombreador entre otras cosas. 2.2 El entorno de renderizado 9 La técnica de raytracing consiste en la emisión de rayos desde la cámara a través de cada uno de los píxels de la imagen. Cuando los rayos encuentran un objeto, si éste tiene propiedades de reexión o refracción, se trazarán dichos rayos desde este nuevo punto, y se continuará haciendo recursivamente con cada intersección con un nuevo objeto. Además, se trazará un rayo hacia la fuente de luz, el cual, si no atraviesa ningún otro objeto, será sombreado calculando la cantidad de luz recibida y su ángulo, además de con los valores de reexión y refracción, mientras que si el rayo atraviesa algún objeto, el valor se calculará solamente con los valores de reexión y refracción al estar en sombra. En este proyecto, se ha establecido la cantidad máxima de divisiones de rayos en 10. A partir de ese valor, se aplicará path tracing. Lo que hace esta técnica es seguir los rebotes de uno posibles caminos en vez de hacerlo de todos, lo que hace que pueda aparecer ruido en las imágenes, aunque el proceso será más rapido a partir de ese punto. Para ello, se calculará un valor aleatorio para elegir o bien el rayo reejado, o bien el refractado. El proceso se ha congurado para que termine después de 20 rebotes. Entre las utilidades que incluye el entorno de renderizado cabe mencionar la de importar cheros OBJ y guardar imágenes PNG de los resultados que serán utilizadas en este proyecto. Además, el entorno utiliza internamente una estructura de árbol BSP (Binary Space Partition) [SS92] para almacenar la geometría en memoria. Dentro del entorno, el usuario puede mover la cámara con el ratón, guardar y cargar la vista y la posición de la cámara e incrementar o decrementar el número de rayos por píxel que serán utilizados. Además, aunque el proyecto permite utilizar cualquier número de luces, solo se va a utilizar una luz direccional que representará el sol. Además, el entorno también controla diferentes tipos de visualización, cuyos sombreadores están inicialmente vacíos, como solo iluminación directa, oclusión ambiental, path tracing o photon mapping, aunque no todos se van a utilizar en este proyecto. Además, aunque todas estas técnicas se pueden implementar en el entorno, hay que saber antes de nada cuales serán utilizadas y desechar el resto para no implementarlas innecesariamente. 2.2.3. Materiales El entorno también incluye un chero de materiales llamado media.mpml. Si en el chero ow.mtl descrito anteriormente se encuentra algún material coincidente, se aplicarán las propiedades descritas en ambos cheros. En contreto, 10 El proceso de renderizado este chero contiene un material seawater que incluye más propiedades sobre el agua. En este chero también se podría incluir nuevos tipos de agua ya que los diferentes océanos tienen ligeras variaciones en su aspecto. 2.2.4. El sol y el cielo Habitualmente, las escenas generadas por ordenador suelen ser en entornos cerrados, sin embargo, este proyecto genera una escena al aire libre, de manera que en lugar de usar un color de fondo para todo el cielo, se va a añadir un método para calcular los colores del cielo. Además, este color también afectará al aspecto del agua al ser reejado por ella. Un modelo muy utilizado hoy en día, y que además es computacionalmente asequible, es modelo de Preetham, Peter Shirley y Brian Smits de la Universidad de Utah [PSS99]. Este modelo simplica enormemente los cálculos para obtener la luz atmosférica que alcanza cada punto de la escena y aporta un gran realismo a la misma. El modelo utiliza las coordenadas reales de la Tierra, así como la fecha y la hora. El modelo simplica los cálculos necesarios debidos a la dispersión de la luz en la atmósfera teniendo en cuenta que en la dirección que mira el observador pueden llegar rayos que han sido reejados en distintos puntos de la atmósfera. Un ejemplo se puede ver en la gura 2.3. Además el modelo simplica algunos parámetros de la atmósfera que habitualmente son desconocidos o muy diciles de calcular. Figura 2.3: Diagrama de la dispersión en el cielo. Este modelo también incluía parte de su estructura en el entorno de renderizado facilitado para realizar este proyecto, aunque se han tenido que realizar pequeños 2.3 Adaptación del entorno al simulador 11 ajustes. Para este proyecto, la fecha elegida ha sido un día de otoño a las 12.00 y se ha localizado en Dinamarca. Estos valores pueden ser modicados en cualquier momento en el entorno de renderizado. 2.3. Adaptación del entorno al simulador Aunque el entorno de renderizado permite importar objetos en formato OBJ, es necesario realizar algunos ajustes para su correcta visualización. Por ello, después de cargar el objeto correspondiente en memoria, se realizan los siguientes cambios sobre el mismo. El simulador, por defecto, no incluye el fondo marino, y dado que es importante para la visualización, se ha procedido a incluirlo dentro del entorno de renderizado. De esta manera, se colocará un cuadrilátero inclinado por debajo de la malla de agua. Esta opción no es del todo precisa y por eso lo deseable es obtener el fondo marino directamente del simulador. De hecho, las últimas versiones del simulador ya lo generan por defecto. Con la actual conguración, la luz podría llegar al fondo marino sin pasar por la supercie. Este fenómeno se puede apreciar en detalle en la gura 2.4. Para arreglar esta cuestión, se ha creado una caja que rodee tanto el agua como el fondo marino, creando algo similar a una piscina. Esta caja debe abarcar desde el punto más alto de la ola hasta el punto más bajo del fondo marino. Figura 2.4: Este diagrama muestra por qué es necesario cubrir los laterales del agua. Si no existiesen el agua alcanzaría el fondo marino sin pasar por la supercie. Al añadir estos cuadriláteros sigue habiendo una anomalía, ya que la escena será más oscura en los bordes, pero el resultado será mucho más preciso que anteriormente. Usando este método, todavía hay un efecto indeseado, ya que al acercarse a las 12 El proceso de renderizado esquinas, el aspecto del agua será más oscuro al llegar menos rayos al fondo marino dependiendo del punto y del ángulo del sol. Además, el lado que mira directamente al sol acumulará una cierta cantidad de fotones que no le correspondería (Esto será detallado más adelante en el apartado de photon mapping). Este efecto puede ser mejorado creando mallas más grandes o creando playas suaves en la intersección entre el fondo marino y la supercie del agua. Finalmente, se ha añadido un plano que representa el suelo. Este suelo se ha colocado más abajo de lo que le correspondería de manera que el agua estaría otando. Esto se ha hecho para que la visualización del horizonte sea mas coherente a como es en realidad, aunque esto crea una sombra en el suelo. Este fenómeno también se puede evitar creando mallas más grandes como se ha explicado anteriormente. 2.4. Producción de vídeo La producción de vídeo se gestiona utilizando la línea de comandos al ejecutar la aplicación. En estos argumentos se dene cual es la primera y la última iteración a renderizar, y también el periodo de tiempo entre cada una de ellas. Si el número de la primera iteración es menor que el último, se procederá a un renderizado en cadena, tomando progresivamente las diferentes simulaciones hasta que termine la última. El nombre de las imágenes resultantes será EP_xxxxx.bin.obj.png siguendo el mismo formato que en todos los pasos anteriores. Para poder crear una escena de vídeo, hay que ejecutar el programa, colocar la cámara en el lugar deseado, y posteriormente, pulsar 4 y R para comenzar el renderizado. Durante el proceso, se almacenarán en disco los fotogramas renderizados, sin embargo, la visualización de la escena en la aplicación no se actualizará hasta que se haya terminado el último fotograma. Finalmente, para poder montar las imágenes y generar secuencias de vídeo, es necesario utilizar una aplicación externa como podría ser Windows Movie Maker. 2.5 Diagrama de clases 13 2.5. Diagrama de clases Esta sección muestra un diagrama de clases simplicado del entorno de renderizado. En dicho diagrama se han coloreado de verde todas las clases modicadas en este proyecto, aunque la que ha sufrido la mayoría de los cambios ha sido la clase RenderEngine . El diagrama de clases se puede ver en la gura 2.5. En este diagrama se han simplicado los sombreadores dejandolos como una única clase, aunque este diagrama se desglosará en el capítulo 3 que trata sobre todos los sombreadores implementados. Figura 2.5: Diagrama de clases del entorno de renderizado. 20 Sombreado Figura 3.6: Esta gura muestra la ecuación para la estimación de la radiancia, que es una aproximación a la ecuación de render. uno de ellos, de manera que el método es más preciso según se aumenta la cantidad de fotones emitidos, lo que, por otra parte, lo hace más lento. De esta manera, al incrementar el valor, será más probable que los diferentes caminos sean tomados por los diferentes fotones haciéndolo así más preciso. La formación de las causticas dependerá de la forma de las olas y también de la distancia desde la supercie hasta el fondo, ya que solo se formarán donde converjan una gran cantidad de fotones. Como se ha explicado anteriormente, el entorno de renderizado incluye una opción para visualizar el resultado de photon mapping, aunque el sombreador ha tenido que ser implementado (si no se hace, el visualizador simplemente no muestra nada). El motivo de la elección de Photon mapping para visualizar las cáusticas se debe a que este algoritmo está construido sobre raytracing, que es la técnica principal de este proyecto. Este método estará activado siempre que al renderizar se utilice el visor número 4 en el entorno de desarrollo. El número de fotones se puede ajustar en la aplicación, así como el número de fotones usados en la estimación. En este proyecto, estos valores son 7.500.000 fotones y 200 para la estimación. En la gura 3.7 se pueden ver tanto el mapa de fotones como el resultado de aplicar photon mapping al agua transperente. 3.4. Absorción El siguiente efecto que se va a utilizar tiene que ver con la profundidad del agua. De esta manera, el agua será mas oscura cuanto más profunda sea, llegándose a un punto en el que el fondo marino no llegue a ser visible. En este sombreador, se planteó la posibilidad de utilizar scattering [GSMA08] [DGJ08]. Esta técnica lo que haría sería reejar o refractar el rayo en diferentes puntos dentro de un volumen. A esta acción se le denomina evento de scattering, 3.4 Absorción 21 Figura 3.7: Izquierda: Visualización de los mapas de fotones. Derecha: Resultado del renderizado utilizando un sombreador transparente combinado con photon mapping. Las cáusticas se pueden ver perfectamente en el fondo marino. y se producirían cuando se encuentre una partícula dentro del volúmen. Sin embargo, aunque en este proyecto se trabaje con uídos, estos no pertenecen a un volúmen, si no que se realiza utilizando diferentes supercies las cuales forman una geometría cerrada, de manera que se optó por descartar esta técnica. Además, utilizar scattering hubiera supuesto un tiempo de renderizado mucho mayor debido a los múltiples eventos que ocurrirían dentro del volúmen. En su lugar, se va a aplicar absorción. El término de absorción es la probabilidad de que la luz sea absorbida por el medio que está atravesando. En este caso, lo que se hace es trazar un rayo en la dirección de refracción y se mide la distancia desde la supercie hasta el fondo, siguiendo la dirección de dicho rayo. De esta manera, se puede aplicar el coeciente de absorción en función de la longitud del rayo [EC05]. Este sombreador forma parte de una nueva clase, sin embargo, se utiliza sobre el de materiales transparentes al cuál se le añade el término de absorción. La gura 3.8 muestra la escena usando absorción de manera aislada (sin photon mapping). Es a partir de este punto donde adquiere sentido la piscina que se ha creado envolviendo a los objetos, ya que la única manera de que entre luz en el fondo es atravesando la supercie. Además, este sombreador se ha construido sobre el transparente, ya que el termino de absorción se aplica sobre dicho sombreador. De esta manera, la cantidad de luz que llega al fondo es muy pequeña, y a partir 22 Sombreado Figura 3.8: Esta gura muestra como el color del agua es afectado por la absorción. En la parte izquierda de la imagen se puede ver como la profundidad es menos y el color resultante es mas claro. En la parte derecha, sin embargo, el color es más oscuro debido a que el agua es más profunda. de este punto casi toda la luz que alcance el fondo será a través de fotones, cuyas causticas serán visibles desde el exterior si la absorción lo permite. 3.5. Modelo de reexión de Phong Por último, para contribuir un poco más al aspecto del agua, se ha implementado el modelo de reexión Phong, que no ha de ser confundido el modelo de sombreado de Phong. Este modelo contribuye a la reexión del agua, que reejará la luz del sol cuando el ojo, la supercie del agua, y el sol, estén en el mismo plano [Pho75]. La ecuación para aplicar la reexión de Phong se encuentra en la gura 3.9. Esta ecuación solo aplica la componente especular de la luz, debido a que la iluminación directa ya se ha calculado anteriormente. De esta manera se consigue 3.5 Modelo de reexión de Phong 23 Figura 3.9: Esta gura muestra la ecuación de la reexión de Phong. que se reeje el sol en la supercie del agua en caso de que la cámara esté en el lugar apropiado. De esta manera, la luz reejada Lr será la componente especular ks del objeto, multiplicado por el factor cos(α)s , donde s es el brillo y α es el coseno del ángulo entre el vector que une el punto de la geometría con la cámara y el vector normalizado del rayo reejado, la luz emitida Li y el coseno del ángulo θ , que es el ángulo formado por el vector que une el punto de la geometría con la cámara y la normal del la geometría. La gura 3.10 muestra la escena utilizando la reexión de Phong junto con el resto de propiedades descritas hasta el momento. Figura 3.10: Esta gura muestra como el sol es reejado en la supercie del agua usando la reexión de Phong. 24 Sombreado 3.6. Comentarios nales Como se ha explicado anteriormente, en la versión nal de la aplicación el usuario puede elegir entre los diferente sombreadores, y esto se hace en el chero ow.mtl. Dentro de este chero es donde elige el sombreador deniendo el valor illum apropiado. En este caso, para el agua se ha utilizado el valor 15. Este sombreador combina absorción, photon mapping y reexión de Phong. Este sombreador ha sido utilizado, por ejemplo, en la gura 3.11. Otro sombreador utilizado es el transparente, aunque este sólo se ha utilizado en los ejemplos. En este caso el valor illum tiene que ser 4 y también utiliza photon mapping. Este sombreador ha sido utilizado en la imagen de la derecha de la gura 3.7. Por último, el sombreador difuso ha sido utilizado como ejemplo para el agua en la gura 3.2 aunque ha sido utilizado para el fondo marino en todas las demás imágenes. Además, el modelo del cielo y el sol se ha utilizado en todas las imágenes y no está vinculado a los sombreadores. Figura 3.11: Esta gura muestra las cáusticas y absorción en el agua 3.6 Comentarios nales 25 El diagrama de clases con la estructura de todos los sombreadores se pueden ver en la gura 3.12. Como se ha explicado anteriormente, el entorno incluía una estructura básica de algunos sombreadores, aunque ninguno estaba implementado. En el diagrama se han señalado en color verde los sombreadores implementados, en los cuales se ha incluído el método shade que se hereda desde el sombreador más básico Shader.h . Figura 3.12: Diagrama de clases de los sombreadores 26 Sombreado Capítulo 4 Resultados Una vez que se ha terminado la implementación, se han llevado a cabo varias simulaciones cuyo objetivo es estudiar el tiempo consumido y generar secuencias de vídeo. Dos de los ejemplos se han congurado para generar dos secuencias de vídeo, mientras que otra se ha realizado con el objetivo de obtener una sola imagen aunque con mucho más nivel de detalle. Para llevar a cabo las simulaciones, se ha determinado la frecuencia en 25 imágenes por segundo que es la que se usa actualmente en las televisiones europeas. De esta manera, hay que congurar el simulador para obtener un fotograma cada 0.04 segundos. En el caso de las simulaciones para una sola imagen, se ha utilizado más de un rayo por píxel, que es una opción que, como se ha explicado anteriormente, viene implementada en el entorno de renderizado. 4.1. Ola lineal Esta simulación da como resultado una ola en dos dimensiones, de manera que para transformar a 3 dimensiones, simplemente se ha extendido en la dimensión restante. Al ser una ola en solamente dos dimensiones, se espera que sea computacionalmente sencilla. Esta simulación va a generar una secuencia de 600 fotogramas y creará un vídeo de 24 segundos. La gura 4.1 muestra el tiempo 28 Resultados requerido por cada uno de los procesos y también el tiempo medio por fotograma. En este caso, el tamaño de la malla que forma el agua es de 259 x 2 vértices en cada dirección. Figura 4.1: Esta tabla muestra los tiempos para el ejemplo de una ola lineal En este caso, la simulación ha durado 0,3 segundos por cada fotograma, de manera de que el tiempo total ha sido de 3 minutos. El tiempo de conversión también ha sido signicativo, aunque este proceso ha sido mucho más rápido. En este caso el tiempo ha sido de 0,07 segundos por cada fotograma, mientras que el tiempo total ha sido de 42 segundos. La geometría se puede ver en la gura 4.2 tanto como se ve en Matlab como después de renderizada. Las salidas de esta simulación también han sido utilizadas en otras partes de la memoria. Figura 4.2: La imagen de la izquierda representa la geometría de la malla visualizada en Matlab, cuyo color es determinado por la coordenada Z. La imagen de la derecha es la visualización de la misma malla, ésta vez visualizada después de renderizar. 4.2 Ola no lineal 29 Finalmente, el tiempo de renderizado ha sido de unos 8 minutos de media, de manera que el tiempo para los 600 fotogramas ha sido de unas 83 horas. En el apéndice A se pueden ver algunos de los fotogramas pertenecientes a esta secuencia. 4.2. Ola no lineal Esta simulación genera una ola en 3 dimensiones y consta nuevamente de 600 fotogramas que representarán 24 segundos de vídeo. En este caso, al ser una simulación en 3 dimensiones, se espera que la simulación sea más lenta que en el caso anterior. La gura 4.3 muestra los tiempos obtenidos en los tres pasos que requiere el proceso. En este caso, el tamaño de la malla que forma el agua es de 259 x 19 vértices en cada dirección. Figura 4.3: Esta tabla muestra los tiempos obtenidos para el ejemplo de la ola no lineal. En este caso, la conversión también ha sido más lenta que anteriormente debido al mayor número de vértices que procesar, aunque este paso ha sido nuevamente el más sencillo de los tres. Finalmente, el renderizado de la secuencia ha tardado una media de 3,5 minutos por fotograma siendo el tiempo total de 35 horas. En este caso, el tiempo de una sola imagen ha tomado entre 180 segundos para el caso mejor y 380 segundos para el caso peor. Aunque esta ola es una ola en 3D, en la visualización después de renderizar es muy dicil de apreciar ya que avanza en una sola dirección, sin embargo, como se puede ver en la gura 4.4, en la visualización en Matlab se pueden observar sus diferencias. En el apéndice A se pueden ver algunos de los fotogramas pertenecientes a esta secuencia. 36 Conclusiones Figura 5.1: Diagrama de Gannt del proyecto Bibliografía [App68] Arthur Appel. Some techniques for shading machine renderings of solids. In Proceedings of the April 30May 2, 1968, spring joint computer conference , AFIPS '68 (Spring), pages 3745, New York, NY, USA, 1968. ACM. [DGJ08] Srinivasa Narasimhan Diego Gutierrez, Henrik Wann Jensen and Wojciech Jarosz. Scattering. 2008. [EC05] Xavier Pueyo Francisco J. Seron François X. Sillion Eva Cerezo, Frederic Pérez. A survey on participating media rendering techniques. 2005. [EKBL09] A. P. Engsig-Karup, H. B. Bingham, and O. Lindberg. An ecient exible-order model for 3d nonlinear water waves. J. Comput. Phys. , 228(6):21002118, April 2009. [EKMG12] A. P. Engsig-Karup, Morten G. Madsen, and Stefan L. Glimberg. A massively parallel gpu-accelerated model for analysis of fully nonlinear free surface waves. International Journal for Numerical Methods in Fluids , 70(1):2036, 2012. [GSMA08] Diego Gutierrez, Francisco Seron, Adolfo Muñoz, and Oscar Anson. Visualizing underwater ocean optics. Computer Graphics Forum (Proc. of EUROGRAPHICS) , 27(2):547556, 2008. [JB02] Henrik Wann Jensen and Juan Buhler. A rapid hierarchical rendering technique for translucent materials. ACM Trans. Graph. , 21(3):576581, July 2002. 38 BIBLIOGRAFÍA [JL04] Claes Johanson and Calle Lejdfors. Real-time water rendering. Lund University , 2004. [Kaj86a] James T. Kajiya. The rendering equation. SIGGRAPH Comput. Graph. , 20(4):143150, August 1986. [Kaj86b] James T. Kajiya. The rendering equation. SIGGRAPH Comput. Graph. , 20(4):143150, August 1986. [Kry05] Yuri Kryachko. Using vertex texture displacement for realistic water rendering , volume 2. 2005. [Lew93] Robert R. Lewis. Making shaders more physically plausible. Technical report, Vancouver, BC, Canada, Canada, 1993. [NJC00] Henrik Wann Jensen Niels Jørgen Christensen. A practical guide to global illumination using photon maps. 2000. [Pho75] Bui Tuong Phong. Illumination for computer generated pictures. Commun. ACM , 18(6):311317, June 1975. [PSS99] A. J. Preetham, Peter Shirley, and Brian Smits. A practical analytic model for daylight. In Proceedings of the 26th annual conference on Computer graphics and interactive techniques , SIGGRAPH '99, pages 91100, New York, NY, USA, 1999. ACM Press/AddisonWesley Publishing Co. [Ska06] Johannes Skaar. Fresnel equations and the refractive index of active media. Phys. Rev. E , 73:026605, Feb 2006. [SS92] Kelvin Sung and Peter Shirley. Graphics gems iii. chapter Ray tracing with the BSP tree, pages 271274. Academic Press Professional, Inc., San Diego, CA, USA, 1992. Apéndice A Resultados adicionales Esta sección contiene algunos fotogramas de los resultados obtenidos en el capítulo 4. La primera secuencia pertenece al ejemplo de la ola lineal, mientras que la segunda pertence al ejemplo de Whalin. 40 Resultados adicionales Figura A.1: Esta gura incluye algunos fotogramas pertenecientes a la secuencia de la ola lineal descrita en el capítulo 4 41 Figura A.2: Esta gura incluye algunos fotogramas pertenecientes a la secuencia de la ola de Shalin descrita en el capítulo 4 42 Resultados adicionales Apéndice B Versión de la memoria en inglés En este anexo se incluye la versión en inglés de la memoria, que ha sido entregada en la Universidad Técnica de Dinamarca. Rendering Ocean Wave Simulations Javier Delgado Aylagas Kongens Lyngby 2013 IMM-B.Sc-2013 vi Contents Summary i Preface iii Acknowledgements v 1 Introduction 1 1.1 Expected outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 The rendering pipeline 5 2.1 Thesimulator............................. 6 2.1.1 Converting the output to a Wavefront OBJ le . . . . . . 6 2.2 The rendering framework . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Adaptation of the framework to the simulator input . . . 8 2.2.2 Video production . . . . . . . . . . . . . . . . . . . . . . . 9 3 Shading 11 3.1 Lambertian reectance . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Transparent shader . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Photonmapping ........................... 13 3.4 Absorption .............................. 14 3.5 Phong reection model . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6 Otherproperties ........................... 16 3.7 Finalcomments............................ 17 4 Results 19 4.1 Linear travelling Wave . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Whalin's experiment . . . . . . . . . . . . . . . . . . . . . . . . . 20 viii CONTENTS 4.3 NewmannKelvin........................... 22 4.4 Comments............................... 23 5 Conclusions 25 5.1 Limitations and future improvements . . . . . . . . . . . . . . . . 26 5.2 Personal conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3 Project development . . . . . . . . . . . . . . . . . . . . . . . . . 27 Bibliography 29 List of Figures 1.1 Example of the result of the execution . . . . . . . . . . . . . . . 3 2.1 Pipeline of this project . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Matlab output seen as a PNG le . . . . . . . . . . . . . . . . . . 7 2.3 Diagram of the visualization modications . . . . . . . . . . . . . 8 3.1 LambertianBRDF.......................... 12 3.2 Water rendered as Lambertian . . . . . . . . . . . . . . . . . . . 13 3.3 Diagram of reection and refraction . . . . . . . . . . . . . . . . 14 3.4 Photonmaps ............................. 15 3.5 Absorption inside water . . . . . . . . . . . . . . . . . . . . . . . 16 3.6 Phongreection ........................... 17 3.7 Caustics and absorption . . . . . . . . . . . . . . . . . . . . . . . 18 4.1 Time for Linear Travelling Wave . . . . . . . . . . . . . . . . . . 20 x LIST OF FIGURES 4.2 Visualization of the Linear Travelling Wave . . . . . . . . . . . . 21 4.3 Time for the Whalin Wave . . . . . . . . . . . . . . . . . . . . . . 21 4.4 Visualization for the Whalin Wave . . . . . . . . . . . . . . . . . 22 4.5 Visualization of the simulation provided by Force Technology insideMatlab.............................. 23 4.6 Time of the Simulation provided by Force Technology . . . . . . 23 4.7 Render of the simulation provided by Force Technology . . . . . 24 5.1 Ganntdiagram............................ 28 Chapter 1 Introduction Computer generated water is a very used element nowadays. It is being used in a lot of applications but it is mainly used in video generation for lms or adverts, and for computer games, but also a lot of companies need water rendering for investigation and also for simulations. Water can be very dicult to render, and the proccess can be separated in two steps. The rst one is the water geometry which must be updated every frame if we don not want completely calm water. The second step is the rendering of the geometry and it will handle with the water properties as a material. In this project, the rst step is performed by a simulator developed by A. P. Engsig-Karup, Morten G. Madsen and Stefan L. Glimberg at the Department of Informatics and Mathematical Modeling [EKBL09][EKMG12]. The aim of this project is to provide a rendering framework which takes as input the ocean wave simulations generated by the mentioned simulator. This framework will have realistic water appearance as output in a process that requires two steps. First of all, it has to deal with the compatibily between the simulator and the rendering framework, and the second step deals with the techniques used to obtain realistic water. This project will study the most important water properties which are going 2 Introduction to be used to obtain realistic water. Some of them are the seaoor colour and its distance to the water surface, but also the sky and environment which also aect its aspect as they are reected by the water. The render engine is based in raytracing and it is completed with photon mapping as water is known to generate caustics in the seaoor. The render engine will be also set up in order to show the generated correctly, and it will also allow the user to generate sequences of frames as well as the simulator does, so ocean water meshes can be generated massively to produce video sequences. This project uses a visualization framework used in the course Phisically Based Rendering to implement dierent techniques. In this project, only some of them have been implemented but it has been extended in other many ways. 1.1 Expected outcomes The project has got two separate parts. The rst one deals with the simulator. In this part, the main parameters of the simulator input le will be explained. In addition, this part covers the transformation from a binary le generated with the simulator and its conversion to a Wavefront OBJ le which is the input of the render engine. This step is performed using Matlab. The second part covers the adjustments made to the render engine but also the shading step, which is the main purpose of this project. On the one hand, the framework has been modied and completed in order to get the most accurate results. Also, it may add missing meshes such as the seaoor in the case that it is not provided by the simulator. On the other hand, dierent shaders have been used in the proccess adding complexity starting from a simple transparent shader and completing it until the nal one. Finally, the outcome of the project as a whole, is a variable number of pictures, which can be combined to generate video les using third party applications. An example of the output image le can be seen in the gure 1.1. 1.2 Document structure The content of the rest of the document is organized as follows: 1.2 Document structure 3 Figure 1.1: Example of the result of the execution. The seaoor can be appreciated, and also the depth of the water and the caustics generated by the waves. Rendering. This chapter contains all the information related with the simulator and the rendering framework. It explains the main parameters used for the water, but also how are the meshes converted into Wavefront OBJ les and what has been changed in the framework to open the simulator les correclty. Shading. This chapter explains in detail the dierent implemented shaders and the techniques used in all of them. Results. This section analyzes the execution time of the render and also shows the aspect of the dierent simulations both in Matlab and after the rendering step. Conclusions. This chapter details the conclusions of the project, but also its limitations and future improvements to continue its development. 4 Introduction Chapter 2 The rendering pipeline Water surfaces are very common in video games and lms, and it is usually a critical element and its level of detail will improve the realism of any scene. In addition, it is usually a very hard computational problem so that it is still dicult to render real-time water [JL04][Kry05]. For that reason, this project will try to compute realistic water with short rendering time leaving real time rendering to the future. This chapter explains how has been the work organized. First of all, the simulator generates water meshes exported as binary les. Afterwards, these binary les should be transformed into Wavefront OBJ les. This step is performed using Matlab functions. Finally, the object les are imported into the rendering framework which, used as it is explained in the next chapter, will output PNG image les. The complete pipeline that is covered by this project is shown in the gure 2.1. 12 Shading is dierent depending from one ocean to another, more kinds of water could also be dened in this le. 3.1 Lambertian reectance This shader is the most basic one that has been used in the project, but it is neccessary as it is used for the seaoor. Lambertian reectance is the property that denes a pure diuse surface. The amount of light returned by the geometry depends only on the angle between the light respect the geometry normal and it does not depend on the eye position. The Lambertian BRDF (Bidirectional reectance distribution function) can be seen in gure 3.1. As an example, the scene has been rendered using this shader for the water. The result can be seen in gure 3.2. Figure 3.1: Lambertian BRDF 3.2 Transparent shader In order to use this shader correctly, the fresnel equations have been used to calculate the refractive index. The fresnel equations calculate the reectance, which is the amount of energy reected while The rest of the energy (1-R) is refracted. Using this equations, the reectance will vary depending on the incident angle and the index of refraction of both mediums and for small angles, there might be only reected light [Ska06]. 3.3 Photon mapping 13 Figure 3.2: Water rendered as Lambertian Once the reectance is calculated, this shader traces 2 rays: the reected one and the refracted one, and they are combined depending on the refractive index that has been explained before [JB02]. The diagram of the reected and refracted rays can be appreciated in gure 3.3. In addition, the framework uses a variable which sets the maximum number of recursions of the algorithm [PH04]. 3.3 Photon mapping In this project, we are using a seaoor which will aect the aspect of the water in dierent ways. One of that ways will be the caustics produced by the waves which will be seen in the seaoor. As caustics are going to aect the aspect of water signicantly, photon mapping has been implemented in this project [NJC00]. The photons may produce caustics depending on the shape of the wave but also depending on the distance from the seaoor to the sea surface. As we have explained before, the framework allows the use of photon mapping 14 Shading Figure 3.3: This diagram shows the reected and refracted rays, which are used in some of the shaders. altought it must be implemented. In addition, there is an option to visualize the photon maps. These photon maps and the whole scene using a transparent shader with caustics are shown in the gure 3.4. The number of used photons can be set in the framework, and also the number of photons used in the estimation. In this project, these values have been set to 7500000 photons and 200 of them used for the estimate. 3.4 Absorption The next eect that we are going to use has to do with the depth of the water. The darkness of the water will increase with its depth. This phenomenon is called absorption. This shader was projected to be a volume shader, but as the meshes returned by the simulator are not volumes, this idea is not applicable. Instead, this shader calculates the distance from the water surface to the seaoor in order to calculate the quantity of energy absorbed. The distance is calculated using the direction of the refracted ray from the water surface so it will be longer or equal than the perpendicular distance from the water surface to the seaoor. [EC05] Figure 3.5 shows the scene using absorption but no photon mapping in this case. At this point the reader has to realize that the used shader is not the transparent 3.5 Phong reection model 15 Figure 3.4: Left: Visualization of the photon maps. Right: Render of the scene using a transparent shader with photon mapping. The caustics can be appreciated at the seaoor one anymore. Now is where the bounding box makes sense, because the only way in which can be light is inside the water is through the surface. In other words, the light that reach the sea bottom is because of the photons that have crossed the water. Afterwards, the light inside the water may not reach the surface again due to absorption, which will determine the nal aspect of the water. 3.5 Phong reection model In order to include another property to the simulator, the phong reection model has been used to reect the sun. This model is not the Phong shading model. Its contibution is only the reection of the directional light and it will be appreciated only if the eye, the water surface and the sun are situated in the same plane [Pho75]. Figure 3.6 shows the scene using with phong reection added to the rest of properties. 16 Shading Figure 3.5: This gure shows how the colour of water is aected by absorption. In the left side the depth is lower and the result colour is lighter because of the seawater colour. In the right side of the scene, the colout is darker because the depth is higher. 3.6 Other properties This section explains some other minor properties that have been used along the project. Sun and sky The sky is also important as it is, either completely, or almost part of it, reected by the water. The chosen model for the day light is the one developed by A. J. Preetham, Peter Shirley and Brian Smits at the University of Utah [PSS99]. This model uses real coordinates of the Earth but also the desired date and time. For this project, the chosen date is a day in autumn at 12.00 and it has been located in Denmark. These values can be changed at any time in the framework. 3.7 Final comments 17 Figure 3.6: This gure shows how is the sun reected in the water surface because of phong reection. Antialiasing In order to make the result more accurate and avoid eects as aliasing, most of the generated images have been rendered using multisampling. The framework allows the generation of more than one ray per pixel and it has been used in this project. However, as the rendering time increases very fast, the maximum number of rays per pixel used is 9. For video generation, as it is needed to render a high quantity of frames, only one ray per pixel has been used. 3.7 Final comments As it has been explained before, in the nal version the user can choose between dierent shaders. This is handled in the le ow.mtl and the material used for the water is seawater. Inside this le, there is a value called illum which determines the shader that is going to be used in the renders. By default, this value is set to 15, which is the shader used for ocean water. This shader uses absorption, photon mapping and phong reecion. This shader has been used, 18 Shading for example, in gure 3.7. Other used shader is the transparent one, which can be chosen changing the illumination value to 4. This shader uses a basic transparent shader with photon mapping. This shader has been used in the right image in gure 3.4. Finally, the lambertian shader has been used for the ocean water in gure 3.2 and it has been used for the seaoor in all the renders. In addition, the sun and sky model has been used in all the renders as it is not aected by any of the shaders. The whole pipeline that the user must follow can be checked in chapter 2 Figure 3.7: This gure shows the caustics and absorption. Chapter 4 Results Once the implementation has been completed, three simulations have been run in order to study the time consumption. Two of the results shown here come from renders that have been congured to be a video sequence. The other one has been performed for a single image. This has been done because usually the mesh is plane in the rst frame, and as the time increases, the variations in the meshes are higher and it aects to the render time. The time frequency for all the simulations is 25 frames per second, which is the standard for european televisions. This means that the step time is 0.04 seconds. All the simulations and renders have been performed in my personal laptop. The render times will be lower using a more powerful computer. In addition, in the cases of video sequences, the obtained times have been performed using only one ray per pixel. For more rays per pixel than one, the time is approximately multiplied by the number of rays per pixel. In the case that the render is focused in one single image, the number of rays have been set to 9 in order to get more accurate and nicer images. 20 Results 4.1 Linear travelling Wave This simulation uses only linear techniques to obtain the simulations, so it is expected to be computationally easy. The simulation will generate a sequence of 600 meshes and it will represent a 24 seconds video with a frequency of 25 frames per second. Figure 4.1 shows the time of all the performed steps. Figure 4.1: This table shows the time for the Linear Travelling Wave example In this case, the simulation has taken 0.3 seconds per frame so the total time has been 3 minutes for the whole sequence. The conversion time is also signicant, but this step is faster than the others. In this case, the conversion time has taken an average of 0.07 seconds per frame, making a total of 42 seconds for all the images. The mesh visualized in Matlab and the render result can be seen in gure 4.2 although the outputs of this simulation have been also used in the previous chapters of this document. Finally, the rendering step has taken 8.3 minutes per frame, making a total of 83 hours for the whole sequence. The size of the meshes used in this example is 259 x 2. 4.2 Whalin's experiment Robert W. Whalin, Ph.D., P.E. is Associate Dean and Professor of Civil Engineering College of Science, Engineering, and Technology, Jackson State University. This simulation uses some of the data gathered in the Whalin's experiment 1 . 1 http://coastalhazardscenter.org/people/robert-w-whalin 4.2 Whalin's experiment 21 Figure 4.2: Visualization of the Linear Travelling Wave inside Matlab and after the rendering This simulation will generate again a sequence of 600 meshes and it will represent a 24 seconds video with a frequency of 25 frames per second. Figure 4.3 shows the time of all the performed steps and also the time at dierent points of the simulation. In this case, the size of the mesh is also bigger than in the previous one. Figure 4.3: This table shows the time for the Whalin Wave example In this case, the conversion time has been higher than the previous simulation as the water mesh is bigger, but this step has been again the easiest to compute. Finally, the render time has been 3.5 minutes per frame, making a total of 35 hours for the total of 600 frames. Figure 4.4 shows the mesh visualized inside Matlab and also the nal render. The mesh size in this example is 259 x 19. 28 Conclusions Figure 5.1: Gannt diagram Bibliography [App68] Arthur Appel. Some techniques for shading machine renderings of solids. In Proceedings of the April 30May 2, 1968, spring joint computer conference , AFIPS '68 (Spring), pages 3745, New York, NY, USA, 1968. ACM. [EC05] Xavier Pueyo Francisco J. Seron François X. Sillion Eva Cerezo, Frederic Pérez. A survey on participating media rendering techniques. 2005. [EKBL09] A. P. Engsig-Karup, H. B. Bingham, and O. Lindberg. An ecient exible-order model for 3d nonlinear water waves. J. Comput. Phys. , 228(6):21002118, April 2009. [EKMG12] A. P. Engsig-Karup, Morten G. Madsen, and Stefan L. Glimberg. A massively parallel gpu-accelerated model for analysis of fully nonlinear free surface waves. International Journal for Numerical Methods in Fluids , 70(1):2036, 2012. [JB02] Henrik Wann Jensen and Juan Buhler. A rapid hierarchical rendering technique for translucent materials. ACM Trans. Graph. , 21(3):576581, July 2002. [JL04] Claes Johanson and Calle Lejdfors. Real-time water rendering. Lund University , 2004. [Kaj86] James T. Kajiya. The rendering equation. SIGGRAPH Comput. Graph. , 20(4):143150, August 1986. [Kry05] Yuri Kryachko. Using vertex texture displacement for realistic water rendering , volume 2. 2005. 30 BIBLIOGRAPHY [Lew93] Robert R. Lewis. Making shaders more physically plausible. Technical report, Vancouver, BC, Canada, Canada, 1993. [NJC00] Henrik Wann Jensen Niels Jørgen Christensen. A practical guide to global illumination using photon maps. 2000. [PH04] Matt Pharr and Greg Humphreys. Physically Based Rendering: From Theory to Implementation . Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2004. [Pho75] Bui Tuong Phong. Illumination for computer generated pictures. Commun. ACM , 18(6):311317, June 1975. [PSS99] A. J. Preetham, Peter Shirley, and Brian Smits. A practical analytic model for daylight. In Proceedings of the 26th annual conference on Computer graphics and interactive techniques , SIGGRAPH '99, pages 91100, New York, NY, USA, 1999. ACM Press/AddisonWesley Publishing Co. [Ska06] Johannes Skaar. Fresnel equations and the refractive index of active media. Phys. Rev. E , 73:026605, Feb 2006. [SS92] Kelvin Sung and Peter Shirley. Graphics gems iii. chapter Ray tracing with the BSP tree, pages 271274. Academic Press Professional, Inc., San Diego, CA, USA, 1992.