Esto nace con lo que fue el primer escenario de baires que arme basando me en el terreno ENV de la versión 7 del simulador para colocar las imagenes fotoreales, pero el método de adquisición y la precisión de las mismas no era muy buena.
Paso bastante tiempo y con SAOS por ejemplo, fui perfeccionando el proceso. encontré una buena manera de conseguir fotos precisas como base, y otra manera de colocarlas también de forma precisa.
Con la salida del X-Plane 9 , se incorporo , creo que una de las mejores habilidades del simulador, y la idea nacio de la comunidad, mas específicamente del desarrollador de FS2Xplane, el conversor de escenarios FS a Xplane, y del OverlayEditor, un editor de overlays de DSF , antes que la propia gente de laminar research lanzara el suyo.
Esta característica es la habilidad de soportar texturas del tipo DDS, comprimidas en formatos DTX1, DTX3 o DTX5 y con mipmaps. para los que no tienen idea del tema se las voy a poner facil. el formato DDS , junto con el algoritmo de compresión DTXn y los mipmaps le dan a cada textura una "forma" o "arquitectura" que la deja lista para que la placa de video la tome y la ponga en el simulador, sin tener que procesar NADA!. Esto evita mucho tiempo de proceso y en concusión da mas FPS!
Todo el proceso se hace al generar la textura, y lógicamente esto se hace una vez, y lo hace el desarrollador del escenario. esto realmente reduce los tiempos de carga de un escenario, porque justamente el x-plane al cargar las texturas lo que hace es tomar una por una y modificarla para que la placa de video la pueda usar, y las mete en la memoria ram.
algo curioso es que en este formato , es que si varias texturas tienen la misma revolución y el mismo algoritmo de compresion van a pesar lo mismo, sin importar lo que tengan dentro.
(como algunos saben y si no pueden hacer el experimento, una imagen de por ejemplo 512x512 pixeles, si es toda blanca y la comprimimos en formato JPG , va a pesar considerablemente menos que una foto del balcón de nuestra casa, que tambien tiene esa revolución , también comprimida en el formato JPG. esto es por el formato directamente le dice a la maquina "todos mis pixeles son blancos", en lugar de detallar el color de cada pixel.)
Esto es algo ineficiente... a lo que espacio en disco se refiere, pero es muy eficiente en lo que refiere a performance de aplicaciones por lo explicado arriba.
Además algo muy interesante son los mipmaps. una imagen con mipmap, es en realidad un conjunto de imagenes. Es, la imagen principal y la misma imagen reducida de dos en dos hasta llegar a 1 por 1. por ejemplo si tenemos una imagen de 1024x1024 pixeles, si esta tiene mipmaps, serán entonces todas estas imagenes en un único archivo:
1024x1024, 512x512, 256x256, 128x128, 64x64, 32x43 16x16, 8x8, 4x4, 2x2 y 1x1
Esto aumenta significativamente el peso del archivo (converge siempre a 2/3 del peso original para ser mas preciso) pero ya nos da la misma imagen achicada en varios niveles , lo que nos es muy útil para mostrarla desde lejos en el simulador. para que vamos a estar cargando imagenes de 1024x1024 pixeles si estamos a 1000 km de distancia!!!! o alguna ves les paso que todo el escenario les anda joya pero si miran para la zona del terreno fotoreal , aunque esta muy lejos los FPS caen al piso!.
Esto justamente lo evita, y solo carga la imagen a un 100% cuando estamos directamente sobre ella, lo que aumenta significativamente los FPS sobre terreno fotoreal.
Como experimento de este concepto desarrolle un escenario prueba , que poseía cerca de 300 MB de texturas en este formato de compresion y arquitectura. La fluidez fue espectacular y la verdad me sorprendió mucho. el escenario no se siente y el tiempo de carga son 5 segundos, literalmente. estamos hablando de al rededor de 432 texturas de 1024x1024 pixeles.
Volviendo al tema principal, ya con el formato, el método de descarga y el software necesario para construir y aplicar las texturas, en estos momentos me estoy ocupando de la difícil tarea de descargar mas de 263.000 (si, docientas sesenta y tres mil) imagenes de 256x256 pixeles, son mas de 16.300 (dieciseis mil trescientas) imagenes de 1024x1024 pixeles, que pesaran al rededor de 10 GB en disco cuando ya esten procesadas. (calculo que optimizando las imagenes, y sacando todas las que no sirven, las que cubren agua por ejemplo, vamos a estar hablando de 6 gb en disco)
La idea es cubrir toda la zona de capital y gran buenos aires, desde casi zarate hasta casi la plata.
y sobre esas imagenes voy a colocar todos los aeropuertos (de los diversos autores que hay, para FS obviamente) respetando la posición en las imagenes.
Colocar las rutas mas importantes, para que el transito del xplane pase por ahí. y colocando los objetos mas significativos como edificios , arboles, etc. es un proceso que va a tardar mucho , pero es la cima de lo posible, y siempre apunto a lo mas alto.
Vamos a ver que pasa, lo mas critico es ver como reacciona el simulador a tantas imagnes. Según los autores de xplane, por cada DSF se puede colocar un máximo teórico de 32,ooo imagenes. yo voy a ocupar la mitad. pero el método con que las voy a aplicar utiliza un polígono por cada imagen, que en poca cantidad no molesta, pero hay que ver como se comporta eso en grandes cantidades.
El primer paso es bajar todas las imagenes procesarlas y aplicarlas al sim, luego borrar las que estan sobre el agua y hacer toda la linea costera.
Ya voy al rededor de un 50% de descargadas las imagenes, y calculo que procesar todas las imagenes va a llevar al rededor de 88 horas, son mas de 3 dias y medio procesando imagenes sin parar. (pobre mi pc)
Veremos que pasa y como se comporta. yo le tengo bastante fe al tema. saludos.
