9.1.3  Otros aspectos relacionados

9.1.3.1  ¿Cómo activo una animación?

"¿Cómo puedo activar una animación? He usado la variable clock en mi escena, pero POV-Ray sigue calculando solamente un fotograma."

La manera más fácil es especificar sencillamente el parámetro de línea de comando apropiado en la linea de comando o en el campo de linea de comando en el menú de especificaciones de renderizado (en la versión Windows). Por ejemplo, si desea crear 20 fotogramas, escriba esto: +kff20

Así creará 20 fotogramas con la variable clock yendo de 0 a 1. Los otros parámetros de la línea de comando se hallan en la documentación de POV-Ray.

Ken Tyler también tiene una buena solución para esto :

En el directorio en el que instaló POV-Ray encontrará un subdirectorio llamado 'scenes' y dentro otro, llamado 'animate'. Encontrará varios archivos de ejemplo que le muestran cómo escribir su escena utilizando la variable 'clock'. Todavía necesitará activar el aspecto de animación utilizando un archivo .ini con la información correcta o con los dispositivos de línea de comando. Personalmente, me gusta utilizar el método del archivo ini. Si desea probar, abra el archivo maestro povray.ini desde el menú de herramientas y añada las líneas siguientes:

;clock=1
;Initial_Frame=1
;Final_Frame=20
;Cyclic_Animation = on
;Subset_Start_Frame=6
;Subset_End_Frame=9

Guarde el archivo y ciérrelo. Cuando necesite utilizar el aspecto de animación, simplemente vaya y edite el archivo povray.ini y elimine el comentario a las funciones que desea usar. Lo mínimo que necesitará utilizar son las opciones initial_frame y final_frame para hacerlo trabajar. Una vez finalizado el renderizado de su serie de fotogramas, asegúrese de comentar las variables clock en el archivo ini. Después del renderizado de una serie de fotogramas individuales todavía necesitará compilarlos en el formato de animación que desee utilizar, como AVI o MPEG. Véanse mis »páginas de enlaces para encontrar programas que pueden ayudarle a hacer esto. POV-Ray no tiene la habilidad interna para hacerlo por usted, excepto en la version de Macintosh.

La versión Mac normalmente no utiliza los archivos .ini y carece de cualquier línea de comando, pero en su lugar una interface completamente gráfica. Para activar la animación, escoja el ítem de las especificaciones para el renderizado desde el menú "Edit" (justo debajo de "Preferences", estará titulado como "FILENAME Settings", donde FILENAME es el nombre de su archivo), haga click en la parte de "Animatión", e introduzca la información necesaria en las cajas de texto.

9.1.3.2  ¿ POV-Ray puede utilizar múltiples procesadores?

Respuesta corta: La única manera de ejecutar POV-Ray en múltiple procesadores es ejecutar varias copias de POV-Ray.

Respuesta Larga:

Hacer que un programa utilice flujos de ejecución múltiples no es tan trivial como parece. He aquí algunas razones de porqué es muy difícil hacerlo con POV-Ray:

Un excelente artículo acerca de este asunto se puede leer en »http://www.acm.org/tog/resources/RTNews/html/rtnv12n2.html#art3.

He aqui una respuesta de John M. Dlugosz con útiles consejos:

El motor renderizador de POV-Ray es un flujo sencillo de ejecución, por eso cuando se ejecuta en un dual Pentium Pro (running NT4) el indicador del CPU solamente llega hasta un 50%. POV no usa más de la mitad del poder disponible de la máquina.

Ese es el asunto básico, aunque objetándolo un poco no es exactamente cierto: el motor de renderizado absorbe un CPU completo, pero el editor corre en su propio canal de flujo, y las funciones del sistema operativo (escribir al archivo, actualizar el display, actividad de red, tareas de fondo) se ejecutan en diferentes canales. Esto otorga un pequeño bono, y el sistema usa tanto como el 54% de MIPS disponible cuando lo monitorea. Más importante, el motor es aún muy sensitivo, y la edición u otras aplicaciones no se ven afectadas.

Pero en un renderizado largo, es irritante tener al CPU paralizado la mayor parte del tiempo. ¿Qué puede hacerse para cortar el tiempo de renderizado a la mitad (de 20 horas a 10, por ejemplo)?

Los más simple es correr dos copias de POV en la máquina. Tener una de las copias renderizando la mitad superior, y la otra renderizando la mitad inferior. Luego pegar las dos partes en su editor de imágenes.

Una cosa de la que estar pendiente: No ejecute las dos copias apuntando al mismo archivo INI y al mismo archivo de imagen, ya que se sobreescribirán sus propias salidas y será un desastre. En vez de eso, asegúrese que cada una escribe hacia un archivo diferente.

Para renderizados moderados, puede dejar una copia trabajando en el renderizado largo, y usar una segunda copia interactivamente para continuar el desarrollo en POV.

9.1.3.3  Puedo obtener un renderizado en "wireframe" (malla) de mi escena?

"Hay alguna manera de generar una imagen de salida en wireframe a partir de un archivo de escena en POV?"

Respuesta corta: No.

Respuesta Larga:

Debe entenderse la diferencia existente entre un modelador como 3d-Studio y POV-Ray,  respecto a la manera en que manejan los objetos. Los modeladores siempre usan mallas de triángulos (y otros modeladores usan NURBS que pueden convertirse en triángulos fácilmente). Las mallas de triángulos son extremadamente simples de representar en un formato wireframe: Sólo dibujan una línea por cada lado de triángulo.

Sin embargo, POV-Ray maneja la mayoría de los objetos como entidades matemáticas, no hay mallas de triángulos. Cuando se le dice a POV-Ray que cree una esfera, POV-Ray sólo la maneja como un punto y un radio, nada más (además de las posibles transformaciones de matrices que se le apliquen). POV-Ray sólo tiene una noción de la forma del objeto como una fórmula matemática (puede calcular la intersección de una línea y la esfera).

Para la salida en wireframe, debería haber una manera de convertir esa representación matemática del objeto en triángulos reales. Esto se llama "teselación" -tesselation-.

Para algunos objetos matemáticos, como la esfera, caja, etc, la teselación es bastante trivial. Para otras entidades, como una diferencia CSG, intersección, etc, es más difícil (aunque no imposible). Para otras entidades es completamente imposible: superficies no-planas infinitas como paraboloides e hiperboloides (bueno, en realidad es posible si se limita el tamaño de la superficie a una forma finita; aun así, la cantidad de triángulos necesarios sería demasiado grande).

Han habido muchas discusiones acerca de la teselación en POV-Ray. Pero puesto que POV-Ray es solamente un renderizador, no un modelador, no parece merecer los esfuerzos (añadir teselación a todos las primitivas y CSG sería un trabajo gigantesco).

(Por supuesto que la teselación podría aportar otras ventajas, como la habilidad de simular transformaciones no-uniformes en objetos como lo hacen la gran mayoría de los modeladores de mallas...)

Si sólo desea vistas previas rápidas de la imagen, trate de utilizar el parámetro de calidad de POV-Ray. Por ejemplo, establecer la calidad -quality- a 0 (+q0) puede darle un renderizado muy rápido. Véase también la pregunta sobre la velocidad de renderizado.

9.1.3.4  ¿Puedo especificar la variable IOR -Indice de refracción- para in objeto?

"¿Puedo especificar un IOR -Indice de refracción- variable para in objeto? ¿Hay algún parche que pueda hacer esto? ¿Es posible?"

Respuesta corta: No.

Respuesta Larga:

Hay básicamente dos maneras de definir IOR variable para un objeto: el IOR que cambia sobre la superficie del objeto y el IOR que cambia completamente el interior del objeto.

El primero es físicamente incorrecto. Para un IOR uniforme, simula el IOR físico bastante aceptablemente, puesto que para estos objetos con densidad uniforme la luz se comba en la superficie del objeto y no en otra parte. Sin embargo, si la densidad del objeto no es uniforme, sino que cambia por todo su volumen, la luz se inclinará dentro del objeto, mientras viaja a través de él y no solamente en la superficie del objeto.

Esta es la razón por la que el IOR variable sobre la superficie del objeto es incorrecta y la posibilidad de hacer esto se eliminó en POV-Ray 3.1.

De aqui podemos deducir que una constante IOR es una clase de propiedad de la superficie del objeto mientras que la IOR variable es una propiedad del interior del objeto (como media en POV-Ray). Por supuesto que la interpretación físicamente correcta de este fenómeno es que IOR es siempre una propiedad del objeto completo (ej, su interior), no solamente su superficie (por eso IOR es ahora una propiedad del objeto en POV-Ray); sin embargo, el efecto de una constante IOR tiene efecto sólo en la superficie del objeto y esto es lo que POV-Ray hace al inclinar los rayos.

La simulación correcta para el IOR variable, entonces, sería la de inclinar el rayo dentro del objeto dependiendo de la densidad del interior del objeto en cada punto.

Esto es mucho más difícil de hacer de lo que se piensa. Las razones son similares a las de porqué las transformaciones no-uniformes son tan difíciles de calcular razonablemente (hasta donde sé, no existe renderizador que calcule transformaciones no-uniformes verdaderas; los modeladores de malla sólo mueven los vértices, no transforman el objeto realmente; una transformación no-uniforme verdadera doblaría los triángulos). Más aún: Las transformaciones no-uniformes pueden simularse si el objeto está hecho de muchos polígonos (se pueden mover los vértices como lo hacen la mayoría de los modeladores de malla), pero no se puede simular una vatiable IOR de esta manera.

El IOR variable es (mayormente) imposible de calcular analíticamente (ej, de una manera matemáticamente exacta) por lo menos en un tiempo razonable. La única manera sería calcularlo numéricamente (a menudo mediante el super-muestreo).

El medio en POV-Ray trabaja de esta manera. Ni siquiera trata de resolver analíticamente el color del medio, sino que supermuestrea el efecto del medio a lo largo del rayo y promedia el resultado. Esto puede ser bastante inexacto como lo podemos ver con el método 1 de media (el único que tenía soporte en la versión de POV-Ray 3.1). Sin embargo, se pueden usar varios trucos para hacer el resultado más exacto sin tener que gastar tanto tiempo, con antialias por ejemplo (que usa el método 3 de media en POV-Ray 3.5). Este es un cálculo bastante sencillo puesto que el rayo es recto, POV-Ray conoce los puntos inicial y final del rayo y sabe además que no intersecta con nada a lo largo del rayo (por eso no tiene que calcular intersecciones rayo-objeto en el supermuestreo).

El IOR variable es, empero, una historia completamente diferente. Aqui el programa tendría que emitir MUCHOS rayos a lo largo de la trayectoria del rayo de luz que se inclina. Tendría que hacer los cálculos de interseccion rayo-objeto. Es como tener cientos de miles de objetos transparentes uno dentro de otro (con max_trace_level ajustado a un valor tan alto para que el rayo pasase a través de todos ellos). Se puede probar fácilmente. Es MUY lento.

Uno pudiera pensar... "hey, qué tal simplemente enviar unas pocas decenas de rayos y entonces usar alguna clase de antialias para los detalles, como en el método 3 de media ".

Pudiera funcionar (nunca he visto la prueba), pero pienso que no ayudaría mucho. El problema es la inexactitud del supermuestreo (aún con el uso de antialias). En media no es un gran problema; si una pequeña área sombreada en media no es detectada por el proceso de supermuestreo, el resultado no diferirá mucho del resultado correcto (puesto que el área sombreada es tan pequeña que habría reducido la brillantez del rayo sólo un poco y no más) y probablemente seguiría luciendo bien.

Con IOR esto no es valido. Con IOR incluso las áreas muy, muy pequeñas pueden tener un gran efecto en el resultado final, puesto que IOR puede cambiar drásticamente la dirección del rayo generando así un resultado completamente diferente ( incluso muy pequeños cambios pueden tener mucho efecto si el objeto que está detrás del objeto refractante está muy lejos).

Puede tener efectos desastrosos. El ior puede cambiar drásticamente de un pixel a otro casi al azar, ni hablar de un fotograma a otro en una animación.

Para obtener resultados más o menos exactos se necesitarían muchísimos rayos; sólo unos pocos no son suficientes. Y el envío de muchos rayos es un proceso extremadamente lento.

9.1.3.5  ¿Qué es el mapeado de Fotones -Photon Mapping-?

El Mapeado de Fotones utiliza el trazado de rayos directo (ej, envía rayos desde las fuentes de luz) para calcular la luz reflejada y refractada (llamadas causticas), que es una nueva caracteristica de POV-Ray 3.5.

El texto que sigue es de la página web del programador (Nathan Kopp):

"Mi última divertida adición a POV es el mapa de fotones. La meta básica de esta implementación del mapa de fotones es la de renderizar cáusticas reflectivas y refractivas reales. El mapa de fotones fue presentado por primera vez por Henrik Wann Jensen. Es una forma de almacenar la información lumínica que se recoge en el paso del trazado de rayos inverso -backwards raytracing [sic]- en una estructura independiente de la geometría de la escena. "

Es sorprendentemente rápida y eficiente. ¿Cómo es esto posible si el trazado de rayos directo -forward raytracing- es tan ineficiente? Por varias razones:

  1. El mapeado de fotones se usa solamente para calcular iluminación, ej, valores lumínicos, no para renderizar la escena real. Los valores lumínicos no tienen que ser tan exactos como el renderizado real (no importa si su luz reflejada se "desparrama" un poco fuera de rango; realmente esta clase de "manchado" sucede también en el mundo real (debido a la luz difuminada en el aire), por eso el resultado no es nada fuera de lo real.
  2. El mapeado de fotones se calcula sólo para aquellos objetos que lo necesitan (ej, aquéllos objetos que poseen reflexión o refracción).
  3. Los rayos no son emitidos en todas las direcciones, hacia la escena completa, sino solamente sobre los objetos específicos. De hecho muchos rayos son emitidos en vano, sin que afecten la imagen final en alguna manera, pero debido a que la cantidad total de rayos emitidos es relativamente pequeña, el tiempo de renderizado no se hace inaceptablemente largo.
  4. La propia imagen final se renderiza con el trazado inverso habitual (el mapeado de fotones es un paso de precálculo que se hace antes del renderizado real). El trazador de rayos no necesita utilizar el trazado directo en este proceso (sólo usa los valores de iluminación precalculada almacenados en un espacio).

Como se ve, para que el mapeado de fotones trabaje de una manera aceptable, debe decirle al programa cuáles objetos quiere que reflejen/refracten luz y cuáles no. De esta manera puede mejorar mucho el paso del mapeado de fotones.