|
En el blog de ethernet podemos leer consejos para crear ficheros en memoria. Esto me da que pensar porque muchas veces tenemos que crear ficheros para almacenar datos, y en un entorno de producción, a veces estos datos son e un tamaño considerable. A vecesme he encontrado con escenas que ocupan 7Gb, que hacian que la escena fuese imposible de manejar, y el tiempo de render se disparaba totalmente (mandar 7Gb por la red no es lo más eficiente). En el mundo de los gráficos, los formatos son muy variados, y están muy implicados en el propio desarrollo de la película. Veamos algunos ejemplos. Formatos de ascii. El ascii mola.Se puede abrir, editar, cambiar, etc. Pero tiene un problema: hay que parsearlo. Una idea es usar el XML, que es lo mejor de los dos mundos. Ahora bien. Hay 1 problema para almacenar las cosas en xml. El documento es del tipo <xml>bla bla bla</xml> . O sea, que hay que cerrar el xml. Que pasa si tenemos una escena con 20 millones de poligonos? con definiciones de rigging, texturas incluidas en base64 y todo eso? Pues que la mayoria de los parser petan porque se quedan sin memoria. Los formatos ascii en render han de ser lo más read&drop posible, y el parseo hay que hacerlo mientras leemos la escena. Esto con raytracing nos trae un montón de problemas, ya que el raytracing necesita toda la escena para lanzar el primer rayo... Cómo soluciono eso? me he acostumbrado a usar el tradicional lex/yacc, y una estructura de texto que va pasando datos ascii a binario, y que me devuelve un arbol tipo compilador de operacion->parametros, que despues parseo facilmente. Esto ha conseguido que algo sencillo, como es leer un ascii, ya no lo sea de primeras, pero el paso intermedio de pasar de ascii a un arbol en memoria, y despues parsear el arbol, permite que sea muy facil crear formatos distintos, binarios o no, y que la aplicación pueda manejarlos facilmente. Sobre el árbol me he creado un sistema que permite hacer queries por nombre, de forma sencilla. Con lo que es posible tener funciones del tipo GetValue ( ".configuration.threads" ) o algo como GetValue(".textures[43].width") hace que programar y extender nuevos parametros sea muy facil. Un problema con los ficheros es que cuando metemos una clase nueva, normalmente le damos un ID nuevo, y esto nos hace perder un buen rato agregando el ID a nuestro código, para que sepa que metemos una clase nueva. Como soluciono esto? pues en ascii, los ID´s son realmente cadenas que entran automaticamente en diccionarios globales de "keywords" (todo esto esta muy basado en cómo se escribe un compilador). Y lo que hace el lex/yacc es generalizar esto en un arbol que despues se puede parsear sencillamente. Y lo que hago es crear otro arbol (no duplico datos, solo la estructura), donde se traducen operaciones abstractas (basicamente, insertar una declaración, donde el parametro es el keyword de la declaracion), a nuestro jerarquia de datos. Esto que parece muy complicado, en la practica no lo es tanto, porque es una pequeña libreria que dado un fichero ascii, devuelve un arbol con la escena, que podemos consultar con el GetValue o modificar con el SetValue. Para crear los datos en ascii en los programas de 3D, hay que tener cosas en cuenta. Maya tiene el famoso mel (y ahora el python), y XSI usa vbasic o javascript. Esto hace que sea facil de crear un fichero, pero volvemos a tener otra vez la realidad, que en render tenemos escenas brutales y muy complejas. Maya es muy lento ejecutando mel y crear un fichero ascii tarda un monton, con lo que nos tenemos que pasar al plugin c++ (ya no es tan sencillo). En XSI todo va mucho más rápido, y personalmente me parece muy eficaz para sacarle datos a la escena, pero hay cosas que, increiblemente, dependen de la configuración regional (la coma de los decimales).
|
Noticias 
