Estos días estoy haciendo unos pequeños cambios en las definiciones ascii de escena. Basicamente estoy incluyendo los datos de las mallas en formato uuencode, con una compresión sencilla usando la zlib. Pero esto me ha obligado a cambiar cómo está organizado el parser.

• Uso el flex y el bison para todo esto. Muchos direis que están obsoletos y todo eso, que probablemente sea cierto, pero tiene ciertas ventajas el trabajar con estos generadores de gramática.

• Leen de forma secuencial, lo cual es muy interesante para cualquier tipo de definición de escena con proporciones considerables. Por ejemplo, leer xml en forma secunecial se vuelve un poco complicado, con push/pops para estados, etc. Con un parser de este tipo, van llegando los "comandos" que van generando las definiciones.

• flex++ y bison++ no usan ninguna lib adicional ni nada parecido. Tienen un cpp/h que usan de plantilla para generar el verdadero cpp/h que va a parsear nuestro código. Está orientado a c++, con lo que te genera una clase que despues podemos extender como deseemos, facilitando mucho la inclusión de nuestro parser en la arquitectura.

• Hay muchisima documentación para estos formatos, especialmente en comp.compilers

• Si nuestra escena es sencilla, los ficheros para generar el parser son realmente pequeños. Realmente todo lo que hace el parser es generar un arbol en memoria con las entidades, y en esto no se diferencia de otro sistema. Lo bueno es que un parseador de este tipo es muy robusto una vez definido. Por ejemplo, no defino palabras clave, simplemente se genera un diccionario de "keywords" que el arbol trata como parámetros para la posterior creación ( objeto = Factory(keyname) )

•  Podemos  realizar cálculos en el mismo parser, como evaluar operaciones matemáticas, etc, abriendo paso a poder optimziar la escena según la vamos leyendo.

 Y la gran ventaja es que siempre puedes ir complicando cuanto desees la gramática (cosa que los informaticos siempre deseamos hacer), para admitir nuevas reglas, que por desgracia, suelen ir apareciendo. El parser te da la abstracción necesaria para que las reglas sean lo suficientemenete genericas para que podamos insertarlas donde deseemos.

Comentarios

Añadir nuevo Buscar

- pplux - ... y que tal lua ?     | 158.42.186.xxx | 2008-02-12 15:20:43 un lenguaje de script como lua, que supersimple de embeber es ideal para hacer este tipo de cosas. Wrappeas cuatro llamadas, que en lua todas tienen la misma signatura de cara a C, y a funcionar! Citar 1   0

Martin BR   | 80.25.232.xxx | 2008-02-12 16:50:50 Pienso que ya que te has decidido por un formato ascii de escena, porque inventarte uno cuando tienes la definicion de escenas de COLLADA? Desde cualquier editor 3D, que lo soporte, podrias cargar escenas. Citar 1   2

- Anónimo - re:   | 80.25.232.xxx | 2008-02-12 16:52:24 Hechale un ojo a http://www.khronos.org/collada/presentations/sailing_the_gulf/COLLADA-Chapter4.pdf Citar 0   0

- ProD - No usar XML     | 80.33.223.xxx | 2008-02-12 17:01:41 COLLADA es un formato que usa XML y si no quiere usar XML pues no le sirve de nada. Citar 1   1

derethor   | Super Administrator | 2008-02-12 17:16:09 son varios los motivos para no usar collada. collada es un formato para videojuegos y aceleracion de tarjeta. Tienes propiedades de materiales muy pegados a un "rasterizador". Por ejemplo, yo uso brdf´s directamente, con diferentes capas. Esto no lo tiene collada. Collada tiene mucha info de rigging, que un raytracer no usa, etc. Es un formato xml. Y tiene los problemas de xml para escenas de 500Mb. Los programas para exportar simplemente no estan maduros. Al menos era así hace 1 año. Creo que el nuevo xsi va mejor, pero el de max fue un desastre cuando lo probé. Sobre lua, si, me ha tentado bastante, pero es un lenguaje de scripting, y por ahora, yo solo defino una escena (aunque orientado a comandos, como transformbegin/transformend) Citar 1   0

- Isaac - Ing. en Sistemas Computacional     | 148.233.37.xxx | 2008-02-12 19:49:50 MMMM yo apoyo la decision, los parsers de XML son mucho mas lentos, yo alguna vez hice cosas muy interesantes en Lex y Jacc(Flex/Bison)creo que son de lo mejor para definir gramaticas. Citar 0   0

Rubén Penalva     | 88.25.1.xxx | 2008-02-12 21:34:01 La verdad es que Lex/Flex y Jacc/Bison son una gozada para parsear ficheros. Estuve un tiempo jugando con ellos en la universidad y en el curro, y me sacaron de mas de un apuro :P . Una pregunta que me asalta leyendo esto: "Es un formato xml. Y tiene los problemas de xml para escenas de 500Mb." Suponiendo que lo que hace la escena tan pesada es la malla ¿Si quitas las mallas del xml, sustituyendolas por el nombre del fichero que contenga la malla, no te quitarias ese problema? Citar 1   0

derethor   | Super Administrator | 2008-02-13 00:35:52 ruben, ese problema es menor sin los enormes datos de vertices, etc, pero aparece el de "que significa incluir un fichero en c: en un render de linux", o el de "si estoy rendeando una malla con animacion, tengo un monton de ficheros por ahi distribuidos", a parte de lo incomodo que es tener multiples ficheros (vale, puedo hacer un zip con todo...) Si estuviese en produccion, lo pensaria, pero para un render como el mio, me parece mas practico tener todo en un fichero (me estoy planteando hasta meter las texturas uuencodeadas), porque asi puedo meterlas en un subversion, etc. Citar 1   1

Rubén Penalva     | 195.219.143.xxx | 2008-02-13 11:09:47 Yep. Yo estaba pensando en que si tienes metido en la escena la definicion de la malla (entiendase por ello, vertices, normales, pesos, etc...) no podrias reusar la malla para diferentes escenas. A menos que tengas las mallas en diferentes ficheros y luego las compongas en la escena. De todas formas, esta claro que nuestras necesidades cuando desarrollamos en casa estan bastante alejadas de las de un entorno de produccion (por lo menos en mi caso). ¿Para cuando un foro? :P Citar 2   0

derethor   | Super Administrator | 2008-02-13 11:53:52 sobre los formatos binarios/texto/etc no tengo todavia unaposicion clara en cuanto a produccion creo que hay que diferenciar claramente render de animacion/pelicula de un videojuego. En un videojuego, el modelo es una entidad de por si, con mucha info, etc. En ese caso, para mi es mas normal tenerlo en un fichero separado. En render de produccion, un frame es un frame. Y el programa aplica toda la animacion, etc para generar la malla en ese frame concreto en una posicion concreta en el espacio. Ese objeto no tiene sentido fuera de ese frame (y menos en el mundo moderno donde se aplican deformaciones postanimacion) En videojuegos, lo importante es la velocidad, y eso implica guardar muchos datos en la malla, en la geometria, etc. Porque el motor va a actuar en consecuencia. En animacion, un render se define a si mismo independientemente de como se ha generado, y el unico resultado es el frame final. El hacerlo en ascii tiene la enorme ventaja de poder hacer scripts para generar y modificar la escena de forma muy sencilla (pixar es muy eficaz en este tipo de scripts). Puedes tener un tio que calcule las fisicas e imprima un fichero de texto de posiciones, otro que lea ese texto y coloque geometria y eso lo escriba en python, otro que pille las rutas de las texturas y prepare un zipo antes de rendear, en perl... es un pipeline mas modular. Citar 1   0

Escribir comentario
Nombre:
Email:	No notificar:Notificar:
Website:
Título:
Código UBB:	-color-aguanegroazulfucsiagrisverdelimamarrónmarinoolivapúrpurarojoplataturquesablancoamarillo -tamaño-minúsculopequeñomedianograndeenorme
	Por favor introduce el código anti-spam que puedes leer en la imagen.

Powered by !JoomlaComment 3.12

Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved.