TP3: Escena 3D

Sebastian SANTISI, 82.069

s@ntisi.com.ar

1er. Cuatrimestre de 2007

66.71 Sistemas Graficos

Facultad de Ingenierıa, Universidad de Buenos Aires

Resumen

En el presente trabajo se desarrollo una aplicacion tridimensional com-

pleta en OpenGL, modelando la xilografıa Relativiteit de M. C. Escher. En

la misma el usuario es capaz de moverse por la escena, en modo de primera

persona, interactuando con el escenario.

Indice

1. Introduccion 3

2. Relativiteit 4

2.1. La obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Las gravedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3. La perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4. Lo plasmado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Desarrollos algorıtmicos 7

3.1. Polıgonos concavos, PyPolygon2tri . . . . . . . . . . . . . . . . . . 73.1.1. Ear cutting . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.3. Bugs conocidos . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2. Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. Movimientos en primera persona . . . . . . . . . . . . . . . . . . . . 103.4. Texturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5. Solidos de revolucion . . . . . . . . . . . . . . . . . . . . . . . . . . 123.6. Solidos de extrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.7. Escena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Trabajo final 15

4.1. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.1. keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.2. poly tri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.3. bezier y bspline . . . . . . . . . . . . . . . . . . . . . . . 154.1.4. converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.5. vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.6. gravity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.7. first person . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.8. textures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.9. revolution x 3 . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.10. personaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.11. extrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.12. scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.13. stars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.14. tp3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2. Iluminacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. Trabajo a futuro 21

2

1. Introduccion

Este informe corresponde a la documentacion del trabajo llevado adelante paraconcretar la construccion de un programa capaz de modelar en tres dimensionesla xilografıa Relativiteit de M. C. Escher.

Encararemos la construccion del proyecto desde tres perspectivas diferentes

El analisis de la obra, donde describiremos las diferentes tecnicas que se aplica-ron sobre los originales, para poder definir el tipo de herramientas a utilizaren la construccion, de manera que fuera viable desarrollar la escena.

El analisis de las herramientas desarrolladas, para poder concretar el armadofinal del programa.

La descripcion del programa, con sus respectivas clases, interfases y jerar-quıas funcionales; y, tambien, el uso del programa desde el punto de vistadel usuario.

A diferencia de en otras entregas realizadas para esta materia, esta vez nose ahondara en todo el detalle que harıa falta para explicar correctamente todolo desarrollado. Apenas se entablara una conversacion a modo de paneo general,para poder explicar como se realizo la construccion. Se toma esta decision por lagran extension que tendrıa un informe que llevara cuenta del detalle. Realmente,se desarrollaron muchos conceptos, estrategias y herramientas para poder llegar aeste trabajo final.

3

http://img407.imageshack.us/img407/4096/escherrelativitywoodcutdf9.jpg

Figura 2.1: Relativiteit (Relatividad), M. C. Escher, 1953. Grabado sobre made-ra, 11”x12”.

2. Relativiteit

Relativiteit (Relatividad) es un famoso grabado (figura 2.1), realizado en 1953por el holandes Maurits Cornelis Escher (1898–1972). Cronologicamente con eldesarrollo del trabajo, empezaremos por el analisis completo que se hizo sobre laobra y los fundamentos para el diseno de la aplicacion desarrollada.

2.1. La obra

La obra madura de Escher se caracteriza por la busqueda de la paradoja ma-tematica, de la ilusion, de lo imposible. Su obsesion radica en la repeticion, lafusion y en explorar de diferentes maneras las fallas que tiene el modelado bidi-mensional de escenas tridimensionales. Escher se caracterizo por ser un excelenteilustrador; pero en su obra tardıa, la ilustracion es solo el medio para evidenciarsus absurdos logicos.

Se quiso rendir un homenaje a Escher desde la realizacion del presente trabajo;por lo que se eligio una de sus obras para ser llevada al modelado 3D. De entretodas las obras de M. C. Escher, se eligio Relativiteit. La eleccion de dicha obrase centro en que es una de las pocas obras de su carrera que muestran la ilusiondel punto de vista de la perspectiva, pero que, ademas, representan una escenatridimensional real; es decir, mientras que muchas de las obras de Escher represen-tan absurdos conseguidos con puntos de vista forzados, el absurdo de Relativiteit

esta dado por lo subjetivo del observador.Si bien esta no es la unica obra de Escher que juega con la subjetividad de la

observacion, parecio la mas rica para explotar desde diferentes perspectivas comouna integracion de los contenidos del curso de Sistemas Graficos. Se eligio la versionxilografica, la cual tal vez no es la mas conocida de las dos que realizo Escher, porconsiderar que era posible realizar una reproduccion fiel de los cortes en la madera,los cuales son mucho mas geometricos que los de la version en litografıa de la obra.

Relativiteit representa una conjuncion de tres mundos en un unico espacio.Cada mundo pende de una gravedad distinta y los tres coexisten ajenos unos deotros en las escaleras del mismo edificio. Cada personaje pertenece a una de estasgravedades y no puede escapar de ella; circulan abstraidos por la suya y parecenno reparar en las demas. Siguiendo la obra de Escher, es evidente que la paradojafilosofica de Relativiteit es la inversa a la de otras de sus obras que giran en tornoa espacios de Moebius. Desde el punto de vista teorico de la perspectiva, juega aconfundir el cenit con el nadir; hecho que se ve agravado por la existencia de trespuntos de fuga y ninguna direccion predominante en la escena o un punto de fugacentral que prioricen una orientacion.

4

http://img46.imageshack.us/img46/906/pyopengleschersrelativiak5.png

Figura 2.2: Analisis de los diferentes planos de la obra.

2.2. Las gravedades

El primer trabajo que se realizo sobre la xilografıa, fue el de intentar separarde alguna manera las gravedades, para poder realizar un relevamiento coherentedel espacio ocupado por los diferentes elementos. Para poder distinguir claramentea las gravedades, se pinto de un color diferente a cada plano segun su gravedad(figura 2.2). Mas tarde, al realizar la escena, se construyo a la misma respetandola coloracion original del primer acercamiento a la obra; por lo que este primeranalisis influyo bastante en el resultado final de la escena.

En la escena coloreada se realzaron un monton de detalles que en la escenamonocroma estaban velados, permitiendo entender realmente la precision del jue-go de los tres mundos. En base a la observacion de la misma se comenzaron aesbozar y poner a prueba las herramientas que conformaron el desarrollo final. Lasobservaciones mas importantes fueron dos:

Solidos de extrusion. La escena completa podıa descomponerse en solidos derevolucion1, cada uno de ellos atado generalmente a una direccion unıvoca.A partir de este temprano hallazgo se evaluo que era viable el describir a laescena desde el bajo nivel, sin recurrir a herramientas de modelado 3D; ladescripcion se realizarıa definiendo perfiles y profundidades de extrusion.

Cada gravedad como mapa de alturas. Salvo pocas excepciones, el espaciotransitable por el personaje de una gravedad no se superponıa en diferen-tes niveles. Es decir, el escenario podrıa ser pensado como curvas de niveldel espacio tridimensional con mınimas intersecciones entre niveles; un casoapenas mas complejo que el de viejos juegos tridimensionales en escenariostridimensionales, como por ejemplo Doom. Este descubrimiento harıa po-sible el poder permitir la navegacion libre por la escena de personajes dediferentes gravedades; simplemente bastarıa con escribir el mapa de alturasde cada gravedad.

En base a estas observaciones, se comenzo a construir un modelo que pudieradescribir la realidad del escenario.

2.3. La perspectiva

Con la tesis de la viabilidad de los solidos de extrusion demostrada, comenzo aser necesario relevar en detalle la escena completa. Para ello se procedio a “desar-mar” la perspectiva para obtener las dimensiones y proporciones del escenario.

El metodo aplicado para deshacer la perspectiva aplicado fue el inverso al apli-cado al plasmar un volumen en un plano bidimensional (figura 2.3). Se buscaron

1Si bien la mınima division podrıa haber sido el paralelepıpedo, el hallazgo fue el haber

encontrado una estructura mas compleja que cuajara con la escena.

5

http://img254.imageshack.us/img254/4539/pyopengleschersrelativing0.png

Figura 2.3: Lıneas guia aplicadas realizando el camino inverso de la generacionde la vista en perspectiva.

http://img526.imageshack.us/img526/1782/pyopengleschersrelativiee5.png

Figura 2.4: Vista final del programa en modo perspectiva de camara esferica.

los puntos de fuga de las direcciones principales, y mediante muchas lineas auxilia-res, medidores, intersecciones de diferentes planos ortogonales, etc.; fue lograndoserelacionar las diferentes posiciones de los puntos de interes hasta poder completarla escena completa. Se aplico la misma neurosis obsesiva de Escher (o mas) paralograr obtener proporciones fieles a las del modelo original.

Del muestreo de la perspectiva fue importante el descubrir que la metrica deldibujo es el escalon. Utilizando ese patron, todas las alzadas y pedadas son delmismo tamano, y los anchos son medidas enteras, al igual como la mayor parte delos objetos; apenas un par de objetos puntuales se escapan a esto.

Del aprovechamiento de esta singularidad enunciada, se desprendio la unidadde representacion del dibujo y se pudieron simplificar muchas variables asociadasal movimiento del observador en el dibujo.

2.4. Lo plasmado

El trabajo final reproduce con exactitud los edificios visibles en la escena (fi-gura 2.4). Salvo el haber obviado detalles de los marcos y puertas, tambien se hanreproducido con exactitud cada una de las texturas del grabado original. Origi-nalmente, la escena incluıa a los personajes que se observan en la xilografıa, peroluego, por acotar el trabajo, fueron retirados de la misma; si bien esta realiza-do parte del desarrollo y estuvieron presentes en demostraciones tempranas delproyecto.

En la vista externa a la gravedad, se muestra completo el edificio original,con agregados que repiten las paredes inconclusas del grabado, para llevar toda laescena a un volumen cubico. No se representaron las vistas del paisaje exterior.

En la vista en primera persona se completaron varias paredes y jardines parano dejar al observador mirando a precipicios. Se completo el ambiente con un cielodetallado, que quita la sensacion de vacıo de la recorrida contra un fondo negro.

6

3. Desarrollos algorıtmicos

Mientras se construıa la escena, fue haciendose necesario el desarrollo de di-versas herramientas y mecanismos que fueron dandole soporte al proyecto queemergıa. Se intentara en esta seccion describir con diversos grados de detalles lasherramientas desarrolladas.

3.1. Polıgonos concavos, PyPolygon2tri

Al comenzar a desarrollar escaleras representadas como extrusiones de polıgo-nos, la primera limitacion contra la que se choco en OpenGL fue debido a la inca-pacidad de dicha biblioteca de renderizar polıgonos concavos. Se intento utilizar lautilidad GluTesselator pero fue evidente que la misma esta “rota” en los paquetesde OpenGL (no ası de Mesa). Luego de intentar infructosamente por horas encon-trar una manera de hacer funcionar las funciones de la familia de GluTess* bajoOpenGL, se decidio implementar algoritmos de triangulacion de polıgonos.

El primer intento de salvar el problema consistio en buscar implementacionesde triangulaciones en internet. Se encontraron realmente muy pocas y en diver-sos lenguajes de programacion. Sin comprender su funcionamiento, se realizo latraduccion a Python de todas ellas. Lamentablemente ninguna de las bibliotecasfunciono renderizando sin errores polıgonos de las caracterısticas de los que setenıan en el trabajo.

El paso siguiente fue leer bastantes trabajos y papers centrados en la triangu-lacion de polıgonos para poder evaluar y comprender cual era el funcionamientode los algoritmos aplicables y cual convenıa para el caso desarrollado.

Dado que los solidos no tenıan huecos, y dado que la cantidad de vertices noera muy grande y que para el perfil de escalones era probable que no se necesitaranmuchas iteraciones para encontrar un triangulo, se determino que la solucion masrazonable era aplicando el algoritmo de ear cutting.

3.1.1. Ear cutting

El algoritmo de ear cutting es un tıpico algoritmo avido. El mismo consiste enbuscar orejas en el polıgono, dibujarlas y retirarlas del mismo, dando lugar a unnuevo polıgono.

Una oreja es el triangulo formado por tres vertices consecutivos los cuales notengan ningun otro vertice en su interior. Un teorema, facilmente demostrable demanera grafica, garantiza que todo polıgono tiene al menos dos orejas.

Si bien el orden de complejidad de ear cutting, en el peor caso, es evidentementecubico; el mejor caso es cuadratico. La configuracion de los polıgonos del trabajo,al consistir en escalones, garantiza un orden practicamente cuadratico.

3.1.2. Implementacion

La implementacion final, la cual se libero bajo el nombre de PyPolygon2tri (opoly tri.py); esta basada en la implementacion poly tri.c de Reid Judd y ScottR. Nelson de 1988.

7

Como ya se dijo en un primer momento, todos los intentos por traducir aPython las implementaciones ya existentes, evidenciaron defectos en las mismaspor lo que los polıgonos de nuestro problema no fueron triangulables. Con loselementos adquiridos luego de leer la teorıa del tema, fue posible corregir los bugs

de las versiones anteriores. Se eligio esta version por la sencillez, eficiencia y porsu carga historica.

El algoritmo basico esta implementado como

Input: Polıgono

Orientacion ←− OrientacionDe(Polıgono);while Longitud(Polıgono) > 3 do

foreach Vertice in Polıgono doTriangulo ←− TresVerticesConsecutivosA(Vertice);if OrientacionDe(Triangulo) = Orientacion then

if EsOreja(Polıgono, Triangulo) thenImprimir(Triangulo);Eliminar(Polıgono, Vertice);

end

end

end

end

Imprimir(Polıgono);

El calculo de la orientacion se obtiene sumando el tamano (con signo) del pro-ducto vectorial de cada vertice consecutivo (igual a dos veces el area del trianguloque forman con el origen). De este modo, es claro observar que las aristas queavanzan de manera horaria mirando desde el origen dan un aporte positivo y lasantihorarias uno negativo. Si la suma de los aportes negativos es mayor que lasuma de los aportes positivos, entonces el polıgono gira en sentido antihorario. Sisumara positivo, entonces gira en sentido horario.

Para cada conjunto de vertices consecutivos; si los mismos tuvieran el mismosentido de giro del polıgono, entonces su area esta orientada hacia el interior delmismo. Caso contrario, no contienen al polıgono y no pueden constituir una oreja.

Para ser una oreja, ademas de estar orientada hacia el interior, no debe contenermas puntos; si cumple las dos condiciones, entonces se renderiza ese triangulo y seretira del polıgono la oreja, es decir, se elimina el vertice interior.

La implementacion se vale de una funcion callback para realizar la impresion,por lo que es independiente del trabajo sobre OpenGL.

3.1.3. Bugs conocidos

Si bien la implementacion trabaja bien con una gran variedad de formas conca-vas, no se pudo determinar la causa por la que falla con perfiles que tienen conca-vidades en todas sus caras. Se supone que hay un error de redondeo de signos endeterminantes cercanos a 0.0, por lo que no se esta detectando correctamente lainclusion de puntos dentro de un triangulo.

8

El resultado de este problema es que se consideran orejas aristas con puntosinteriores y se rasterizan llenas concavidades.

Se espera poder corregir el bug a futuro; pero no afecta al trabajo presentedado que se redefinieron las listas de puntos para evitar el disparo del error.

3.2. Escenarios

Como se dijo anteriormente, el trabajo permite el desplazamiento del observa-dor dentro de cada una de las tres gravedades de la escena. Para poder realizaresto, fue necesario el describir mapas que indicaran las alturas de los diferentespisos, los obstaculos y los lımites del espacio.

Para el desarrollo de una implementacion sencilla se explotaron las dos pecu-liaridades que se describieron en las secciones 2.2 y 2.3; la escasa superposicion deniveles dentro de una misma gravedad, y la metrica unitaria de toda la escena,respectivamente.

El hecho de que la metrica fuera unitaria, determino la descripcion de los esce-narios segun una suerte de bitmaps ; sabiendo que podrıan aplicarse coordenadasdiscretas para representar el nivel de un area y que los niveles posibles estarıanmuy acotados al ser enteros. El hecho de que la superposicion fuera poca, hizo quecon solo dos mapas por gravedad fuera posible describir la totalidad de la escena.

Los archivos descriptores se desarrollaron en texto plano, en formato ASCII(al igual que los demas descriptores del trabajo). Los mismos consisten en unencabezado, seguido de varias matrices, cuyas celdas representan un area cuadradade un escalon de lado, codificando un numero en base 36 (0..9-A..Z) o un guion(-) para indicar la ausencia de valor, el cual indica la altura de la misma. El mapase traduce en un mapa tridimensional mapeado sobre coordenadas (x, y).

El encabezado son tres lıneas numericas en las cuales el primer valor representael offset en x, el segundo valor el offset en y y el tercer valor el offset en la altura(z); luego una lınea en blanco.

Las matrices describen valores sobre x en sus columnas y sobre y en sus filas.La posicion de arriba a la izquierda de la misma marca la coordenada expresadapor los offsets dados en el encabezado. El valor de cada celda es ajustado segun eloffset en z. Cada matriz se separa por una lınea en blanco, y a la siguiente se leaplican las mismas reglas que a la primera.

Por ejemplo, el mapa

3

7

5

89

BA

CD

-E

representa a una espiral que empieza en la coordenada (3, 7), a la altura de 13(510 + 836), y termina en la coordenada (4, 8), despues de haber dado mas de una

9

vuelta, a la altura 19 (510 +E36). En la coordenada (4, 7) hay dos posibles alturas,14 o 18; mientras que en la coordenada (3, 8) solo es posible la altura 16.

En memoria, este mapa se representa como diccionarios de diccionarios delistas, en donde diccionariox,y es la lista de alturas posibles para la coordenada x,y.

3.3. Movimientos en primera persona

Al comienzo de la animacion del movimiento en primera persona se hizo evi-dente que no era natural el movimiento dado por pasos discretos al activar loscontroles. Se trato de implementar un modelo de movimiento que emulara de unamanera mas realista el movimiento natural de un cuerpo al recibir estımulos.

La solucion que se desarrollo, es el desarrollo de un sistema que responde alos estımulos, y entrega una senal que indica cuanto hay que moverse. Si bien elenfoque matematico fue mas bien intuitivo en las primeras instancias del desarrollo,el mismo fue hecho a consciencia.

La funcion de movimiento responde a un sistema LTI causal el cual acumulaestımulos individuales en el momento en el que los mismos se originan. Cada pedidode movimiento dispara una respuesta al impulso discreta que esta formada por unmuestreo de una decena de puntos del segundo polinomio cuadratico de Bernstein,multiplicado por una cierta constante; es decir, una senal con impulso inicial queluego se apacigua.

El desarrollo guarda un sistema para el avance y otro sistema para la rotacionangular. En cada instante de tiempo se rota lo que diga la senal de rotacion y seavanza en el sentido actual lo dictado por la senal de avance. Los estımulos tienensignos, por lo que un estımulo hacia adelante puede ser contrarrestado por un im-pulso hacia atras, o el mantener constante el estımulo en un sentido hace que sealcance una velocidad de movimiento constante.

Ademas de la nocion de posicion, sentido y los sistemas que describen la evo-lucion futura; el sistema de primera persona tiene una instancia de un escenario(seccion 3.2. En base a ese escenario, se sabe si es posible avanzar en el sentidoindicado.

Cuando se alcanza un lımite del escenario, o se esta ante un obstaculo/abismoinsalvable (solo se puede pasar a niveles que no disten en mas de una unidad dealtura), el movimiento puede seguir produciendose unidimensionalmente, si unade las dos coordenadas todavıa tiene libertad. Es decir, si se llega a una pared demanera oblicua, el avanzar actualizara aun la coordenada perpendicular a la pared,en la misma cantidad que si la pared no estuviera. Se implemento esto tardıamentepara hacer mucho mas aceitada la navegacion y evitar que el personaje se estanque.

Pese a que los mapas del escenario representan un area de un escalon cuadrado,y esta es la medida entera de todo; se guarda un coeficiente de 0,2 en el cual no sepuede avanzar si fuera de ese lımite no hay continuidad con el piso que se transita.Esta restriccion se toma porque la restriccion de clipping mayor a cero de OpenGLcausarıa que las paredes atravesaran el cuadro al llegar a una de ellas de maneraoblicua sin este coeficiente de seguridad.

10

Fue necesario, tambien; imponer una velocidad maxima, la cual esta fijada en≈ 0,8, es decir un valor tal que nunca se pueda dar un paso que sobrepase masde una unidad del mapa de alturas. Si no estuviera esta restriccion, el personajepodrıa atravesar paredes; ademas de que se frenarıa en las escaleras al no podersubir dos escalones por paso.

El sistema completo exporta dos coordenadas, una de posicion y otra de direc-cion de vista; y consta con cinco funciones, una para computar el siguiente paso yotras para avanzar, retroceder, girar a derecha y girar a izquierda.

La implementacion del sistema se realiza sobre una especie de cola. Cada ac-tualizacion de la posicion desencola un valor de la misma y modifica la posicion;en caso de estar la cola vacıa, asume haber sacado un valor nulo. Cada estımulole suma el muestreo de la respuesta al impulso a los valores presentes en la cola,y encola valores nuevos de ser la cola mas corta que el muestreo. La cola tiene sutamano acotado por la cantidad de puntos en el muestreo del impulso.

3.4. Texturas

Para hacer lo mas compatible posible a la aplicacion con instalaciones genericasde Python2, se intento prescindir de bibliotecas de manejo de imagenes, como puedeserlo Python Image Library (PIL).

Al igual que con los mapas de escenarios, se desarrollo un pequeno formato des-criptor ASCII para images, en un formato analogo al raw. Un archivo de texturases una secuencia de texturas separadas por renglones. Cada textura se componede un encabezado y de su informacion.

El encabezado consta de 4 lıneas; la primera es el nombre que identificara ala textura, la segunda es el ancho de la misma, la tercera el alto, y la cuarta elformato.

La textura esta codificada en ASCII, y se implementaron dos formatos dife-rentes, segun la necesidad del presente trabajo. Extender los formatos a mas espracticamente trivial. Dado que se trabajo con imagenes monocromaticas, se im-plementaron modos acordes a eso. Los formatos desarrollados fueron dos

8 bits: El formato de 8 bits, describe una imagen en modo raw, en la cual cada dosbytes ASCIIs se puede leer un numero hexadecimal que representa el valorde color de ese pixel. La lectura se hace de a un pixel por vez, empezandodesde la esquina superior izquierda y avanzando primero hacia derecha yluego hacia abajo, segun el ancho y alto especificado.

4 bits: El formato de 4 bits fue pensado como una simplificacion del de 8 (si bienel formato de 4 es cronologicamente anterior en el desarrollo), cada byte AS-CII es un dıgito de un numero hexadecimal el cual se duplica para obtener elvalor de 8 bits correspondiente. Es decir, el byte 5 representa al numero 5516,es decir, al decimal 85; esta compresion de representaciones esta inspirada en

2Esto, desde ya es un imposible, dado que se hace uso del paquete PyOpenGL, el cual tiene

varias dependencias; pero de todos modos, se busco no agravar esa situacion.

11

otras especificaciones, como por ejemplo CSS, y tiene la ventaja de represen-tar 16 colores distintos, en el rango 0..255, con poco espacio. Se utilizo esteformato porque los mapas monocromos fueron tipeados a mano y eran massencillos de esta forma; tambien se podrıa haber utilizado codificacion PGM,pero hubiera resultado menos versatil a futuro.

Tambien se desarrollaron herramientas (estas sı sobre PIL), para convertirimagenes al lenguaje descriptor desarrollado.

3.5. Solidos de revolucion

Como parte del desarrollo inconcluso de los personajes de la obra de Escher,se plantearon distintos tipos de solidos de revolucion. Si bien en el trabajo final nose termino usando ninguno mas que el mas sencillo.

Los tres solidos que se incluyeron en los codigos entregados, mas alla de los quese descartaron, son

Revolucion simple: Es la revolucion tradicional. Se recibe una lista de puntos decontrol de Bezier o BSpline, bidimensionales, (x, y). Se computa la rotacionde los valores de y a lo largo del eje x.

Revolucion elıptica: Esta revolucion toma dos perfiles; con coordenadas (x0, y0)y (x1, y1). Computa la rotacion de los valores de las yes a lo largo de los valoresdados por x0. En el plano yz se aplican los valores (y0 cos θ, y1 sin θ); es decir,se generan perfiles elıpticos de coeficientes y0 e y1. Es importante remarcarque las coordenadas en x estan dadas solo por uno de los dos perfiles; ası quees de esperar que hayan deformaciones si no son similares los dos perfilesentregados.

Revolucion doble-elıptica: Esta revolucion toma tres perfiles, y genera un soli-do con simetrıa bilateral en base a ellos. Analogamente a como se computa larevolucon elıptica, esta revolucion toma las equis del primer perfil y ponderasegun la formula de ella para 0 < θ < π; para valores de π < θ < 2π utilizalos valores de y del tercer perfil; por lo que se obtiene una seccion formadapor dos hemielipses contınuas entre sı, con el parametro y1 comun a ambas.

En el camino hasta llegar a la ponderacion elıptica pasaron diferentes intentos,como ponderaciones lineales, por Bernstein (la lineal, en realidad, son un casoparticular de Bernstein con grado 2), cuadraticas, ¡y hasta segun parametrizacionesde espirales! Al dar con las parametrizaciones elıpticas se consiguio lograr cuerposde revolucion con continuidad C2, que era lo que se buscaba al experimentar condiferentes ponderaciones.

La implementacion final, para ajustarla a lo pedido, opera sobre matrices; lasimplementaciones iniciales hacıan el calculo de los quads, de las normales y eldibujado on-the-fly. La generacion mediante matrices no solo no complejizo sinoque redujo drasticamente la resolucion de los algoritmos.

Para mayor eficiencia, se generan las matrices en dos pasadas; la primer matrizes la matriz de puntos, y la segunda matriz se calcula en base a la primera con las

12

normales de cada punto. Las normales de las columnas exteriores se calculan contrala fila siguiente; mientras que las normales interiores se calculan interpolando la filaanterior y siguiente a la fila a la que pertenece el punto. Esto hace que cada puntotenga una normal diferente y elimina practicamente por completo el facetado en elsolido final. Las ventajas de hacer el calculo de normales en una segunda pasadason varias; en primer lugar, no hay un crecimiento de complejidad dado que, sibien la implementacion en dos pasadas, se conserva el orden; en segundo lugar, segana muchısimo en la suavidad del solido, dado que se dispone de muchısima masinformacion que la que es razonable llevar en una implementacion en una pasada;y, en tercer lugar, es importante que se puede omitir la generacion de la matriz denormales si no importa renderizar una version solida del objeto.

Desde el punto de vista del diseno, la implementacion del calculo de puntos yde normalizacion disociada hizo posible una herencia muy sencilla entre las tresclases. La clase que genera los solidos de revolucion simples tiene escrita la logicaprincipal; las clases de solidos de revolucion elıptica y doble-elıptica apenas re-escriben las 5 lıneas del algoritmo generador de puntos, dejandole el resto a losmetodos heredados de la clase base.

La interfase de instanciacion de un solido de revolucion contiene los parametrosde posicion y direccion, necesarios para que por sı sola sea capaz de ubicar al objetoen su lugar definitivo.

3.6. Solidos de extrusion

La implementacion de los solidos de extrusion en sı es bastante sencilla y noaporta en mucho describirla. Los solidos se generan para una de las tres dimen-siones, in situ (es decir, no hay transformaciones asociadas); la decision de im-plementarlos de esta manera, si bien poco versatil, parte de tratar de bajar lacomplejidad de la generacion del escenario principal, siendo que su carga es recu-rrente en cualquier contexto de la aplicacion. Los solidos son ortogonales, y generansus dos caras extruidas sobre planos paralelos. Esta claro que la intencion no fue,en ningun momento, la de desarrollar una biblioteca de funciones de extrusiongenericas y versatiles (ademas, para eso existe GLE).

La generacion de un solido se hace a partir de un polıgono que representa sucontorno, y dos coordenadas que representan entre que valores de la direccion deberealizarse la extrusion. Tambien se entregan los nombres de las texturas a utilizary el sentido de las mismas. Las texturas se proveen por cada plano cartesiano;es decir, dadas las caracterısticas del dibujo, se implemento que todas las carascercanas al plano xy del solido tuvieran la misma textura y color, y ası con losotros dos planos.

3.7. Escena

La descripcion completa de la escena, en terminos de texturas, y solidos selevanta de archivos que codifican los volumenes y la manera de representarlos. Elformato es, como cada vez en todo el desarrollo, un archivo ASCII de texto plano.

Cronologicamente, la descripcion de la escena, fue el primer formato que sediseno, y el mas coplejo. En algun momento se penso en hacer el lenguaje des-

13

criptor compatible con PostScript, para poder visualizar con cualquier visor dearchivos los perfiles, pero se abandono pronto la idea. Eso sı, es posible que, enun futuro cercano, se reescriba el formato descriptor y se tome de PostScript elfuncionamiento como arquitectura de stack.

El formato es una serie de extrusiones, separadas por lıneas en blanco. Laslıneas que comienzan con numeral (#) son comentarios. Cada comando o valoresta separado de los demas por caracteres blancos. Cada extrusion tiene un enca-bezado y una secuencia de comandos.

El encabezado es o x, o y o z y dos numeros; en base a eso se describe enque direccion se realizara la extrusion y entre que valores.

Los comandos pueden ser

Puntos: Un punto es una coordenada bidimensional expresada como x,y.

Curvas de Bezier: Una curva de Bezier es el identificador bezier seguido decuatro puntos, siendo ellos sus puntos de control.

Escalones: Una secuencia de escalones se conforma por el comando steps, se-guido opcionalmente de los modificadores down y/o left para indicar quela misma no es ascendente o hacia la derecha, respectivamente; seguido op-cionalmente de los modificadores cutb y/o cute, los cuales indican que sedebe recortar el primero o el ultimo escalon; seguido del numero de escalones,seguido de un punto que representa la coordenada de inicio.

Texturas: Una declaracion de texturas comienza con texture y es seguido porlas declaraciones de textura para x, y y/o z, en ese orden. Cada declaracionde textura es la letra del plano en el cual se aplicara la textura (se entiendepor plano x al plano perpendicular a x; es decir el yz; y analogamente conlos otros dos), seguida opcionalmente de la letra r, que indica que la texturadebe ser rotada, seguida del nombre de la textura.

Reverse: Indica que la lista se esta describiendo en sentido antihorario. Esto esindiferente al usar PyPolygon2Tri (seccion 3.1) dado que la clase de extrusionchequea el sentido de giro dado que “no le cuesta nada hacerlo”, y lo corrigeantes de llamar a la funcion de recorte de orejas (a quien le avisa que ya nodebe volver a chequer el sentido); pero en los sistemas en los cuales funcionanlas herramientas de Tesselator de GLU, estas se utilizan, y pueden quedarnormales apuntando hacia el interior del objeto de no revertirse las listas.

El parser se encarga de ir concatenando en secuencia los puntos, escalones y cur-vas de Bezier. Con ellos y con los parametros de textura fijados, si los hubiera,instancia un objeto solido de extrusion por cada solido descrito.

Puede observarse como la descripcion de la escena no incluye a los solidos derevolucion y superficies generadas con mallas; las mismas se encuentran hardco-deadas en el cargador de escena y se cargan si en el archivo descriptor estan laslıneas revolution o corniza. Esto es algo a ser corregido para proximas versiones;al igual que poder incluir la iluminacion en el lenguaje descriptor.

14

4. Trabajo final

Hasta el momento hemos descrito los principales conceptos y herramientas de-sarrollados para llegar a la concrecion del trabajo. A partir de ahora describiremosalgunos detalles tecnicos de la implementacion, si bien no entraremos en un detalleriguroso de los mismos.

4.1. Clases

Si bien se empezo con el desarrollo del trabajo bastante antes de que el mismotuviera un enuciado definido, el mismo tuvo una extension considerable como parahaber pasado por sucesivos clen-ups, y pese a eso seguir teniendo fallas de disenoimportantes. Hay muchos huecos en la manera en la que quedaron armadas lasjerarquıas y es proyecto a futuro el racionalizar el diseno.

Daremos una breve recorrida por cada uno de los modulos, su implementacion ysu funcionamiento; muchos de ellos ya fueron comentados en las secciones previas.Algunos de los modulos fueron desarrollados, pero no fueron usados en la versionque se presenta; sin embargo seran descritos porque formaron parte del desarrolloy seran integrados a futuro.

4.1.1. keyboard

La clase keyboard es la que encapsula el manejo de los eventos de teclado. Ladocumentacion de la misma se encuentra en el TP2 de esta misma materia.

4.1.2. poly tri

El modulo poly tri encapsula en la funcion draw poly la funcionalidad des-crita en la seccion 3.1. Esta funcion recibe una lista de vertices, un puntero a unafuncion que toma 3 puntos y un argumento generico, ese argumento generico, yla orientacion del polıgono (para no recalcularla en caso de ya haberse hecho) yaplica el algoritmo de ear cutting sobre el polıgono, llamando al callback con cadatriangulo.

4.1.3. bezier y bspline

Las clases bezier y bspline son dos clases estaticas las cuales devuelven uniterador o una evaluacion de puntos, en base a una secuencia de puntos de controly una cantidad de puntos dadas. Las mismas llevan una cache de las evaluacionessobre sus bases hechas en llamadas previas, por lo que sucesivas llamadas con lamisma cantidad de pasos no necesitan recomputar los polinomios generadores.

Para la clase que genera Bezier, de haber mas de 4 puntos de control, los mismosse asumen como una curva continua iterando de a tres de ellos por vez.

4.1.4. converter

Este modulo es una pequeno programa de consola el cual convierte una imagenpasada por argumento al formato de 8 bits de texturas (seccion 3.4), “escupiendo”

15

el resultado de la conversion por stdout. Hace uso de las facilidades de la bibliotecaPIL.

4.1.5. vector

Si bien esta clase termino sin usarse para reducir el overhead en la generacionde vectores, y por no haber tantas aplicaciones en las cuales se justifica su uso, lamisma esta escrita completa y funcional. Se trata de una clase, muy sencilla, lacual encapsula aplicando distintas estrategias de calculo-λ, toda la funcionalidadnecesaria para operar con vectores bi o tridimensionales, representados como untipo n-upla. Estan implementadas todos los operadores y sobrecargas, y el tipo esindiferente para operar contra otros vectores o contra cualquier tipo de Python quesea representable como una secuencia (siempre y cuando coincidan las longitudesde ambos).

4.1.6. gravity

La clase gravity contiene la implementacion del parseo de escenarios explica-do en la seccion 3.2. Una instancia de la clase se crea desde un nombre de archivoy, luego, puede ser invocada con una coordenada instancia[x,y], llamada en lacual devuelve la lista asociada con la coordenada x, y o None, de no haber posiblesvalores de altura para esa posicion.

Se encuentran definidos los archivos gravity x, gravity y y gravity z, lostres de extesion .dat, que contienen los mapas de alturas para cada una de lastres gravedades de la escena.

4.1.7. first person

La clase first person implementa lo descrito en la seccion 3.3. Se instanciadesde la ruta del mapa de alturas que va a respetar, y exporta los metodos ypropiedades ya enumeradas.

4.1.8. textures

La clase textures se encarga de levantar las texturas desde un archivo dadoy de registrarlas ante OpenGL. Luego, la misma al ser invocada con el operadorcorchetes, devuelve el ındice asignado por OpenGL para la textura del nombreindicado.

La clase se encarga de habilitar los parametros de texturas de OpenGL y, a me-nos que se cambie despues, deja seteadas a las textudas segun los filtros GL NEAREST

para mag y GL LINEAR MIPMAP NEAREST para min. Se eligieron estos filtros dadoque las texturas que se repiten en todas las paredes son monocromaticas (y, prac-ticamente, unidimensionales); elegir oros filtros, para mag, hacıa aparecer nuevosvalores intermedios entre el blanco y el negro, y para min, se veıa muy notoriala distancia al observador a partir de la cual cambiaba el buffer de profundidadasociado a la textura, viendose franjas con diferentes texturas. Si bien la texturalineal, sumada a las rayas del diseno de la textura, se presta para un gran efecto

16

de aliasing, fue preferible dicho aliasing a los otros efectos colaterales de filtrossuavizantes.

La textura, por omision, queda en modo GL OBJECT LINEAR; practicamente entoda la aplicacion se usa esta estrategia, dado que la unicidad en la metrica delos objetos tambien se manifiesta en la metrica de la textura. Luego los objetos aldibujarse redefinen la orientacion de GL OBJECT PLANE, pero no tienen la necesidadde setear cordenadas explıcitas dado la naturaleza de la escena.

Se encuentra definido el archivo textures.dat, el cual contiene la descripcionde las 4 texturas que utiliza la aplicacion. 3 de ellas de 4 bits, monocromaticas, querepresentan los diferentes cortes de la xilografıa. Y una cuarta, de 8 bits, en escalade grises (generada con la herramienta de conversion), la cual es una textura dela superficie lunar. Esta ultima textura consiste a la excepcion en el tratamientolineal, dado que se renderiza utilizando GL SPHERE MAP.

4.1.9. revolution x 3

Se proveen tres clases de revoluciones, las cuales ya fueron detalladas en laseccion 3.5. Las mismas se encargan de generar, almacenar y renderizar solidos derevolucion, de revolucion elıptica y de revolucion doble-elıptica.

4.1.10. personaje

La clase personaje no se entrega funcionando en esta entrega, la misma seencarga de renderizar completos a los hombrecitos de la escena, aplicando sucesivastransformaciones de rotacion y translacion segun los angulos de cada uno de susmiembros. La manera de resolver el dibujo es anidada. La rutina de dibujo del torso,llama a dibujarse a la cabeza, los brazos y los muslos, entregandole la coordenadaorigen en el lugar en el cual ellos tiene su pivote. Luego, la rutina de brazo dibujasu antebrazo y la del antebrazo la mano; y la rutina del muslo llama a la pierna yesta al pie. De este modo, se pueden representar a personajes en cualquier posicion.

Los volumenes de los personajes estan descritos con revoluciones doble-elıpti-cas, para dar la apariencia de simetrıa bilateral en los brazos, piernas, antebrazos,muslos, manos y pies; con revolucion simple para el geoide de la cabeza; y conmallas de bezier (provistas por GL) para el torso.

4.1.11. extrusion

La clase extrusion es la comentada en la seccion 3.6, simplemente recibe unalista de puntos del perfil, los nombres de las texturas a aplicar, almacena al objetotextura actual como un atributo estatico de su clase, y se encarga de dibujar losdiferentes solidos.

4.1.12. scene

La clase scene implementa la carga de descripciones de escenas descritas en laseccion 3.7. La misma procesa el archivo de descripcion de la escenas, genera los

17

http://img45.imageshack.us/img45/9899/pyopengleschersrelativifz5.png

Figura 4.1: Captura de un cielo mostrando la Luna, estrellas y una estrella fugaz.

objetos de extrusion necesarios, compila la escena y luego la renderiza.

Se proveen dos archivos descriptores de escena scene.dat, el cual provee laescena presentada por M. C. Escher; y el archivo externscene.dat, el cual pro-vee el completado del escenario para hacer natural la recorida por los lımites delescenario.

4.1.13. stars

La clase stars encapsula el manejo completo de la visualizacion y animaciondel cielo (figura 4.1). La misma se instancia a partir de un centro, un radio yla cantidad de objetos a representar. Luego, se encarga de generar la esfera quecontiene a todos sus objetos, dentro de ese radio con ese centro.

Los objetos que representa y anima la clase son 4

Estrellas: Las estrellas se generan y compilan al realizar la carga de la clase. Poromision se generan 1000 estrellas, las cuales se posicionan de manera aleatoriaa lo largo de una esfera del radio dado. Las estrellas se generan sin textura,con emision blanca al 100 %. Al renderizar la escena, se actualiza el valor dela declinacion del cielo en 0,005◦, por lo que el mismo gira lentamente. Ladeclinacion del cielo ata a las transformaciones de los demas objetos, estadeclinacion, representa la rotacion de la tierra.

Planetas: Los planetas se generan aleatoriamente, con un eje de giro, un anguloinicial y un color (con principal componente en rojo). Se compila un unicoplaneta al generar la escena, y al dibujar se aplican las transformacionesnecesarias para posicionar cada planeta y colorearlo y se dibuja al patroncompilado. En cada redibujado se actualiza el angulo de la orbita de losplanetas en 0,01◦.

Estrellas fugaces: Las estrellas fugaces funcionan de la misma manera que losplanetas. La unica diferencia esta en que son mas complejas las transforma-ciones que posicionan a cada instancia en el cielo, dado que, al tener unacola, las mismas son orientables y no basta simplemente con posicionarlas ensu sitio. En cada iteracion, las estrellas se desplazan 0,1◦.

Luna: La Luna son dos hemiesferas dibujadas como solidos de revolucion, las cua-les forman un globo. Cada una de las dos mitades tiene una componente deluz difusa diferente, siendo una practicamente blanca (un poco azulada) yla otra negra; y teniendo, ambas, una mınima componente de luz ambiente.La esfera tiene aplicado un mapa esferico con una fotografıa de la superficielunar, esta vez con filtros lineales para lograr mas definicion. Esta conforma-cion en dos gajos, da el efecto de dos fases. La esfera gira sobre su propioeje, por lo que la fase de la misma va cambiando en 0,1◦ por iteracion; la

18

textura aplicada como mapa esferico hace que se mantenga en su sitio in-dependientemente de la rotacion de la esfera; por lo que se cumple con laapariencia de iluminacion que pega desde diferentes angulos, dando lugara fases naturales con llenos y nuevos completos. La luna se desplaza a unavelocidad de 0,012

◦

frame, tangencial al movimiento estelar, se mueve apenas

un poco mas rapido que los planetas, dando sensacion de cercanıa.

El radio con el que se esta representando al cielo es de 100 unidades; tomandoen cuenta que la escena llega hasta 30 unidades desde su centro, es muy pocala distancia del cielo a la tierra. Esto provoca que al caminar en linea recta, seavance conra las estrellas, lo cual es un efecto indeseado. No se ha puesto el cieloa mas distancia porque la merma en la resolucion del buffer de profundidad paraobjetos cercanos hacıa estragos con el aliasing de las texturas rayadas. Cambiandolos patrones de texturas del modelo es mas que factible alejar el cielo sin tenerefectos colaterales.

4.1.14. tp3

El modulo tp3 contiene a la clase screen, desarrollada segun el paradigmade diseno fundamentado en el TP2 de esta misma materia. La misma provee lafuncionalidad de alto nivel, dejandole el trabajo a las clases de bajo.

Desde aquı se instancia la ventana y se configuran las perspectivas y puntosde vista; se registran los callbacks de teclado, y se lleva el ındice de los diferentesobjetos de bajo nivel que dibujan la escena.

La clase screen incializa las texturas, los escenarios, las escenas, y genera lasestrellas. Tiene dos modos de funcionamiento, funcionamiento por camara esferica,la cual esta implementada dentro de la clase; y funcionamiento en primera persona,la cual le delega el calculo de las coordenadas de camara a las clases de primerapersona. Cuando funciona en el modo de camara esferica, solo renderiza la escenabasica. En el modo de primera persona, renderiza la escena completada, y tambienrenderiza el cielo.

El refresco de la escena se hace a intervalos constantes. La rutina display, comoprimera accion registra un timer en 50 milisegundos3; como los eventos en OpenGLson bloqueantes, si la rutina de dibujado se demorara mas que el intervalo de timer,el evento de timer esperarıa a que finalizara, por lo que el sistema trabajarıa almaximo de velocidad del procesador. El callback de timer, obviamente, dispara unrefresco de la escena.

Se eligio esta estrategia de refresco de pantalla y no una asociada al callbackde idle, para poder tener una tasa constante de refresco, cosa fundamental paraque la animacion fuera consistente.

3Realmente, no se tiene mucha nocion de la precision de dicho timer. Para evitar lagueos, se

quiso implementar un sistema que tratara de asegurar una tasa constante en diferentes compu-

tadoras; pero dentro de OpenGL se descrubrio que el tiempo de renderizado de la escena era

proporcional al intervalo entre renderizados sucesivos. Es decir; con los 50 milisegundos, la escena

se renderiza en el orden de los 60 milisegundos; pero si se subiera el intervalo a 83 milisegundos,

para garantizar una tasa de 12 frames por segundo, el tiempo de generacion de la escena se alarga

a mas de 100 milisegundos; por lo tanto, es inclusive peor la performance.

19

http://img525.imageshack.us/img525/1795/pyopengleschersrelativivz5.png

Figura 4.2: Vista en primera persona de la escena, con gravedad sobre el eje y.

4.2. Iluminacion

La iluminacion no ha sido un punto fuerte del desarrollo de la escena.La causa de esto es que la generacion de un motor generico que pudiera ren-

derizar escenarios levantados desde scripts externos, provoco, que el manejo deiluminacion quedara externo a la descripcion de los polıgonos. En un modelizadohardcodeado en el codigo fuente hubiera sido trivial agregar diversas fuentes deluz segun los objetos a dibujar, pero agregar esta misma funcionalidad al lenguajedescriptor hubiera complicado exponencialmente los mecanismos del motor.

Por otro lado, la ausencia de calculo de sombras en una o mas pasadas en laAPI de OpenGL hace que, por las caracterısticas de los objetos, un modelo deiluminacion exterior, con luces fuertes, evidencie la ausencia de luces, dando unaapariencia antinatural.

Es por esto que la iluminacion se limito a dos modelos de iluminacion diferentes.La fuente principal de luz es el observador; quien va iluminando con su vista... estoresuelve el problema de las sombras, dado que no deberıa ver ninguna si el proveela luz; y crea una atmosfera agradable al realzar los objetos con emision total quese encuentran en el cielo. La otra iluminacion surge de la Luna; quien iluminade manera difusa el espacio; si bien esta es una iluminacion tenue, la misma esperceptible en la escena, y da una ambientacion razonable al espacio.

4.3. Funcionamiento

Los controles de la aplicacion se realizan desde el teclado, mas que nada poruna simplificacion en la operacion al momento de desarrollar; es probable que seevolucione hacia controles con mouse a futuro.

Los modos de funcionamiento, como ya se describieron, son dos; vision esfericay primera persona (figura 4.2).

En el modo de vista esferica la camara rota lentamente describiendo un cilin-dro con respecto al centro de la escena. Los controles asociados al modo sonlas teclas j, l, i y k, las cuales giran hacia izquierda, derecha, arriba y abajo,respectivamente; controlando las dos primeras el angulo de giro sobre al ejez y las dos ultimas el angulo con respecto al plano xy. Se accede al modo devista en perspectiva con camara esferica mediante la tecla p.

En el modo en primera persona la camara se ajusta al punto de vista de unobservador dentro de una de las diferentes gravedades. Se selecciona uno delos tres modos en primera persona mediante las teclas x, y y z, asociada cadaletra con el plano sobre el cual se manifiestan las alturas del escenario. Loscontroles vuelven a ser i, k, j y l, esta vez representando avance, retroceso,giro a izquierda y giro a derecha, respectvamente.

Para salir de la aplicacion se puede presionar la tecla q o ESC, en cualquiermodo de funcionamiento.

20

5. Trabajo a futuro

La aplicacion fue acotada para poder se entregada dentro de los plazos de lamateria. Pese a las cotas que se impusieron, su desarrollo llevo mas de un mesy medio de trabajo sostenido; se estima que al trabajo le falta un mes mas dededicacion para llegar a una version pulida.

La idea es publicar la aplicacion, por lo que se espera poder mejorar los detallesque quedaron pendientes. Terminar la inclusion de personajes, agregar mas objetosen la escena, mejorar el modelo de iluminacion, pulir los modelos de objetos, etc..

Se considera, de todos modos, que la presente entrega tiene una madurez sufi-ciente como para ser expuesta como una primera version beta del trabajo.

21