Foro x-plane.es

(para ver el Post original sobre \"Escenarios fotorrealistas independientes de la malla\" ir más abajo)

#######################################################################
MALLAS \"SUPER HD\"
#######################################################################

* Descargar Canarias Super HD 3.01: Desde esta web (http://www.x-plane.es/modules/TDMDownloads/singlefile.php?cid=24&lid=144) o desde mi página (http://www.cestomano.com/mas/xplane/#canariasshd) *
(actualizado 4 febrero 2015)


SCRIPTS:

* pintadera 2.4 (http://www.cestomano.com/mas/xplane/#pintadera)

Aumenta el número de triángulos de una o varias celdas del XP10 subdividiendo cada uno de ellos en 4 más pequeños y de similares proporciones (cada vez que se aplique). El uso de pintadera va ligado al uso de rasters de mayores dimensiones (por ejemplo, de 25m, MDT25) para conseguir mejorar considerablemente los relieves. Ver método explicado por Grrr05 en este hilo.

Más información acerca de su uso en el archivo \"leeme.txt\" o en www.cestomano.com/mas/xplane (http://www.cestomano.com/mas/xplane)

* ter2xp10 1.2

Convierte archivos .DSF fotorrealistas creados mediante el G2XPL (celdas de XP9 con malla incluida) a archivos .DSF con malla, autogen, objetos, etc. del XP10 (sólo para usar con XP10). Se puede usar pintadera y los rasters de más abajo para mejorarlos.

Más información acerca de su uso en el archivo \"leeme.txt\" o en www.cestomano.com/mas/xplane

* ter2pol 1.4 (http://www.cestomano.com/mas/xplane/#ter2pol)

Convierte archivos .DSF fotorrealistas creados mediante el G2XPL (celdas de XP9 con malla incluida) a archivos .DSF basados en POL, los cuales son independientes de la malla del terreno (podemos usarlos en XP9, XP10, ... sin afectar al autogen, malla, etc.)

Más información acerca de su uso en el archivo \"leeme.txt\" o en www.cestomano.com/mas/xplane (http://www.cestomano.com/mas/xplane)

* apisonadora beta 2.0 (http://dl.dropbox.com/u/1126231/X-Plane/apisonadora.py)
Apisonadora suaviza las pistas de los aeropuertos que puedan presentar baches, tras haber usado pintadera y rasters de mayor resolución.
Más información en este Post (http://www.x-plane.es/modules/smf/index.php?topic=6626.msg64208#msg64208) (más o menos :D).
(no se recomienda usar... no sirve de mucho)

#######################################################################


Para crear las mallas HD usando el MDT25 (by Grrr05 ;)):

• Crear una carpeta temporal y poner el Pintadera.py y el DSFTool.
• Descomprimir (7z) los dsf del Global Scenery que se vayan a usar para el escenario dentro de la carpeta temporal siguiendo la estructura de directorios de las celdas (carpeta temporalEarth nav data+XX+YYY).
• Arrastrar todos los dsf dentro del XGrinder y cuando termine de extraer todos los .txt y .raw eliminar los dsf.
• Editar todos los .txt (recomiendo Notepad++), al final del archivo hay dos líneas:

RASTER_DATA version=1 bpp=2 flags=5 width=1201 height=1201 scale=1.000000 offset=0.000000 G:X-Plane Toolsst12meshHDearth nav data+40+000+41+003.txt.elevation.raw
RASTER_DATA version=1 bpp=2 flags=1 width=256 height=256 scale=1.000000 offset=0.000000 G:X-Plane Toolsst12meshHDearth nav data+40+000+41+003.txt.sea_level.raw

Los números en rojo se deben sustituir por 3601.

• Sustituir los archivos *elevation.raw por los nuevos de alta resolución y volver a arrastrar todos los .txt al XGrinder y esperar a que aparezcan los dsf.
• Ejecutar el Pintadera (python pintadera.py -x), esperar a que termine y ejecutarlo de nuevo, la segunda vez tarda bastante más.
• Eliminar los .txt residuales e instalar los nuevos escenarios dentro de Custom Scenery, en una carpeta que empiece preferiblemente por Z para darle mínima prioridad.

Una primera ejecución del Pintadera multiplicará el número de triángulos en 4 respecto a la malla original, una segunda 16 veces, y el rendimiento puede quedar bastante afectado, aunque la calidad aumenta notablemente.
A criterio personal.

No he podido comprobar visualmente todas las celdas, pero si alguien ve errores (montañas mal ubicadas o que no se corresponden con las sombras que hay en el fotorreal...) que lo diga para corregir los rasters.

Descargas:

Rasters:
Canarias (http://dl.dropbox.com/u/59143574/rasters/rasters_canarias.7z)
Baleares (http://dl.dropbox.com/u/59143574/rasters/rasters_baleares.7z)
Paralelo 43º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B43-010_%2B43-002.7z)
Paralelo 42º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B42-010_%2B42%2B003.7z)
Paralelo 41º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B41-009_%2B41%2B003.7z)
Paralelo 40º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B40-007_%2B40%2B000.7z)
Paralelo 39º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B39-008_%2B39%2B000.7z)
Paralelo 38º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B38-008_%2B38%2B000.7z)
Paralelo 37º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B37-008_%2B37-001.7z)
Paralelo 36º (http://dl.dropbox.com/u/59143574/rasters/rasters%2B36-007_%2B36-002.7z)



#######################################################################
#######################################################################

POST ORIGINAL:

#######################################################################

Hola!

He dedicado este día a intentar elaborar un script que permita convertir escenarios fotorrealistas ligados a la malla del terreno (es decir, creados con el G2XPL) a escenarios basados en POL (independientes de la malla del terreno). De forma que se puedan utilizar (por ejemplo) en X-Plane 10.

Y bueno, este es el resultado de la primera Beta:

(http://s7.postimage.org/3kw749ufb/c4_2.jpg) (http://postimage.org/image/3kw749ufb/)

(http://s7.postimage.org/5s0fs6zpj/c4_3.jpg) (http://postimage.org/image/5s0fs6zpj/)

(http://s7.postimage.org/bhgoci5vr/c4_4.jpg) (http://postimage.org/image/bhgoci5vr/)

(Tenerife convertido desde el original creado con G2XPL a zoom 18: tiempo de proceso del script, unos 10 segundos)

Hay un par de detalles que, de momento, hay que arreglar a mano (mediante el WED y un programa de retoque de imágenes); ambos inherentes a las líneas de costa:

1º) Los POL de las líneas de costa no son cuadrados y la textura queda deformada. Se puede ajustar fácilmente mediante el WED, aunque voy a darle vueltas a la cabeza este finde a ver si se me ocurre una idea para que se pueda hacer automáticamente.
2º) Las texturas (DDS) de las línea de costa necesitan ser \"recortadas\". Esto es, quitarles el mar.

Esto último es algo obligatoriamente manual. De hecho, cuando he generado escenarios mediante el Gmaps (en formato POL), aunque tiene una utilidad para autorecortar las líneas de costa, termino haciéndolo yo a mano.

¿Ya va eso en marcha?. Estupendo.

Así es! Aunque, ya digo, quedan los dos escollos nombrados. Además, he de probar el script en otras plataformas pues de momento sólo está probado bajo linux: no creo que me cueste mucho adaptarlo, pues está hecho en Python, aunque tengo que tener cuidado con la llamada a DSFTool.

La semana que viene ya podrá convertirse, el que quiera, el fotorrealista de España  ;)

Para windows avisa y hago la prueba.

Lo de las costas hay que revisarlo si o si, porque eliminia de un plumazo la sensacion de fotoreal  :(

Se me han ocurrido esta mañana dos ideas para automatizar la colocación de los POL en las líneas de costa. Una es difícil de realizar y poco precisa; la segunda parece más fácil, pero la precisión... no sé, tengo que verlo, puede que sea buena  :)

Eso sí, lo de recortar las imágenes manualmente va a ser sí o sí. No obstante, yo lo he hecho con el Gimp y se va muy rápido.

No se cuantas imagene sson, pero hacer eso para toda españa puede ser bastante trabajo.....y no somos tantos xD

Lo bueno de el script es que lo pueda ejecutar cada persona en su casa, de manera que no haga falta resubir España fotográfico... salvo por la peculiaridad de recortar las costas. Mmmmm, habrá que hacer números a ver cuántas imágenes son.

Quizá haya por ahí algún algoritmo para borrar mar de imágenes, pero mucho me temo que estas automatizaciones... dejen mucho que desear.

Otra cosa, relacionada con el XP10, es que las imágenes DDS deberían ser reconvertidas con el DDSTool y la opción XP10, pues el valor gamma es diferente. Por eso, las imágenes sobre Tenerife son tan claras en comparación a los objetos.

Veremos...  ;)

Con "guindos" te puedo hechar una mano, así descanso de las puñeteras luces  :'( que me tienen mareado para situar los haces en su sitio

Se me ocurre algo para el script, pero no se si es posible, no tengo ni pajolera idea de Python.

La idea es evitar el uso de .pol encima del terreno de XP10 y usar los .ter de nuestro fotorrealista.
He hecho unas pruebas mínimas, (falta de tiempo) y aparentemente va bien, en el sentido que el XP no se cuelga ni da errores por culpa de la malla.

Según la wiki sobre el uso de DSF, si la malla está definida a una altitud de -32768 (bajo el nivel del mar), el XP10 coge automaticamente las elevaciones desde el raster.

El inconveniente es que o creamos una nueva malla(¿gmaps?) con más triángulos (resolución) o cogemos la malla de la v9 que incorpora nuestro fotorreal y bajamos todos los vértices a -32768.

Si la malla se baja a -32768 y se definen los vectores de normales a 0, la malla creará el volumen a partir del raster y las texturas se mostrarán a modo de proyección sobre el terreno, adaptándose al su contorno. No haría falta modificar las texturas para nada.

Lo que he probado:

Extraer el raster del Global Scenery de la v10

Descomprimir el archivo dsf con el 7zip, y pasar el dsf extraído por el Scenery Tools de Feb del 2012.
Aparecen dos archivos .raw.

Modificar el dsf del fotorrealista de la v9 para incorporar la elevacion por el raster:

Añadir debajo de PROPERTY sim/south

PROPERTY sim/planet earth
PROPERTY sim/creation_agent X-Plane Scenery Creator 0.9a
PROPERTY laminar/internal_revision 1

Añadir debajo POLYGON_DEF lib/g8/beaches.bch

RASTER_DEF elevation
RASTER_DEF sea_level
RASTER_DEF bathymetry

Añadir al final de todo del archivo

RASTER_DATA version=1 bpp=2 flags=5 width=1201 height=1201 scale=1.000000 offset=0.000000 G:\X-Plane Tools\st12\Nueva carpeta\+42-001.txt.elevation.raw
RASTER_DATA version=1 bpp=2 flags=1 width=256 height=256 scale=1.000000 offset=0.000000 G:\X-Plane Tools\st12\Nueva carpeta\+42-001.txt.sea_level.raw

Ni caso de las rutas, se tiene que poner la ruta donde se encuentren los dos archivos .raw que se han extraído del dsf. Una vez convertido de txt a dsf los archivos raw se quedan "enpaquetados" dentro del dsf, y los que se quedan en la carpeta donde se han extraido se pueden borrar.

Borrar todos los parámetros salvo las coordenadas de cada uno de los POLYGON_POINT.
Con el notepad++ la operación la he completado en 5 segundos con la "selección de columna"

Tendría que quedar así:
POLYGON_POINT -0.966670481 42.772081712

Y ahora lo chungo del carallo, en caso de aprovechar la malla de la v9 (se puede omitir este paso si se crea una nueva malla como he dicho antes, con una elevación de -32767);

Modificar todos los parámetros desde el primer BEGIN_PATCH hasta el último END_PATCH para que queden así:
PATCH_VERTEX -0.297501335 42.246665904 -32768.000000000 0.0  0.0   0.230197604 0.557869841
(la selección de columna del np++ no sirve, con un script seria ideal).

Los números rojos por orden son altitud y vectores de normales X y Y.

Las pruebas las he hecho modificando unas 200 definiciones de PATCH_VERTEX.
Aparentemente no hay cambios pero el simulador no da error ni se cuelga como con anteriores pruebas.

Con esto pretendo matar dos pájaros de un tiro, una nueva idea del script que no implicaría pérdida de rendimiento por usar las texturas como .pol y saber lo que es posible hacer con estas nuevas mallas, hasta aqui he visto que se puede crear una nueva malla con ¿gmaps? con mas resolución en cuanto a número de triángulos, y utilizar un raster mas grande para tener un terreno mas bien definido y preciso comparado con la realidad. Creo que lo que se ha hecho con las mallas HD ha sido solo aumentar el número de triángulos en la malla, utilizando los rasters que ya lleva el Global Scenery.

También he probado de usar los .ter y sus definiciones de polígonos unicamente como "overlay", para que se "peguen" al Global Scenery, pero sin éxito, se comen la malla y todo se queda en el vacio.

De todas formas seguiré intentando copiar a saco la malla de la v10 al fotorrealista, por si hay mas soluciones.

Esto no tiene que ser para nada definitivo, es solo una observación, pero utilizar la malla de la v9 con los datos de elevación de la v10 usando rasters, creo que es un pequeño paso, hasta la conversion total (o mejora) de nuestro fotorrealista.

Sea lo que sea que sepais que teneis ciclos de mi cpu a vuestra disposición también (siempre que sea güindous :D).

mmm, esto parece muy interesante. La actualización de los archivos de texto se puede realizar rápidamente medianet script.

Lo que me preocupa es cualquier dependencia de mallas de versiones anteriores, ya sea, por un lado, por la pérdida de precisión en las elevaciones o, por otra, en la pérdida de autogen de la versión 10.

No obstante, lo probaré a ver!  ;) Aún no he probado a trabajar con DSF de la versión 10 y tengo curiosidad...

En otro orden de cosas: sobre el uso de POL, ya tengo encaminado una modificación del script original que corrije el problema de las costas. Veremos cómo acaba.

Y tengo pendiente realizar pruebas de rendimiento entre escenarios POL y TER aunque... de momento no noto la diferencia en rendimiento.

Los datos de elevación del raster deberían ser mas precisos, pero la resolución sería la misma que teníamos con la v9, lo que podria llevar a un terreno mas abrupto e irregular.

Los DSF siguen siendo con formato 800, salvo que están estructurados de forma que puedan guardar los rasters, por eso hay que abrirlos con el último Scenery Tools.

¿Podrías añadir en el script una linea configurable a nivel de usuario para que se pueda elegir si excluir o no el autogen y carreteras?
Yo personalmente lo mandaría a hacer puñetas, ya que utilizo las carreteras de Boke y todo lo que se puede sacar del OSM jeje. No me gusta nada ver mi pueblo como la típica urbanización norteamericana :D

Bufff, acabo de hacer la primera prueba con Tenerife y ha quedado PLANO del todo...

(http://s18.postimage.org/t01m3dnfp/prueba_rasterxp10.jpg) (http://postimage.org/image/t01m3dnfp/)

Y el DSF lo crea bien, carga los patchs del XP9 (fotográfico) pero los raster no... y es lo extraño, así como tampoco los datos del mar (NO HAY AGUA!!).

mmm, indagaré más en ello. Puede ser una buena solución ;) Pero otro día, ahora voy a Mallorca!!

(puedo hacer ambos scripts, uno para crear POl y otro para este, y que cad uno elija)

Bo! Desaparesió er Teide!

¿Has puesto la linea PROPERTY sim/overlay 1?

Es que es muy extraño que un dsf solamente con definiciones de .pol se coma la malla entera...
Tengo entendido que si esta linea no esta presente x-plane lo pilla como si fuera un escenario con malla, y al no estar definida, pues ale, todo al nivel del mar.

Sobre los rasters; no sirve de nada meterlos en el dsf si este no tiene los datos vectoriales de la malla en sí, con todos los vértices a la altitud de -32768 (ese es el indicativo para que x-plane use el raster), en el caso de que estés creando un dsf completamente nuevo.
Como ya sabemos, en la v9 los vértices de la malla tenían la altitud definida en el mismo dsf, pero en la v10 la altitud de cada vértice se calcula a partir de el raster siempre y cuando esten a la altitud mencionada antes y con las definiciones correspondientes de los rasters. Hay que tener una malla definida si o si, por eso comentaba lo del gmaps, por si sería posible crear una nueva malla con más triangulos, para ganar definición, y usar el raster para que nos de la altitud correcta de cada vértice.

Pero bueno, me estoy desviando del tema, yo, por ahora, dejaría el tema de las mallas para mas adelante, para centrarnos ahora en usar las ortofotos como .pol.

No! no he puesto "PROPERTY sim/overlay 1", ¿será eso?

De todas formas, he dejado el DSF tal y como estaba, pero modificando las alturas a -32768 y añadiendo los datos de raster. Lo raro es que ni alturas... ni mar.

Bueno, ya probaré a ver si sale así.

Lo malo del Gmaps es que los servidores que consulta no proveen datos de altura de Canarias (aunque claro, tampoco los necesitamos, teniendo el raster :P) pero bueno, la cosa es poder aprovechar las imágenes que tenemos y no volver a hacer el proceso con el Gmaps el cual, dicho sea de paso, es leeeeeeeeento...

Todo se andará ;)

Lo del overlay 1 es válido unicamente si creas un escenario como tal, con los .pol y cualquier cosa como autogen, etc... pero sin malla.

Lo de bajar los vértices no he podido asegurar que funcione, puede que la prueba se me quedó en un area demasiado pequeña y por eso no vi nada... pero tenía que probarlo.

Con lo del Gmaps no me refería a coger las elevaciones desde allí, si no que una vez leí que tiene una función para añadir más triángulos a una malla existente.

Lo que se necesita para que funcione el raster es una malla del tamaño de una celda y completamente plana, eso es obvio si todos los vértices están a -32768.

El problema es que la malla de la v9 y la v10 tienen pinta de ser las mismas, pero las alturas han sido tratadas de distinta forma, en la 9 ya venían asignadas con el que fuese el programa que utilizaron en Laminar, y en la 10 se procesan a tiempo real partiendo del raster, pero diría que los vértices están en las mismas coordenadas. Lo de que la v10 tiene mas resolución, no me lo creo, eso si, es distinta, un ejemplo muy claro lo he visto en LESU, en la v9 hay una colina muy pronunciada a tocar de la pista. Eso es así en la realidad, pues la montaña ha sido "cortada" para meter la pista, en cambio en la v10 aparece una montañita de nada, se pierde el efecto de cortado y además está a menos altura de la que debería. Puede que el raster sea correcto, pero la falta de vértices en la zona, junto con los distintos algoritmos con los que se procesan mallas de la v9 y la v10 provocan esto, creo...

Es un lio. Para mi lo ideal sería tener una malla cuadrada dividida en triángulos del mismo tamaño, pero en Laminar utilizaron un algoritmo para minimizar y optimizar el uso de triangulos, si a esto sumamos que los datos del SRTM fuera de USA son de una resolución de 90 metros, imaginate. En MSFS siempre se han utilizado mallas con triangúlos iguales por cada celda, el problema; el bajo rendimiento, en parte por falta de optimización de la malla, pero es que o se tiene todo o no se tiene nada... un lio.

Si de algún mode se pudiese crear una malla plana con triangulos iguales, ya sea con meshtool, gmaps o a lo bestia con un script, y esos triangulos pudiesen tener una resolucion de entre 5 y 10 metros, verás que escenarios, ni los HD de Alpilotx :D  teniendo en cuenta que los rasters originales de la v10 tienen una resolucion de 1201x1201 por cada celda, creo que se podria crear un buen terreno con una resolución relativamente alta.

En resumen, para evitar confusiones, el raster sólo tiene datos de elevación y la malla coge estos datos para formar el terreno. El hecho de usar un raster mas grande no influirá en nada ya que el número de triángulos es el mismo.

Pues otra cosa que me interesa, y mucho, es saber en qué formato están los datos raster (ese archivo +XX-YYY.txt.elevation.raw) para poder "jugar" con él (se podría aumentar la calidad creando puntos intermedios por métodos bilineales, fractales, ...).

Sobre lo otro, pues nada, he cambiado algunas cosas, más por prueba y error (y fijándome en los cambios de los DSF del XP9 al XP10) y sigo sin conseguir los datos de elevación... CERCANOS. Y digo cercanos porque a lo lejos sí se aprecian alturas!! Fíjate en esta foto:

(http://s18.postimage.org/55oeo24h1/ELA_07_S_26.jpg) (http://postimage.org/image/55oeo24h1/)

He corregido además los patchs relacionados con el mar, dejándolos como en el DSF del XP10 (sin poner el -32.768) y ahora aparece el agua... pero su nivel queda separado del suelo (se puede apreciar también en la foto).

Por cierto, no he encontrado la referencia a los raster y el dato de -32.768 en la Wiki de Laminar ¿podrías dejarme el enlace de dónde lo viste? Thanks!

http://developer.x-plane.com/?article=dsf-usage-in-x-plane (http://developer.x-plane.com/?article=dsf-usage-in-x-plane)
Está actualizado para la V10.

También te indica el formato de los raster. El formato esta adaptado a los rasters del SRTM, asi que si en un futuro queremos usar rasters del IGN se tendrían que convertir y tratar.

El formato RAW es una imagen sin procesar, como lo que sale de una cámara de fotos digital sin pasar por la compresión. El Photoshop puede manipularlos pero con el Gimp no lo se seguro.

Por lo de las alturas ya si que no se que decirte, pero me parece que lo que se ve en la imagen es la celda contigua sin modificar. Y lo del nivel del mar, supongo que tendrá que ver con el raster sealevel, ay madre como se está complicando la cosa... ¡faltan datos!

Zenkiu!

Formato RAW de cámara de fotos? Muy raro, pues el formato RAW depende de cada cámara... (1 minuto después). Acabo de intentar cargarla con el Darktable y no la reconoce. Voy a mirar el enlace que lo explicará bien ;-)


Pues no, porque se ve parte de la isla y ésta está dentro de la misma celda 1x1. Lo curioso es que si me acerco (free cam) a dicho desnivel, va desapareciendo; es decir, se va alejando...

Nada, lo dicho, a leer y a solicitar más info !!!

Pero qué g*l* soy !!!

Si resulta que me había equivocado de celda al copiar del Global Scenery y, por tanto, de raster!!

Ahora sí que salen las alturas del XP10:
(http://s9.postimage.org/nknnjgw6j/c4_3.jpg) (http://postimage.org/image/nknnjgw6j/)

Eso sí, con las líneas de costa hay que hacer algo...
(http://s9.postimage.org/5x5ul9m97/c4_5.jpg) (http://postimage.org/image/5x5ul9m97/)

Lo bueno es que creo que también se puede mantener el autogen y otras cosas. Voy a probar!

Correcto, cada cámara lo procesa a su manera, el problema de este tipo de archivos es que no tiene cabecera, sin ningún tipo de información. Por eso en el caso del photoshop hay que decirle todos los parametros con los que se ha creado dicho archivo, hay que decirle el tamaño en pixels, la profundidad de color, orden de bytes, etc...
En el caso de los RAW de X-Plane, son de 1201x1201, 16bits de profundidad y orden IBM, es la única configuración que me ha servido para abrirlos. Lo que es raro es que el RAWTherapee (conocido programa para crear fotos en HDR partiendo del formato raw de la misma cámara) no me los reconoce.

Por cierto, la suite FWTools puede abrir esos rasters tal cual, pero no he sido capaz de volverlos a guardar en su mismo formato.

Esto es lo que veo yo, he tenido que aumentar el brillo porque si no no se aprecia nada.
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/raster.jpg)

Es el raster de +42-001 (Pirineos)


Sobre las costas;
Según he visto con unas prubeas, están definidas como POLYGON_POINT, me ha pasado con todos los PATCH de la 10 con sus rasters y los POLYGON_POINT de la 9 en el mismo DSF. La definición de la costa de la 9 corta la malla de la 10, porque no son iguales. Supongo que el arreglo estaria en copiar los POLYGON_POINT que pertenezcan a la linea de costa de la 10, que a saber cuales son...

Sí, acabo de leer la wiki acerca del formato del raster. Está en formato crudo (raw) pero crudo de imagen, no crudo de las cámaras de fotos (que ni siquiera son imágenes). El photoshop y otros programas de retoque los podrán cargar simplemente diciéndole el formato (1 canal de brillo de 16 bits de dimensiones X:Y).

Se puede probar a hacer ampliación de la imagen (2X) con diferentes filtros para que cree puntos intermedios... en fin, un mundo por probar!!

Acerca de lo otro, he conseguido mezclar las imágenes del terreno con todo lo demás (playas, autogen de casas, árboles, carreteras, luces, etc.).

(http://s9.postimage.org/gfe9zzgmj/c4_4.jpg) (http://postimage.org/image/gfe9zzgmj/)

El problema es la costa. Las líneas de costa son las del XP10 (que son buenas) y añade la arena de las playas... pero si el polígono continuo (del escenario fotorrealista del XP9) no llega a las mismas pues queda ese espacio en azul.
(http://s9.postimage.org/nhc7m6k8b/c4_1.jpg) (http://postimage.org/image/nhc7m6k8b/)

Se podría buscar la manera de mantener algunos polígonos de la malla del XP10 original como overlay o algo similar para disimularlo... no sé... (es lo que proponías?).

En fin, todo esto lo he hecho a mano, pero hacer un script que lo procese automáticamente es bastante sencillo. Quedaría, como en el tema de los POL, un problema con las costas...

Ok, a ver que me aclare.

Ests utilizando la malla de la v9 con los datos de elevacion de los rasters de la v10 ¿no?
Las lineas de costa de la v10, ya se ven por el número de vértices.

Ahora nos queda un espacio vacio donde no hay malla ni nada, por lo que un overlay no serviría para taparlo, todo el escenario se apoya en los parches de la malla, y si no hay, pues nada...
Lo suyo sería desplazar los vértices de la malla hasta juntarlos con los de la costa, pero tampoco hay suficientes, y no se terminaría nunca... es algo que doy por imposible.
La otra opción, aun peor, pero mas precisa seria crear nuevos parches de malla en estos espacios, es decir, triangulizar todo este espacio vacio.

Por ahora no se me ocurre nada viable :(


Ampliar el raster no servirá de nada sin aumentar antes el número de triángulos de la malla. El raster actua como un molde, y la malla es el material, si el material no es suficientemente flexible no se adapta bien al molde, dejando espacios sin llenar.

Vale acabo de descompilar un dsf del HD Mesh Scenery y efectivamente, el raster es exactamente el mismo que lleva la v10 (1201x1201x16) y se han duplicado el número de triángulos.

Lo que quiere decir que actualmente es posible crear una nueva malla. Lástima que Bokepacha ya preguntó a Alpilotx si liberaría el código y le dijeron que no, en un principio.

NO hay problema!  ;D

Con el script que tengo para convertir los DSF a formato POL genero efectivamente polígonos (en este caso, rectángulos). Podría hacer una modificación para generar triángulos para adaptarse a la malla. Incluso que calculase el nº de triángulos óptimos dado un raster determinado (y que el usuario pudiera cambiarlo). Naturalmente, la malla no estaría optimizada (podrían haber muchos triángulos en una zona llana, por ejemplo), pero para probar estaría bien. También se me está pasando por la cabeza hacer scripts para agrandar digitalmente los rasters buscando métodos de "invención" de puntos intermedios (Lanczos, bicúbicos, fractales...). En fin, que queda un mundo por investigar.

A ver si me meto con ello la semana que viene y sale algo...

Pues sería genial!

No creo que afecte demasiado al rendimiento el hecho de usar una malla no optimizada, en todo caso el problema seria de RAM como comenta AlpilotX, algo que puede que pronto quede solucionado con el ejecutable de 64bits.

Tampoco haría falta que todas las celdas del pais tengan la misma resolución (en cuanto a número de triángulos), pero supongo que depende de la complejidad del script.

Eso si, si hay una malla "sin optimizar" quiere decir que será mucho mas precisa con el raster, lo que dejará mucho margen para jugar con ellos. Tambíen se ganaría en fiabilidad con los flatten en los aeropuertos, afectando menos al terreno circundante.

El OpenEV de FWTools permite manipular rasters con este mismo formato, con filtros y demás, pero, almenos yo, no he sido capaz de volver a exportarlos, tampoco se puede decir que lo he tocado demasiado.

mmm, tendré que probar el OpenEv...

Por cierto, se me ocurre también una manera bastante sencilla (en principio, en mi cabeza; veremos cuando vaya a pasarla a script...) de ampliar el número de triángulos de un DSF por defecto del XP10; sin tener que tener ortofotos ni nada más. El algoritmo triplicaría el número de triángulos de la malla simplemente subdividiendo cada triángulo en tres. Es decir, sería como crear las mallas HD que ha hecho AlpilotX.

A ver cuántos de todos estos scripts verán la luz al final, jaja

Todos los comienzos son difíciles...  :D

(http://s7.postimage.org/wr9t3vrg7/c4_6.jpg) (http://postimage.org/image/wr9t3vrg7/)

(http://s7.postimage.org/xjch32vnb/c4_7.jpg) (http://postimage.org/image/xjch32vnb/)

Pero bueno, ya está el script "encaminao". Ahora, a analizar porque desaparece uno de cada 3 triángulos.

Que guapo  :D :D :D pero SEGURO  que los conseguireis, BRAVO, sois geniales

The Physical Mesh

The graphical mesh of your DSF can overlap, have holes, or have any number of strange artifacts; what you draw is entirely up to you.

X-Plane extracts part of the DSF mesh to form a physical mesh. Basically every triangle that is in a patch with the 'physical' flag set is copied into the physical mesh. The physical mesh must meet the following constraint:

For any given horizontal location in your DSF there must be exactly one triangle for that point in the physical mesh. In other words, the physical mesh must have no overlaps or holes!
(http://scenery.x-plane.com/library.php?doc=mesh.php (http://scenery.x-plane.com/library.php?doc=mesh.php))


¿Puede ser que al aumentar el número de vértices en cada patch hayan quedado espacios vacios entre ellos o que se esten solapando y creen este mismo efecto?
Por el efecto que crean las texturas en los espacios vacios en la primera captura parece como si la malla se estuviera solapando, aunque en la segunda no se aprecia nada y parecen simples "agujeros" - se ven las texturas originales...

De todas maneras ya va tomando forma y con un montón de triángulos!!  :-i-

Por fin !!!

Al final el problema es que no ordenaba correctamente los vértices al crear los nuevos triángulos.

En fin, queda por hacer, pero ahí van unas capturas:

Prueba 1 (El Hierro): malla por defecto del XP10:
(http://s15.postimage.org/s5dqis0dz/EH1_xp.jpg) (http://postimage.org/image/s5dqis0dz/)

Prueba 1 (El Hierro): malla HD creada con el script:
(http://s15.postimage.org/4pvtdfgmv/EH1_HD.jpg) (http://postimage.org/image/4pvtdfgmv/)

Prueba 2 (El Hierro): malla por defecto del XP10:
(http://s15.postimage.org/8xv6zx7g7/EH2_xp.jpg) (http://postimage.org/image/8xv6zx7g7/)

Prueba 2 (El Hierro): malla HD creada con el script:
(http://s15.postimage.org/r9h93bqpj/EH2_HD.jpg) (http://postimage.org/image/r9h93bqpj/)

Es difícil apreciar los cambios (aunque tb. lo es en el HD de AlpilotX). Fíjense en el Roque de Salmor (montañita en el agua); se nota más "picuda" en la malla por defecto del XP10.

No obstante, aún hay que pulir cosas. Por ejemplo: en las líneas de costa pueden haber cambios bruscos de altura. Otro problema es que si intento iterar una segunda vez (subdividir de nuevo cada triángulo creado anteriormente en 3) da un error el DSFTool. En fin... poco a poco.

Ah, por si alguien quiere hacer pruebas, les dejo enlace al script (versión ALPHA !!!! puede dar errores).
http://dl.dropbox.com/u/1126231/X-Plane/triMesh.py (http://dl.dropbox.com/u/1126231/X-Plane/triMesh.py)

Para ejecutarlo es necesario tener el Python instalado y tener las DSFTool últimas. Al ser un script de prueba hay que hacer varias cosas previas para su correcto funcionamiento:

Lo mejor es crear una carpeta de pruebas que comience con "ZZZ", dentro el Earth Nav Data y la subcarpeta de coordenadas que contenga el DSF que queramos probar (debería funcionar con varios al mismo tiempo). Dentro copiamos el archivo(s) DSF deseado (desde el Global del XP10).

¡¡OJO!! Los DSF del XP10 vienen comprimidos; deben descomprimirse previamente.

Ejecutar el script desde la línea de comandos algo así:

pyhton triMesh.py <susodicho directorio de pruebas> <ruta al DSFTool>

Está probado sólo en Linux................ cuando tenga tiempo lo preparo un poco más.

NOTA: NUNCA ejecuten el script sobre un DSF del Global Scenery, por si acaso.  ;)

A mi no me va :D

Me sale IndexError: list index out of range

y me deja el dsf(txt) a medias, procesa unos cuantos PATCH hasta que se para.

¿Será er güindous?

Si quieres probar, lo he intentado con +42+001 y +41+001 (del Global Scenery v10), ambos por separado.

Y thanks por subirlo (y hacerlo posible) ;)



EDITO: En las celdas de Canarias si que me funciona.

Eso me pasa por probar con celdas tan poco pobladas ;) Debe haberse saturado alguna variable...

De todas formas, hay varias cosas que no tengo contempladas aún en esta versión Alpha, como el procesar primitivas con 7 parámetros (aunque es fácil hacerlo). Lo retocaré, no te preocupes.

También se me estaba ocurriendo poner la posibilidad de poner rangos de Lat/Lon, para ampliar el detalle de la malla sólo en zonas. Lo malo es que el raster se ampliaría (si se quiere) en toda la celda... A ver qué sale!!

Me imaginaba que sería algo así, me daba exactamente el mismo error (linea 111) al hacer una segunda iteración en Tenerife (la primera sin problemas).


¿Que tiene esto de malo? :D

Por cierto ayer hice una prueba con una malla de tu script aumentando el raster 4 veces (2402x2402) y sin problemas oiga!

Cargó perfectamente aunque al utilizar un filtro bicúbico para la ampliación no se apreciaban cambios. Eso si, hay que decirle al dsf la medida del raster.

Bueno, realmente no tiene nada malo, jeje.

Sobre el filtro bicúbico, claro, me imagino que el resultado debe ser similar pues los puntos creados digitalmente son las medias de los adyacentes. Muy grosso modo (asumiendo que se tenga una malla ampliada) significaría que una "montaña picuda" de un sólo vértice, al aumentar el raster, tendría varios puntos más a su alrededor... pero su altura coincidiría con la arista cuando no existían dichos vértices... uy! no sé si me he explicado (pintarlo es más fácil que escribirlo). ¿Quizá probar a hacer algún tratamiento "más agresivo" después de ampliar el raster? O si has utilizado el potochó, ampliar el raster con la opción de "enfocar".

Tengo ganas de llegar a casa esta tarde y hacer montañas de pruebas!!  :)

La intención de la prueba era saber si se podrían mover rasters mas grandes, el bicúbico era el filtro por defecto  ;D.

Sabiendo esto, se me pasa por la cabeza que ya va siendo hora de hacer lo que se hizo en su día con FSX, utilizar los rasters del IGN. Gracias a esto disfrutábamos de toda la península a una resolución base de 25m y en zonas de montaña de 5m, la cordillera cantábrica era espectacular. En el IGN se pueden obtener (previo registro) de forma gratuita los rasters del MDT25 y MDT05, pero hay un inconveniente, son miles de archivos pequeños con formato ASC (ascii) y bajarlos todos es un coñazo.

El problema; como ignorante del sector, no se ni por donde empezar ni como...

De pronto lo que se me ocurre es con algun programa como ArcGIS (de pago) o la alternativa abierta GRASS, confeccionar una celda de 1x1 juntando todos los rasters de la resolución apropiada, al estár georreferenciados no veo mucho problema por la ubicación.

Una vez terminada la confección de la celda, exportar a RAW (tanto ArcGIS como GRASS tengo ententido que pueden hacerlo). Lo que no tengo claro es como calcular la altitud dada segun la intensidad de blanco, los datos SRTM y MDT son distintos.

De momento voy a empezar a experimentar, si es que tengo tiempo, con los MDT200, rasters pequeños que abarcan areas enormes, mas grandes que una celda de 1x1. Si logro una exportación (e importación) correctas podría servir como base para empezar con el MDT25. Un raster de 2402x2042 nos daría una resolucion de 30m, con lo que el tamaño sería suficiente, para una celda con la malla subdividida una o dos veces.

Eso son buenas noticias! No sabía que el IGN tuviera datos con una resolución tan buena.

Sobre conversión, pues bien si lo consigues. Habrá que investigar y probar y probar...

Al ser datos crudos, se me ocurre que también se podría idear un script (avalancha de scripts!) que pudiera simplificar un poco la tarea... pero claro, primero hay que tener bien claro qué se va a hacer (y seguro que lo averiguas).

Voy a echar yo un vistazo a esas celdas donde te daba el error.

Bueno... creo que he logrado algo, compara las sombras de las dos imagenes ;)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalma.jpg)
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalmahd.jpg)

Ambas estan hechas despues de pasrle el TriMesh, pero la segunda además tiene un raster de 3601x3601 confeccionado con el MDT25 del IGN.

He bajado unos cuantos archivos del IGN y los he podido cargar todos a la vez con la demo del Global Mapper con proyección UTM.
Lo mejor es que el Global Mapper me deja exportar por celdas de 1x1 automáticamente el trabajo completo depués de cambiarle la proyección a Geográficas y el datum WGS84.

El problema es que el Global Mapper es de pago y la demo no me deja mucho margen a la hora de exportar, sólo me deja en formato HGT que es el del SRTM (¡ey, el tipo de datos el que utiliza XP!).
Para pasarlo a RAW he tenido que abrirlo con el OpenEV que automáticamente me crea un GeoTiff. Despues lo he abierto con potochó y despues de voltear la imagen verticalmente (importante) la he guardado en formato RAW con 16bits y orden IBM.

Y aquí los resultados, sin problemas (por lo que he visto) en cuanto a las alturas y georreferenciación*, lo que significa que funciona y es posible   ;D
*El raster no va georreferenciado, solo es para la exportación por celdas.

Ahora bien, para aprovechar el potencial del MDT05 habria que iterar unas 3 o 4 veces las malla, y bajarse todos los archivos del IGN... se necesitaria mucho personal, el proceso es lento y doloroso.

Habría que mirarse si este procedimiento se puede llevar a cabo con el GRASS, yo no he sido capaz, y el Global Mapper para mi ha sido como una versión For Dummies, lo que me ha ido de fábula.
El GRASS es más atractivo en el sentido de que es gratuito y multiplataforma.

Cuando tengas el script estable empezaré con mis Pirineos  8)

Guauu!! Vaya si se nota (La Palma?).

Por mi parte, el script lo he tenido que rehacer. El problema es que estaba en un caso muy concreto donde sólo tenía en cuenta primitivas de tipo 0 (triángulos) y las celdas que nombrabas tenían de tipo 1 (tiras de triángulos). Lo estoy rehaciendo para que permita primitivas tipo 0, 1 y 2. Además de patchs con más parámetros y algunas otras opciones (puede que iterar varias veces de una sola vez).

Además, con la posibilidad de hacer sólo zonas determinadas se podrá optimizar la malla (por ejemplo, en los aeropuertos, montañas, valles... dejando los llanos sin procesar).

Hay una cosa curiosa y es que existen patchs físicos (de tipo 1) que tienen algunos vértices con alturas definidas, no -32768. Eso es porque están en la costa. El procesar estos patchs tiene efectos extraños... cosa que también he observado en el HD de AlpilotX.

Subida la versión BETA 1.0 de TriMesh (tengo que cambiarle el nombre...). La anterior era la ALPHA 1.0  ;D

http://dl.dropbox.com/u/1126231/X-Plane/triMesh.py (http://dl.dropbox.com/u/1126231/X-Plane/triMesh.py)

Ésta procesa todos los tipos de primitivas y patches con 5 o más coordenadas. Adicionalmente, se le puede especificar coordenadas delimitadoras de un rectángulo si sólo quisiéramos procesar un área determinada, por ejemplo, así:


Los parámetros que he introducido:
1º) . ==> Directorio de trabajo. Como suelo ejecutar triMesh dentro de la propia carpeta de pruebas, no hace falta ponerla, sólo un punto
2º) ./DSFTool ==> ruta y nombre de la aplicación DSFTool (DSFTool.exe en windows)
3º y 4º) -17.80 -17.90 ==> Parámetros de longitud del recuadro delimitador (no importa el orden, sí importa que los decimales se separen con un punto, no con una coma)
5º y 6º) 28.204 28.208 ==> Ídem para las latitudes

He procesado una zona de El Hierro (aeropuerto) tres veces y el resultado es algo raro... empieza a aparecer un extraño efecto abanico:

(http://s8.postimage.org/5f1x9wc3l/c4_1.jpg) (http://postimage.org/image/5f1x9wc3l/)

No sé si se debe a la falta de datos raster, a la mezcla de éstos con datos de altura explícitos o qué...

También debo revisar el tema de los patches "no físicos" pues no los toco y creo que debería...

Mas imágenes de La Palma   ;)

 Malla por defecto

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalma2.jpg)

 Malla iterada 2 veces con el TriMesh beta1 y con raster del MDT25 (3601x3601)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalmahd2.jpg)

¿Guapo eh?

A la segunda iteración aparecen problemas de sombras y se ve claramente que la resolución del raster no es suficiente, a la tercera se veía exactamente igual.
Dejaría seguro una sola iteración para el MDT25 y ahora que es posible tendremos que averiguar cuantas harían falta con el MDT05, lo que ahora está claro es que es mejor que sobre raster que malla
Y cuidado que el tamaño de los DSF se dispara, el +28-018 me ha pasado de ocupar 2mb a 45mb!! suerte que XP los puede cargar directamente en 7z.

Voy a tener que mirarme a fondo el GRASS GIS para montar los rasters del IGN, el Global Mapper es inviable, aunque es perfecto para esta función, y muy intuitivo, su precio es de unos 400$ y la demo solo permite cargar cuatro rasters simultaneos y dura 15 días. A ver que alternativas salen por ahí.

Por cierto, muy interesante lo del cuadro delimitador!

Brutal  ;)

Me voy a ir tocando mientras pienso en canarias con el 05  8)

Fascinante el proyecto compañeros...

Al ver el cambio del Mesh está increíble como se re-diseña los contornos del relieve. Ahora la pregunta del millón, sería posible escarbar tanto que se pudiera eliminar creando un agujero para que sea rellenado por agua y así poder crear un lago o un río.

Se que es muy pronto como para distraerlos, una disculpa.


Saludos y adelante.

 ;)

Brutal es poco!!  :)

Lo de las sombras creo que es un pos-efecto del efecto abanico (cuántos efectos nuevos, jaja), ya que se crean aristas muy afiladas al iterar mucho y éstas proyectan sombras. Sin embargo, hay algo más, y son texturas (overlays) que desaparecen (o aparecen) sólo cuando te acercas... no sé si es normal o no (supongo que no); quizá deba subdividir también los triángulos de las capas overlay (que no toco).

Sobre el efecto abanico, ya sé por qué ocurre:

La manera en que subdivido los triángulos es la siguiente:

(http://s18.postimage.org/oz2ayrqud/esquema_tri_Mesh.jpg) (http://postimage.org/image/oz2ayrqud/)

En la primera iteración divido un triángulo (el negro) en 3 (azules). En la siguiente, cada uno de los azules otra vez en tres (rojos), y así sucesivamente... como se puede apreciar en los naranjas, los triángulos resultantes van quedando cada vez más achatados...

Es una cuestión difícil de resolver partiendo de triángulos, aunque se me ocurre otro procedimiento para tiras de triángulos (primitivas nº 1) y abanicos de triángulos (primitivas nº 2), pues se debe evitar añadir nuevos vértices en las aristas.

Sin embargo, crear una malla nueva a partir de un escenario fotorreal podría ser más sencillo (el problema aquí sería las costas).

En fin, si no consigues nada con el GRASS podría estudiar lo del script para procesar las imágenes del raster en varios formatos.


No hay que escarbar. Tal y como se define la malla, habría que crear triángulos con características de agua y líneas de costa. Eso puede ser más complicado porque ya no sería retocar triángulos en masa sino localizar algunos determinados y cambiar unos pocos puntos... pero vamos, nada es imposible!  ;)

Opa,

Hay dos proyectos open source españoles para trabajo GIS: gvSIG y Sextante. Los tenéis controlados?
Sextante es una maravilla. La versión oficial de gvSIG es un poco áspera en algunas cosas, pero existen dos forks un poco mejores:
http://oadigital.net/software/gvsigoade (http://oadigital.net/software/gvsigoade)
http://gvsigce.org/ (http://gvsigce.org/)

El Community Edition (segundo enlace) es más reciente y tiene buena pinta, aunque yo no he trabajado todavía con él.
gvSIG integra Sextante, y Sextante integra los algoritmos de GRASS, así que con uno de los gvSIG se tiene todo :)

Por cierto, una pregunta: No hay pérdida de rendimiento al colocar las ortofotos en un overlay como POL en lugar de empotrarlas en el DSF?

Vaya! Muy interesante. Es posible que con esto se solucione todo lo referente al raster... veremos!  :)

Sobre los escenarios fotorrealistas, sí, se dice que los basados en POL tienen menos rendimiento que los basados en TER (con la malla del terreno). Aunque se pueden hacer pruebas a ver si se nota o no...

Mi idea es poder hacer scripts para todo: (1) para convertir escenarios fotorrealistas ligados a la malla a escenarios fotorrealistas independientes, (2) adaptar escenarios fotorrealistas a la malla del XP10, (3) convertir escenarios independientes (POL) a la malla del XP10, (4) ampliar la malla del terreno (triMesh), ...

Aunque lo ideal, pienso, es (1º) el script de ampliar la malla para adaptar el raster y, a continuación (2º), un script para adaptar fotorrealistas a la malla del XP10 (y ampliarla). Con eso ya tenemos todo.

Toda información referente al tema, será bienvenida.

Pues una información más  ;)

Quizás ya lo conozcáis, pero porsiaca: gdal_retile.py es un script que forma parte de la suite de gdal (viene en el FWTools también). Sirve para coger una colección de rasters teselados de una manera, y teselarlos de otra. Vale para rasters de todo tipo: DEMs, ortofotos, lo que sea.

Me di de cabezazos al descubrir este script depués de haber "retileado" 40.000 Km2 de terreno a mano para un escenario para el Condor.
c;ra

Caso de uso: Se pillan las fotos del PNOA con JSigPac. Se ajustan a los límites del DSF. Se pasan por el gdal_retile.py para sacar teselas de 2048x2048, y luego se empotran en un DSF con alguno de los scripts que os estáis currando (muy buen trabajo, por cierto).

Bien, esto es genial, muchas gracias ;)

Estaba dándole vueltas al FWTools o GRASSGIS para evitar el uso del Global Mapper, eso es exactamente lo que quiero hacer:

Confeccionar mosaico con las hojas del IGN - proy. UTM Datum etrs89 (regcan95 para Canarias) --> Georreferenciar a proy. Lat.Long. Datum wgs84 --> exportar a HGT-STRM(int16) con división de celdas 1x1 --> Conversión RAW 16bit IBM.

Los cuatro primeros pasos los hice con el Global Mapper y el último con OpenEV + Photoshop.

Voy a mirarme el retile y el gvSIG, thanks!

Menudo nivel está cogiendo X-PLANE.ES, o mejor dicho, que nivel tienen algunos miembros de la lista  ;D

Por cierto, grrr05, podrías pasarme el raster que hiciste de La Palma para hacer pruebas?

Saludos

Aquí tienes
http://dl.dropbox.com/u/59143574/rasters/%2B28-018.txt.elevation.raw.7z (http://dl.dropbox.com/u/59143574/rasters/%2B28-018.txt.elevation.raw.7z)

No te olvides de ponerle "width=3601 height=3601" al dsf.

Pero te advierto que solo hay La Palma, La Gomera está completamente plana, es lo que tiene trabajar con demos :D

Por cierto ya me he bajado todo el MDT05 de Canarias (1,5GB), ahora a estudiarme los programas que ha dicho Galvedro.

Vale. La reproyección también te la resuelve gdal con algo como:

    gdalwarp -s_srs "+proj=UTM +zone=30" -t_srs "+proj=latlong" <raster_original> <raster_final>

La zona UTM hay que poner la que toque, claro. Y aunque ETRS90 no exactamente lo mismo que WGS84, la diferencia es mínima minimísima. A todos los efectos se pueden considerar equivalentes. El datum de canarias habría que mirarlo, ese no lo controlo...

Lo bueno de gdal es que es altamente "scripteable"  :)

Conocía este comando, pero la reproyección no es el problema, si no crear el mosaico y despues dividirlo en rasters de una sola celda (soy completamente novato en SIG).

Las hojas del IGN están proyectadas como UTM con ETRS89 y XP utiliza Geográficas con WGS84, pero ya te digo, en mi primer intento no tuve ningún problema para reproyectar el raster.

El datum canario es equivalente al WGS84 en cuanto a funcionalidad, o almenos eso he leido.

Ahora estoy con el Sextante y de momento me está convenciendo mucho.

Subida la versión BETA 2 de TriMesh. En ésta, simplemente, he cambiado el código para evitar el "efecto abanico"... pero por las pruebas que pude hacer con el raster de La Palma dicho problema aún se nota.

http://dl.dropbox.com/u/1126231/X-Plane/triMesh.py (http://dl.dropbox.com/u/1126231/X-Plane/triMesh.py)

No obstante, se me ha ocurrido otra idea para dividir triángulos más eficientemente. Será para la versión beta 3  8)

Ah, si se pone la opción -t en la ejecución del script, se procesará de la forma original (por si da error la nueva).

¡¡Notable el aumento de definición del terreno comparando las dos capturas al utilizar la nueva subdivisión de la malla.¡¡

¿El aumento de malla afecta mucho al rendimiento gráfico o apenas se nota?.
¿El autogen sobre la nueva malla se anula o al no sustituir la capa del raster se conserva?.

Hice una prueba hace unas horas y noté algo de bajada de rendimiento, aunque no mucho. Probé a volar por los barrancos de La Palma y ... guau!
El autogen sigue funcionando, casas, carreteras, árboles, todo. ;)

Mañana intentaré subir el script modificado. Acabo de ver la luz!! Creo que el "efecto abanico" desaparecerá al mismo tiempo que el código se vuelve más sencillo y la malla más eficiente (a ver si las palabras no se las lleva el viento, jaja)

Bien, acabo de hacer unas pruebas en el Teide (con la beta2) y queda horroroso por culpa del "abanicamiento" y las sombras que genera :D

Y ahora las malas notícias; aún no he dado con un programa que me vaya bien, tanto como Sextante, como OpenEV, GRASS, me crean un efecto de "solapamiento" con las hojas del IGN, a parte que con ninguno he dado con la función de exportar por celdas, todo lo contrario que con el Global Mapper, que me carga las hojas a la perfección... estoy a punto de tirar el PC por la ventana.

La otra es que veo inviable el uso del MDT05, en la celda de Tenerife me ha salido un raster de 1,2GB, y eso que en dicha celda no está ni la mitad llena!!!! ¿como vamos a meter esto en x-plane? encima el formato RAW ocupa algo más.
Vuelta a empezar y mañana a bajar los del MDT25 para mas pruebas.

ZX, sobre el rendimiento, algo tiene que mermar, es natural al multiplicar considerablemente el número de triángulos que forman la malla , aunque yo no he notado nada por ahora, pero como siempre esto va a máquinas. Lo que más me preocupa es el tamaño de los rasters que he usado, unos 25mb por cada dsf, todo esto se va a la RAM y hasta que no tengamos un ejecutable de 64bits, el tratamiento de las mallas debería ser experimental, igual que ha hecho AlpilotX.
Pero ese es el tamaño casi óptimo para el MDT25, ya que los he creado a partir del formato SRTM, pero a diferencia de los que se han usado en el Global Scenery original, los mios tienen el triple de resolución, 90m vs 30m. Pero intentaré mejorarlo para llegar a los 25m, que calculo que será un tamaño de unos 4000x4000 aproximadamente y unos 30mb, y así aprovechar al máximo la resolución del MDT25, que se vea bien en X-Plane ya dependerá de José Ángel  ;D.

Me estoy perdiendo en dos puntos. Por qué no estais usando la meshtool para optimizar la malla? y por qué es necesario empotrar el raster en el dsf?

Es uno de los cambios referentes a la malla en XP10, si la malla está definida la altitud de -32768, se usan los datos de elevación de un raster enpotrado en el dsf, lo que da mas margen para modificar el terreno en el futuro, al tocar unicamente el raster, sin necesidad de pasar por el meshtool.

A lo que me refiero es que no es obligatorio meter el raster en el DSF. Si se quiere usar una fuente muy detallada, como el MDT05 por ejemplo, puede convenir usar el método tradicional de incluir sólo la triangulación (para que no se vaya de madre en tamaño, me refiero).

He encontrado este post de Ben, donde dice qué gana metiendo los raster en la v10:

We get a few wins from storing elevation separately:

+ After compression the files are actually smaller.  This is because the data is more “regular” when stored in raster format than as part of the triangulation, and also because we don’t need to store normal vectors.
+ Since we’ll have the elevation data in its original form, we can use it to someday enhance the mesh for graphics cards that support hardware tessellation.

If raster data is a win in both quality and file-size, why didn’t we do this originally?  Two reasons:

+ Originally DSFs shipped in zip files; the big win in compression with regular data comes from the more advanced 7-zip compression we started using to ship X-Plane 9.
+ Raster encoding means increased load time in the sim as it “puts the mesh back together”.  Today in a multi-core world this is totally moot – DSF loading happens on another core, but originally DSFs had to be loaded on single-core machines, so load time was a key performance point.

(http://developer.x-plane.com/2011/08/dsf-gets-raster-data/ (http://developer.x-plane.com/2011/08/dsf-gets-raster-data/))

P.D. Por cierto. Sabed que me estáis picando mogollón, desgraciados...  :D

Pues habría que contemplar esta posibilidad sobre el uso del MDT05. En su día ya discutimos la opción de usarlo en algunas celdas en concreto, por contra en estas celdas se perdería la posibilidad de edición directamente desde el raster, pero no creo que sea algo muy crítico.

De momento yo voy a ir creando rasters del MDT25 con el objetivo de hacer pruebas, a ver si esta tarde puedo subir todos los de Canarias.

jeje, Ben lo deja claro, mejor separar la elevación de la triangulación con los raster. Además, eso permite mucho juego (el trabajar por separado).

Lo de la malla espero tenerlo solucionado esta tarde. No creo que me lleve más de 30 minutos hacer la modificación y si todo sale como lo tengo en la cabeza, debería mejorar mucho (Murphy, ni te acerques!).

El nuevo script cuadruplicará los triángulos en cada iteración, dejando los resultantes con unas características similares a los iniciales (proporción-ángulos) por lo que el "fecto abanico" no debería aparecer...

El método es sencillo, iterar a modo pintadera (http://es.wikipedia.org/wiki/Pintadera):

(http://img.ebayanuncios.es/74/86/74865ea8da3c37b9bf276852214b6ec6_big.jpg)

El lado malo es que, al añadirse vértices en los lados originales de cada triángulo (cosa que quería evitar desde el principio pero ahora me he dado cuenta de que no es mayor problema), no se podrá aplicar a zonas determinadas de una celda sino a una celda entera (bueno, poderse si que se puede, pero los efectos pueden ser imprevistos...).

En cuanto a los Raster de más de 25m de resolución se podrían dejar de lado, de momento. Si conseguimos automatizar el procedimiento lo suficiente (lástima lo del Sextant :(), cada cual lo podrá aplicar a las zonas que desee y así no tener que descargar (o subir) toneladas de Gb.

Jeje no te preocupes por el Sextante, con el puedo exportar un GeoTiff enorme y queda como debe quedar (no siempre hay que hacer caso de lo que se ve en pantalla).
Con la demo del Global Mapper lo puedo cargar como capa única y hacer la división de celdas georreferenciadas sin restricción alguna.

Por ahora este será el método provisional para la exportación, hasta que domine un poco el Sextante, de momento los rasters son 100% funcionales ;)

Ajá, genial. Mientras dure el periodo de prueba...

Por cierto, con la malla con "triángulos-abanico" no veas la de baches en la pista de GCLA. Habrá que llamar a la apisonadora a ver si arregla el desaliño  :D

Te dejo mas rasters por si acabas el script y quieres hacer "montañas" de pruebas ;)

http://dl.dropbox.com/u/59143574/rasters/27-18_27-19_28-17_28-18.7z (http://dl.dropbox.com/u/59143574/rasters/27-18_27-19_28-17_28-18.7z)

Son de las celdas +27-018 +27-019 +28-017 +28-018

Las celdas completas de La Palma, El Hierro, La Gomera y Tenerife, todas a 3601x3601.

Los he apañado con la demo del GM, esto empieza a ser desesperante, mucha lectura de manuales me queda aún...

Intentaré para esta noche completar el archipiélago.

Pues algo de ésto debe de pasar en LERS y sin vuestras maravillas en las taxi's, en 3 sitios me pega un bote por "socabrones" que cascan el avión, pero sigo investigando  c;ra

Bueno, esto marcha !!

El script modificado elimina el "efecto abanico" y la malla queda más realista!

Recordando unas imágenes que subí más atrás:

El Hierro: malla por defecto del XP10:
(http://s15.postimage.org/s5dqis0dz/EH1_xp.jpg) (http://postimage.org/image/s5dqis0dz/)

El Hierro: malla HD creada con el script en su versión Alpha y con el raster por defecto:
(http://s15.postimage.org/4pvtdfgmv/EH1_HD.jpg) (http://postimage.org/image/4pvtdfgmv/)

Añado ésta:

El Hierro: malla SuperHD creada con el nuevo script (beta 3), dos iteraciones (1 -> 16 triángulos) y con el raster de grrr05 de 3601x3601 (x3):
(http://s14.postimage.org/btxyo9w31/EH1_SHD.jpg) (http://postimage.org/image/btxyo9w31/)

Se pueden apreciar los cambios en los acantilados del Golfo (así sí son en la realidad) y en la montaña más cercana al avión que acaba en un saliente en el mar. Fíjense en las montañitas que se denotan arriba de ella...

Aquí los acantilados vistos desde el sur:
(http://s15.postimage.org/h3mulgk2f/Sbach300_18.jpg) (http://postimage.org/image/h3mulgk2f/)

Aún quedan un par de problemillas que arreglar: dividir tb. los triángulos overlay y ... las líneas de costa. En las lineas de costa pueden aparecer "zonas muertas", pequeñas, sin superficie. Eso también se veía en los escenarios creados con el g2xpl.

Ajusto unas cosas y subo el script (me ha llevado mucho más de lo que pensaba  :o)

Genial, que wuapo  ;)  ahora se tendrá que crear un manual para negados, por cierto, aparte de Linux supongo que podrá furular con "guindos"  :D :D :D

Of course ;) De hecho, grrr05 lo ha probado bajo windows.

Aquí dejo el enlace a la beta 3: http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py (http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py)

Si no quieren comerse el coco con los parámetros en la línea de comandos, lo más fácil es que pongan el script y el DSFTool dentro de la carpeta donde vayan a trabajar. Doble click y... debería funcionar. Si no... ejecútenlo en la línea de comandos y miren que les pone. Cualquier error que detecten, por favor, díganmelo ;)

Recuerden, deben tener instalado el Pyhton (por defecto en Linux y Mac) y las últimas DSFTool. Las celdas a procesar deben estar descomprimidas dentro de dicha carpeta de pruebas. Cada iteración (ejecución del script) cuatriplica los triángulos de la malla. Para añadir el raster ampliado, hay que meterle a mano a pelo.

Hice una prueba en el área de LECI, dos iteraciones, pero con el raster por defecto. Los cambios no se notan mucho pero... ahora no hace falta desmarcar "Runways follow terrain" ;)

Antes:
(http://s16.postimage.org/xcheuksox/c4_13.jpg) (http://postimage.org/image/xcheuksox/)

Después:
(http://s16.postimage.org/j7blsrjnl/c4_14.jpg) (http://postimage.org/image/j7blsrjnl/)


(sí, le cambié el nombre al script, :P)

EDITO: Beta 3.1. Ya conseguí eliminar el efecto fantasma por las texturas overlay que no se ajustaban... sólo tuve que quietar 4 letras del código  ;D

Sólo queda mirar lo de las líneas de costa y... buscar una buena apisonadora para las pistas de los aeropuertos, que en algunos sigue habiendo demasiado bache (supongo que es cosa de trabajar con el raster).

Teniais que sacar esto cuando estoy de 24x7??? Os odio!!! jajajaja

A ver si encuentro algún día para mirarlo, pero creo que hasta mayo nada de nada.

Bueno bueno bueno... en primer lugar muchísimas gracias por el script y enhorabuena!

Aquí los rasters de todas las celdas de Canarias (he empaquetado los anteriores también)
http://dl.dropbox.com/u/59143574/rasters/rasterscanarias.7z (http://dl.dropbox.com/u/59143574/rasters/rasterscanarias.7z)

Problema en el sur de La Gomera, no hay hoja del IGN y un cacho de celda esta sin terreno. Como estos rasters no van a ser definitivos trataré de remediarlo con un Copy&Paste y ampliación del raster original del XP10.

Ahora los resultados en Tenerife 8)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/tenerife2.jpg)
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/tenerife2hd.jpg)


(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/tenerife1.jpg)
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/tenerife1hd.jpg)


No hace falta decir que foto es de la malla original y cual es la que está iterada 2 veces y con el MDT25 :D :D


Aún sigo buscando una manera viable de crear los rasters y casi no doy abasto, os pido que tengais paciencia ;D

Estaba por hacer un copy/paste 1000 veces del : lo quiero ya!  8)

Algunas foticas ;-)

El Hierro: malla iterada dos veces con el script "pintadera" (16x) y raster de grrr05 (MDT25) 3x + escenario fotorrealístico independiente de la malla (POL) a zoom 18 (http://forums.x-plane.org/index.php?app=downloads&showfile=15681 (http://forums.x-plane.org/index.php?app=downloads&showfile=15681)).

http://www.dropbox.com/gallery/1126231/1/El%20Hierro%20XP10HD?h=1cdcb9 (http://www.dropbox.com/gallery/1126231/1/El%20Hierro%20XP10HD?h=1cdcb9)

Tomando estas fotos a veces me parecía que estaba utilizando el Google Earth... la resolución de la malla es muy similar  :)

(para la próxima pongo la calidad de las texturas en extreme high, que se nota la falta de definición)

Por cierto, que los escenarios basados en POL en el XP10 tiene algunos inconvenientes: la unión de las texturas se nota!! (cosa que no pasaba en el XP9). Fíjense en las líneas que aparecen en algunas fotos.

Beta 3.2 del script "pintadera". Se soluciona el problema de los triángulos azules en las costas.  :)

http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py (http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py)

De paso, he subido la isla de El Hierro procesada (dos iteraciones) y con el raster 3x del IGN procesado por grrr05. Vamos, por si quieren probar a volar directamente, sin pasar el script, entre valle sy montañas (recomiendo instalar El Hierro fotorreal que mencioné en el post anterior):

http://dl.dropbox.com/u/1126231/X-Plane/ZZZ_ElHierro_SHD.7z (http://dl.dropbox.com/u/1126231/X-Plane/ZZZ_ElHierro_SHD.7z) (4 Mb)

Descomprimirlo en Custom Scenery (sólo en XP10!!) procurando que sólo quede una carpeta "ZZZ El Hierro SHD" sin que haya otra del mismo nombre dentro.

Ah, si tienen instalado el Canarias HD de Alpilotx o el fotorreal de Canarias (ambos tienen mallas!) quitarlos del Custom Scenery (o darles menos prioridad).

Algunas tomas:

(http://dl.dropbox.com/u/1126231/X-Plane/ElHierro_SHD_01.jpeg)

(http://dl.dropbox.com/u/1126231/X-Plane/ElHierro_SHD_02.jpeg)

(http://dl.dropbox.com/u/1126231/X-Plane/ElHierro_SHD_03.jpeg)

Ya tengo todas las hojas de Catalunya y he empezado por los Pirineos.

Ahora que he encontrado otro programa freeware (MicroDEM) podré agilizar bastante el proceso, sigo dependiendo del Global Mapper pero creo que lo podré terminar antes de que acabe el periodo de prueba ;)

Este me permite trabajar con areas mucho mas grandes, como una comunidad autónoma entera, aunque tendré que estar al caso con los husos. Cuando tenga algo de tiempo escribiré una mini-guia para crear los rasters.

También me miraré el asunto de las fronteras, el mismo caso que en la Gomera, a ver si puedo cortar los rasters originales e interpolar las zonas sin datos.

Unas fotos mas,  para Jorduran, que seguro las reconoce ;)


(http://s14.postimage.org/4bqcjj0yl/cathd1.jpg) (http://postimage.org/image/4bqcjj0yl/)

(http://s16.postimage.org/jnyk9obm9/cathd2.jpg) (http://postimage.org/image/jnyk9obm9/)

(http://s14.postimage.org/okmwwqf19/cathd3.jpg) (http://postimage.org/image/okmwwqf19/)


Vaya!! esta noche me pongo a ello que me esperan en el bar!  :D

¡¡Qué ganas dan de volar a 3 metros sobre ese río!!  :)

(http://i178.photobucket.com/albums/w271/jorduran/iconos/inchino.gif)(http://i178.photobucket.com/albums/w271/jorduran/iconos/ojos.gif)(http://i178.photobucket.com/albums/w271/jorduran/iconos/icon_bottle.gif)(http://i178.photobucket.com/albums/w271/jorduran/iconos/globos.gif) ES QUE ME QUEDÉ SIN PALABRAS y además HAY RIO

Es impresionante el efecto de las ortofotos y la nueva malla en esos acantilados de El Hierro.

Este finde arreglare los rasters de las celdas fronterizas de Catalunya (y de La Gomera) y subiré todos los rasters correspondientes junto con los dsf a Dropbox.

Despúes de procesar celdas que no tienen costa y son todo malla, he visto que el tamaño final de cada dsf no llega a los 30mb (previamente comprimidos con 7z).
Se me ocurre que cuando el tema esté algo más estable, se podria subir al ftp (a modo de beta y experimental), celda por celda, como se hizo con el fotorrealístico, a ver que opinan los jefes.
El pais entero no tendria que llegar a 1,5gb, siempre que no se incruste el fotorrealístico.

Se por experiencia que si se empiezan a hacer tutoriales para que la gente lo haga ella misma, no lo disfrutarán, muchos no es atreven con estas cosas, otros sencillamente no tienen paciencia.

La otra es que si hay que pedir permiso a LR, ya que lo que se distribuye es un derivado de su producto, se han procesado dsf originales del Global Scenery, lo mismo que hizo AlpilotX supongo.

También estaba pensando, que con tiempo, se tendria que valorar si usar una o dos iteraciones dependiendo de la celda y buscar un término medio entre calidad y rendimiento, tengo tres celdas hechas del norte de Catalunya y el tiempo de carga en X-Plane ha aumentado bastante, aunque los frames se me mantenían casi intactos. ...ejecutable de 64bits por favor.... :D

Sitio hay de sobra por ahora y si encima podemos volver a generar el fotoreal pero sin mesh, pues va a ser mejor aún. El tema es que tendreis que subirlo a diversos sitios (donde solais subirlo) y nosotros lo subiremos ya en su estado final al FTP.


No comercialias con ello y esto es un trabajo personal, no creo. Otra cosa es que igual les interese vuestro trabajo. Podeis comentárselo pero problemas no hay.

Cierto! La isla de El Hierro sólo ocupa 4 Mb. Y no se nota pérdida de frames al cargarla. Yo creo que debería mencionarse, al menos, que es un producto derivado de Laminar (¿no?) y en los créditos al IGN.

Sobre los fotorrealísticos: el script para convertir los antiguos fotorrealísticos (malla del xp9) a POL y hacerlos independientes está casi listo. Por otro  lado, hacer un script que convierta dichos escenarios al formato XP10 es bastante sencillo (teóricamente). Luego se le podría pasar "pintadera" y añadir los raster procesados por grrr05 y obtendríamos celdas fotorrealísticas, con autogen y malla superHD. Y esta segunda solución será más eficiente que la primera, la de los POL (aunque ésta es más flexible).

Lo único malo de la segunda solución es que la línea de costa no sería tan buena como en el xp10... En fin, la semana que viene me meto con ello a ver si en un par de tardes lo tengo.

Impresionante trabajo, menudo currísimo que os estais dando!! :-d-  :-i-

Por cierto, quedan pendientes dos cosas para la "HDisación" de las mallas:

1ª) Un error que da DSFTool con algunas celdas cuando las intentas iterar varias veces ("Can't sink vertex\n" o algo así). Este error me lo da, por ejemplo, al intentar iterar El Hierro una segunda vez en Linux; sin embargo, en Windows no. Pero en Windows también lo da si la intento iterar 3 ó 4 veces. Con otras celdas no pasa. Y no sé cómo solucionarlo.

En principio, para iteraciones de 2 ó 3 pasos quizá no haya mayor problema.

2ª) Los baches en las pistas de los aeropuertos. Los raster de la malla original del XP10 están "tocados" para que las zonas de los aeropuertos no tengan estos baches y sean medianamente correctas (en algunos casos se nota). Habría que "toquetear" los rasters nuevos en las zonas de los aeropuertos para evitar ese problema. No creo que sea difícil, pero habría que hacerlo manualmente en TODOS los aeropuertos afectados...  ::) (o tener siempre desactivadas las "slopped runways"... cosa que no me gusta).

Haré algunas pruebas con las celdas de Canarias.

Creo que desde el MicroDEM se puede llamar a toda la cuadrilla de Obras Públicas para pasar las apisonadoras por los aeropuertos. Cuando tenga todos los rasters exportados veré que se puede hacer.

Otra cosa, modificad el parámetro del dsf para cambiar el tamaño del raster antes de la segunda iteración en celdas "full mesh", es casi imposible abrir un txt de 700 y pico mb, incluso con el Notepad++.

Más de dos iteraciones creo que es excesivo, almenos en la península, con una tercera ya son de 1 a 64 triángulos y el raster no da para tanto, la malla se ve practicamente igual que en google earth, porque han usado los mismos MDT25. Más triangulos significan un contorno algo más redondeado a expensas de unos tiempos de carga mucho mayores y puede que una pérdida de frames considerable, por no decir que se necesitarían grandes cantidades de RAM.

En otro orden de cosas, las condiciones de uso de datos del IGN;

Licencia de uso no comercial según lo establecido en la Orden FOM/956/2008, de 31 de marzo (BOE 8 de abril)

1. La licencia de uso solicitada ampara exclusivamente el uso no comercial de la información geográfica, entendiendo como tal el uso que no conlleva aprovechamiento económico directo, indirecto o diferido. Cualquier uso distinto al descrito requerirá la suscripción de un contrato específico con el CNIG, devengando la contraprestación económica correspondiente.
2. El usuario titular de la licencia se compromete a citar al Instituto Geográfico Nacional mediante la formula: "©INSTITUTO GEOGRÁFICO NACIONAL DE ESPAÑA" como autor y propietario de la información geográfica suministrada ante cualquier exhibición o difusión de la misma, o de parte de ella o de cualquier producto que, aún siendo de forma parcial, la incorpore o derive de ella.

El origen de los baches (o "socabrones" ;) ) en los aeropuertos:

LESU:

(http://s12.postimage.org/evyo6hfmx/lesu.jpg) (http://postimage.org/image/evyo6hfmx/)


(http://s13.postimage.org/3p1yk2dfn/lesumdt05.jpg) (http://postimage.org/image/3p1yk2dfn/)

Este es el MDE de 5 metros de LESU, y los MDT25 son versiones reducidas de tamaño.

Con el MDT25 la pista tiene la anchura de un pixel, y desde el MicroDEM no puedo hacer nada. La solución creo que está en editar el archivo RAW directamente, aunque es muy arriesgado.

Seguiré investigando, pero este handicap puede ralentizar mucho todo el asunto.

Faltaba un raster en Canarias que ya he resubido, no pasaba nada en La Gomera (no se en que mapa estaría mirando  ::))

http://dl.dropbox.com/u/59143574/rasters/rasterscanarias.7z (http://dl.dropbox.com/u/59143574/rasters/rasterscanarias.7z)

También he probado con Baleares el tema de falta de datos del IGN, rellenando las zonas "vacias" con el raster original de XP y no se nota nada.
A ver si hay el mismo resultado con Portugal y Francia.

Rasters de Baleares
http://dl.dropbox.com/u/59143574/rasters/rastersbaleares.7z (http://dl.dropbox.com/u/59143574/rasters/rastersbaleares.7z)

Si alguien se anima a probar el escenario SHD con las cuatro islas del archipiélago balear.
http://dl.dropbox.com/u/59143574/escenarios/ZZZ_Baleares_SHD.7z (http://dl.dropbox.com/u/59143574/escenarios/ZZZ_Baleares_SHD.7z)

Al igual que el de El Hierro, no es compatible con el fotorrealista.

(http://s17.postimage.org/dna5f4xwb/mallorca1hd.jpg) (http://postimage.org/image/dna5f4xwb/)

(http://s17.postimage.org/uvlqhfs7v/mallorca2hd.jpg) (http://postimage.org/image/uvlqhfs7v/)

(http://s15.postimage.org/caemkieo7/mallorca3hd.jpg) (http://postimage.org/image/caemkieo7/)

(http://s18.postimage.org/xnpq9adrp/menorcahd.jpg) (http://postimage.org/image/xnpq9adrp/)

Pero esa pista debería estar suavizada o plana por el perímetro del aeropuerto. No puede ser problema de que no tenga perímetro? Lo has mirado en el wed?

Pasa practicamente en todas las pistas que hay en las celdas con malla modificada, cuando la opción de que la pista sigue el contorno del terreno está activada.
Al haber tantos triángulos y que los datos del IGN son imprecisos en zonas llanas aparecen estas ondulaciones, claro que si se desactiva lo de las pistas y el contorno el perímetro hace su función correctamente.

Lo de la imprecisión en las zonas llanas creo que se debe al proceso que se hecho para eliminar edificios y demás objetos artificiales para dejar el terreno "limpio" en los MDT, entonces aparecen "interferencias" en dichas zonas.

Se lohabeis comentado a Ben o a Andras a ver si os pueden ayudar? (Andras es Alpilotx)

No creo que ni Ben ni Andras tengan nada que decirnos sobre esto, pues el fallo está exclusivamente en el raster. El raster ya contiene estos datos de elevación de los baches, aunque sean falsos y la malla al tener tanta precision por el número de triángulos se adapta perfectamente.

Andras no ha utilizado rasters propios, si no los originales de XP, como dice en la web, solo ha subdividido la malla. Si se pasa el script de Cestomano dos veces sobre cualquier celda y no se le pone el raster del IGN las pistas quedan llanas. Exactamente igual que los HD Mesh de Andras.

Y la solución de Ben puede que sea desactivar el contorno en las pistas. A mí no me importa mucho pero a Cestomano no le gusta nada, la solución mas directa es editar el raster a mano y a la larga se tendrá que hacer. Como los rasters originales de XP tienen una resolución de 90m, los alrededores de la mayoría de aeropuertos quedan suavizados.

Escenario SHD con toda la costa cantábrica, Picos de Europa, etc - celdas +43-010 .... +43-002 (2 iteraciones y MDT25)
http://dl.dropbox.com/u/59143574/escenarios/ZZZ_Spain_SHD%2B43-010_%2B43-002.7z (http://dl.dropbox.com/u/59143574/escenarios/ZZZ_Spain_SHD%2B43-010_%2B43-002.7z)

Solo XP10, incompatible con fotorreal y hay que desactivar "las pistas siguen el contorno del terreno"

Rasters
http://dl.dropbox.com/u/59143574/rasters/rasters%2B43-010_%2B43-003.7z (http://dl.dropbox.com/u/59143574/rasters/rasters%2B43-010_%2B43-003.7z)

Quien se anime a probarlo que nos diga posibles errores, rendimiento y si hay cuelgues que especifique sobretodo cantidad de RAM  y arquitectura del S.O. (32 o 64bits)
No es que se pueda hacer mucho al respecto pero mas que nada para saber los requerimientos. A muy malas se podria hacer además una versión con una sola iteración y con los rasters del MDT25, aunque visualmente no va a ser lo mismo.

Más fotos  ^-^

(http://s18.postimage.org/rni18i7hh/sshd1.jpg) (http://postimage.org/image/rni18i7hh/)

(http://s10.postimage.org/4h7m1k4dx/sshd2.jpg) (http://postimage.org/image/4h7m1k4dx/)

(http://s15.postimage.org/7webm7tef/sshd3.jpg) (http://postimage.org/image/7webm7tef/)

Lagos Ercina y Enol  8)
(http://s18.postimage.org/hjtbccqqt/sshd4.jpg) (http://postimage.org/image/hjtbccqqt/)

(http://s18.postimage.org/wibq6s5t1/sshd5.jpg) (http://postimage.org/image/wibq6s5t1/)

(http://s16.postimage.org/pryf1ke69/sshd6.jpg) (http://postimage.org/image/pryf1ke69/)

Bajando esos "Picus" para ver el Urriellu  ;), si tienes la zona de La Cerdaña, me gustaría poderle dar unos vistazos.

Hoy no podré probarlo pero lo preparo, lo que si es un "coniazo" es lo de que a unos les gusta que "las pistas siguen el contorno del terreno" y a otros no, en LERS en obras no pasa ésto pero existe un desnivel en el terreno que  o la pista queda flotando o queda rara, pero está en estudio alguna solución ( a que pongo la terminal sobre pilares)  ;D :D :D :D :D :D :-[

La Cerdanya estará para la siguiente, hago por hileras de celdas de este a oeste, aunque voy a tener que apañar los rasters de las celdas fronterizas con los MDT25 disponibles y con los originales de XP, Tanto el Institut Géographique National frances y el Instituto Geográfico Português me piden dinero para los MDT y no se lo voy a dar así que sintiéndolo mucho más alla de las fronteras se quedarán en 90m, aunque la malla estará iterada dos veces y se verá algo mejor que de origen.

Pero no quiero correr demasiado por si José Ángel saca una nueva versión del "pintadera".

Y recordad que esto es puramente experimental sin ninguna garantía de que furule bien, advierto ya que los tiempos de carga se disparan y se notan caídas de frames  8)

Editar los raster para "allanar" el terreno no debe (pienso, no lo he probado) ser muy complicado; lo malo es que habría que repetir la operación para cada pista afectada. En principio, al tener rasters de 25m, la cosa es nivelarlos no solo en la pista, sino cerca de ella (como está en los rasters originales del xp10) para que vértices de triángulos exteriores a la pista no afecten a esta.

¿Cómo hacerlo? Se me ocurre importar el raster al photochó (el Gimp no permite importar imágenes brutas de un canal/16 bits, sólo RGB 8 bits :(). Crear una capa transparente encima y dibujar en ella las 4 esquinas de la pista (o pista y plataforma). ¿Cómo? Regla de tres: si 0 es 28.0º y 3600 es 29º, entonces la latitud de tal punto es tal píxel... (ya, ya... laborioso). Luego medir con cuenta gotas (y un buen zoom aplicado al área) los valores de los píxeles y repintarlos nivelados... mmm, voy a probarlo con El Hierro a ver qué sale.

(creo q primero debo instalarme el potochó, pues llevo un par de años sólo a base de Gimp :S )

Ah, y sobre Pintadera. Creo que que esta última versión es bastante estable (la beta 3.2) y no se me ocurren mejoras que hacerle, así que podemos procesar España y... bueno, si hay mejoras en el futuro, reprocesar  :D

Algo que no queda muy bien con todo este proceso son las líneas de costa: suelen aparecer acantilados muy bruscos donde no debería haberlos... La razón: en las líneas de costa, los vértices no tienen altura -32.768, sino otra definida. Es decir, no siguen el raster, sino que se cortan ahí a lo bestia. Por muy detallado que pongas un raster, el punto donde termina la tierra y comienza el agua será el mismo (hasta que implementen la barimetría... cosa que espero que no sea a muy largo plazo).

Por cierto, acabo de encontrar una aplicación (un paquete de utilidades) gratuitas (para Linux) para trabajar la conversión entre formatos de rasters, tiff geoetiquetadas, recortes, transformación, etc.

http://tmintt.eu/content/srtm-dem-conversion-gdal (http://tmintt.eu/content/srtm-dem-conversion-gdal)

(Gdal)

Le echaré un vistazo en cuanto pueda a ver si puede contribuir en algo a esta causa  :)

Voy a mirarme eso del potochó, también seria interesante probar si en alguna pista con inclinación se pudiera crear un gradiente en la mascara basándose en el valor de altitud de los pixels en cada cabecera de la pista, pero eso lo veo complicado y hay que trabajar con perfiles con la gamma altísima porqué a simple vista no se ve casi nada en el raster.

El Gdal está integrado en el FWTools y es el que utilizo para convertir los mosaicos en formato hgt (SRTM) a GeoTiff para su posterior volteado vertical y conversión a RAW con potochó.

La conversión la hago con el GUI del FWTools (mal acostumbrado estoy) pero se puede desde consola con el comando gdal_translate.

Sí, acabo de verlo. Hay que crear un duplicado de la capa y subir los niveles a tope para poder ver la imagen. Lo del gradiente es buena idea, aunque yo estaba pensando en algo más laborioso: hacerlo a mano! algunas pistas tienen unas características (badenes) que merecen que se les respete.

Uy! sí, leyendo del Gdal vi que estaba dentro del FWTools. Intenté hacer una conversión con el gdal_translate y no me fue muy bien. Se nota que estoy perdido en este tema. Paciencia, poco a poco... (me digo a mí mismo).

Bueno como se supone que no hay "plazo de entrega" se puede mirar con detenimiento. Mañana intentaré completar y subir los rasters del paralelo +42.

Este es el proceso que he dejado como definitivo para montar los rasters (windows), como novato no se me ocurre nada mas o no encuentro las funciones en los programas habituales:

Para crear un mosaico con las hojas del IGN hay que seleccionar las correspondientes a la celda de 1x1 que se va crear con la funcion del MicroDEM "Open and merge DEMs" (es vital tener a mano el mapa con la cuadrícula lat/long que hay en la sección de descargas del IGN) y se le especifica la zona UTM a cada hoja (28 Canarias y 29, 30 y 31 península). Despues se exporta con la función "Save DEM" y con formato GeoTiff. Tiene la función de exportar por celdas especificando las coordenadas lat/lon de la esquina NW y la SE pero a mi no me funciona, me salta un "Acces Violation" o algo así lo que alarga un poco el proceso...

El GeoTiff resultante lo cargo con la demo del Global Mapper y lo vuelvo a exportar en formato STRM-1deg (X-Plane utiliza el STRM-3deg, que es el de 90m) y aquí se le puede decir que "corte" por las coordenadas que queramos, que logicamente van a ser las de la celda que vamos a hacer. Se exporta un archivo HGT y 3 archivos más (no hay que borrarlos!!).

Con el FWTools se importa (con la función Import, no con la Open) dicho HGT. Automaticamente aparece otro GeoTiff y se puede cerrar el FWTools.

Abrir el nuevo GeoTiff con Photoshop, meterle el bote de pintura negra en las zonas NODATA si las hay (representadas en gris claro), voltear la imagen verticalmente y guardar en formato RAW con orden IBM.

Las zonas NODATA se encuentran o en el mar o a partir de los límites fronterizos, en este último caso lo que hago es cargar una nueva capa con el raster original de XP de esta misma celda ampliado a 3601x3601 y le pego el nuevo raster encima, cortando toda la zona NODATA. No hace falta tratar la imagen ni nada ya que la malla se encarga de suavizar el terreno si es que el cambio en el raster es muy brusco, pero por ahora yo no he visto ninguna anomalía.

El problema está si el raster original también tiene zonas NODATA, que en este caso no son areas enteras sino pixels individuales. Al ampliar el raster estos pixels se suavizan mediante filtros por lo que pasan de ser NODATA a contener datos falsos (no se si me explico bien...) por lo que hay que eliminarlos antes de ampliar, cogiendo el valor de color circundante con el cuentagotas y "tapar" esos pixels. Otra operación que requiere meterle mano.

Asi explicado parece bastante pesado pero en realidad, o almenos yo que lo tengo por mano, no tardo más de 5 minutos por celda a no ser que me encuentre el problema de las fronteras.


Toma Urriellu :D
(http://s15.postimage.org/lnog3j72v/urriellu.jpg) (http://postimage.org/image/lnog3j72v/)

Con respecto a allanar las pistas, cierto es que sería genial poder mantener los desniveles actuales y solo retocar los que están muy mal y no se puede aterrizar/despegar de ellos.

Por cierto, cuando lo acabeis avisadme y lo subo al ftp.

Ya me parecía a mi que no lo encontraba en la página de descargas... XD

Eso es el naranjo?

Anoche, la almohada me estuvo dando ideas para automatizar esto. Quizá una aplicación la cual, mediante los datos de borde de un aeropuerto definidos en un apt.dat (o los datos de pista) cree una selección de la zona para luego aplicar un filtro gaussiano. El filtro gaussiano suavizará dicha superficie sin llegar a allanarla del todo (bueno, depende del % que se le aplique). Ahora, la cosa es conseguir automatizar esto ;)

Por cierto, ¿qué les parece hacer pública la utilidad (pintadera) y el método expuesto por grrr05 en x-plane.org? Podría crear un efecto dominó y tener mallas superHD de muchas zonas del mundo....  ;)

 :-[ Ni manualmente... he probado filtros de todo tipo y degradados... la pista sigue sin allanarse (todo con potochó). Es más, queda peor! El único método que me ha funcionado hasta ahora es el de pintar los píxeles con un valor central de la pista. Eso sí, se pierden los badenes que pudiera tener la pista... aunque queda mejor que activar las "slopped runway" (en aeropuertos pegados a la costa quedan fatal).

Seguiré haciendo pruebas... (otro día  ;))

Correcto, viendo ésto con un quesuco y una sidra en la mano  ;)

Y en la página 5 (último post) grrr5 nos obsequió con el Pedraforca en el Cadí  ;)

Mal asunto con el paralelo +42, se me ha liado un pollo con los datums y la mitad de rasters me han quedado desplazado varios metros, los tendre que rehacer, puede que en el paralelo +43 también pase algo similar pero yo no vi nada raro en los aeropuertos, pero sin las ortofotos es dificil comprobarlo, se pueden utilizar las sombras de las montañas en las ortofotos para ver si "casa" bien con el raster.  :-t-

Jordi esta vez el Pedraforca ha salido donde no tocaba y ha quedado todo cubierto por los arboles del autogen y con una forma horrorosa. El que utilicé para la foto tenia el raster bien georreferenciado pero sin la parte francesa (las montañas cortaban en seco) y no valía subir eso.

Ale, al lío otra vez...


Todo tuyo!! yo no llego a tanto :D, el problema creo que está en que muchos triángulos han quedado mas pequeños que un pixel del raster y al más mínimo cambio de color entre pixels puede crear un escalón en la malla si está en una zona llana.

Cuando solucione el asunto de esos rasters que me han salido mal georreferenciados puedo subirte los GeoTiff previos a la conversión, por si te va mejor para editarlos. Pero recuerda espejarlos de arriba a abajo (volteado vertical) antes de guardarlos en RAW.

En cuanto a lo de publicar esto, tu mismo que por eso es tu script, por mi parte el método que utilizo para crear los rasters es de pésimo a ridículo, así que si lo simplificas mejor  :D Pienso que todo lo que hago es posible con el gvSIG o incluso con Gdal, pero no doy con ello. Creo que cualquiera que entienda de GIS sabrá como hacer un mosaico de DEMs con el formato SRTM y exportarlo a raw por celdas.

Quizá la mejor (o más sencilla) solución sea poner como capa el raster original ampliado a 3601 y recortar el aeropuerto. Así nos podemos asegurar que quede bien y, a continuación, quien quiera mejorar el apt, a pelearse con cálculos!  :D

Lo del método a mí me parece correcto. Sí, puede que haya otras formas pero ese es un ejemplo válido (muy válido) pienso yo. Cuando quede un poco más claro lo de las pistas (un método que funcione medianamente) se puede subir.

Ahora que tengo un rato he buscado la zona de canarias, pero pensaba que estabais subiendo los ficheros para el custom scenery y me veo los raw. Me vais a hacer leer de nuevo el hilo y todo  :D

Vale ahora creo que si, el escenario con las celdas +42-010 a +42+003
http://dl.dropbox.com/u/59143574/escenarios/ZZZ_Spain_SHD_%2B42-010_%2B42%2B003.7z (http://dl.dropbox.com/u/59143574/escenarios/ZZZ_Spain_SHD_%2B42-010_%2B42%2B003.7z) (se puede combinar con la carpeta del anterior)

Por ahora hay un fallo en la celda +42+003 en la parte francesa, culpa (como no!) del raster original y la mezcla con el nuevo.

Ale Jordi, ya puedes sacar a pasear el ELA por los Pirineos  ;D

Rasters:
http://dl.dropbox.com/u/59143574/rasters/rasters%2B42-010_%2B42%2B003.7z (http://dl.dropbox.com/u/59143574/rasters/rasters%2B42-010_%2B42%2B003.7z)

Si los links dan error esperad un rato porqué acabo de empezar a subir y son casi 300mb.


Eso me parece muchísimo mas viable, miraré a ver si consigo algo, pero la ampliación del raster original tiene que hacerse con un filtro que suavice bastante.

Si el método de la creación de rasters te parece valido, por mi estupendo pues, pero yo esperaría a que el asunto cuaje más (me ha salido el primer pantallazo de fallo de RAM de X-Plane  :D :D), y a ver si aparecen nuevas actualizaciones o el ejecutable de 64bits, que veo será casi obligado para estas mallas, en los Pirineos me ha llegado a consumir 2,5gb de RAM.


Descuida que esta noche lo vuelvo a crear y lo subo. Los DSF que he utilizado para las pruebas y capturas las hice con una versión antigua del Pintadera, que aparecian algunos problemas en las costas, por eso no lo subí.
Este casi casi que se podría dejar por definitvo (beta) ya que teneis las ortofotos independientes de la malla. Cestomano subió el de El Hierro una páginas mas atras por si quieres ir probando.

En el punto en que se encuentra actualmente el proyecto, ¿Los dsf se convierten a pol finalmente?
Cestomano, respecto a lo que comentas de publicarlo en el org, fíjate que Andras teniendo un script para hacer la malla con más definición no lo ha liberado, no se si por problemas de la licencia de X-Plane. Si lo comentas con LR mejor que mejor.
Publicar el "pintadera" no creo que sea problema, pero se está modificando "material" que lleva el propio simulador. Si se coge directamente del SRTM y se manipula pues no hay problema.
Es estupendo que con el script se pueda modificar la malla de terreno para tener más definición, pero publicar y distribuir esa malla modificada ya es diferente.
No se si estas cosas te las habías planteado, pero hay que tenerlas en cuenta.

Por otro lado, estas haciendo un trabajo excepcional y de mucho nivel. 

Je je, esto da que pensar.

En primer lugar, puede que Andras tenga sus razones para no liberar el script, pero el está distribuyendo al público lo que se supone que es un derivado de un producto LR, imagino que bajo el consentimiento de LR. Aunque haya creado una nueva malla, sigue distribuyendo los rasters que incorpora que SI son propiedad de LR.

El SRTM tengo entendido que es de difusión pública, pero los que he usado para las celdas fronterizas o donde no hay datos del IGN son los del mismo XP, esos datos han estado procesados por LR supongo que bajo licencia comercial de la NASA, lo que imagino les convierte en titulares de los archivos RAW que utilizo y en parte se distrubuyen con el escenario.

Los datos del IGN no tienen problema, se pueden utilizar-distribuir-modificar siempre que se cite al IGN en los créditos y no haya beneficio económico directo o indirecto.


Por eso había preguntado anteriormente si es necesario pedir el consentimiento a LR, ya que las mallas, aunque modificadas, son propiedad suya, a si como parte de los rasters que he utilizado.

Se lo pediría yo mismo pero mi inglés... digamos que lo entiendo perfectamente pero soy incapaz de expresarme  :-[

Iva a colgar Canarias pero si acaso me espero. ¿Tendría que borrar de momento lo demás que he subido de este escenario en Dropbox?

No, yo me refería a subir al ORG la utilidad (pintadera) y el método-ayuda para extraer datos SRTM y convertirlos, no los escenarios en sí.

La utilidad es libre y de código abierto; mi idea es que la pueda utilizar todo el mundo para que generen mallas de otras zonas (y que las suban a algún sitio si quieren). Nosotros podemos subir las nuestras al FTP que no creo que haya mayor problema con LR.

Sobre la de Canarias, súbela si quieres, Grrr05. Yo aún sólo tengo creadas la de Tenerife y El Hierro. Lo malo de Canarias es que la mayoría de aeropuertos son costeros... (problemas de baches). Pero si quieres, la puedo subir yo en cuanto arregle lo de las pistas (en principio copiando de los raster originales). Es más, quiero allanar un poco la zona de El Revolcadero y Buenavista.

Sobre lo de los escenarios POL (mira que ha derivado el tema en el hilo, jaja): como dije en un hilo más atrás (perdido en la inmensiadad de este océano de información ;)) el Script estaba casi listo, a falta de corregir lo de las costas. Y también tengo en cabeza un segundo script para convertir los escenartios del G2XPL no sólo a POL sino a la malla del terreno del XP10 por lo cual se le podría aplicar pintadera y el raster STRM25 si lo desean. Las combinaciones finales pueden ser varias... veremos cuál gusta más.

Espero hacer ambos scripts esta semana (si todo va bien) y, sobretodo, un resumen para no confundir con tanto script, conversión, escenario, etc.  :D

Lo mejor para subir escenarios es esperar a que vosotros lo veais listo y si quieres, edita el primer post y así la información clave no se pierde.

Con respecto al org u otros sitios, lo mejor es ponerse en contacto con LR, con Ben o con Andras directamente y preguntarles. Este tema es más de Andras, que es quien lleva el tema en LR. Mejor asegurarte con ellos que no hay problema ninguno, que ya sabes lo tontos que se ponen en el org con cualquier cosa, que los americanos son muy de la libertad hasta que les interesa :)

Gran trabajo! Creo que con dos mas como vosotros, yo ya me puedo retirar jajajaja

grrr05, no tienes por qué borrar nada, no van por ahí los tiros. Si, el SRTM es una base de datos de acceso público que yo sepa, realizado por la NASA con sus satélites.
Lo de Andras es caso aparte porque LR también se a aprovechado con el permiso del mismo, del trabajo son el sistema de generación de zonas de bosque.

El acuerdo de licencia de usuario final EULA de Laminar, fuera de toda jerga legal dice:

You agree to not distribute the artwork from X-Plane, OR ANY DERIVATE OF THAT ARTWORK, without permission from Laminar Research.

Por eso lo comento, lo que realmente prohiben (no está expresado aquí pero si en alguno de sus manuales) es hacer ingeniería inversa, descompilar o hacer público el código fuente del simulador.

Lo de modificar o alterar algún contenido, como es este caso solo dice que sea con su permiso.

Para salir de dudas si queréis lo mejor, es comentarles: ¿mira hemos hecho esto, hay algún problema en poner la malla modificada como descarga para la gente que tiene X-Plane10?.
Si queréis lo podemos hacer como consulta general y no individual, para que tenga más peso.

Exacto, si lo propones como un proyecto vuestro pero dentro de x-plane.es, suena distinto a proponerlo como algo personal. Cuando yo les propongo algo, los términos siempre son de trabajo en equipo del .es

Pero bueno, eso ya es decisión de cada uno.

Sobre los escenario, toi de acuerdo  ;)

Lo ideal sería que un administrador de x-plane.es enviara un mensajito a LR diciendo que estamos sacando productos derivados, gratuitos y los colgamos en nuestro FTP. O algo así, no?

Sobre este tema, se me ocurre que se pueda automatizar para cualquier malla-aeropuerto utilizando el raster antiguo, el nuevo y la selección del "boundary" de los aeropuertos desde el APT.DAT, todo mediante el ImageMagick (http://www.imagemagick.org (http://www.imagemagick.org)), gratuito y multiplataforma. Habrá que hacer otro script   :-X

A eso me refería, para colgar los escenarios ya hechos aquí, en el .es

Sabiendo esto, dejo el escenario de Canarias para ir probando.
http://dl.dropbox.com/u/59143574/escenarios/Canarias_SHD.7z (http://dl.dropbox.com/u/59143574/escenarios/Canarias_SHD.7z)

Siguen los problemas de los baches en pistas, pero si es posible solucionarlo con capas de rasters (el script que corte por los boundary sería genial ;)) no habrá ningún problema para meterlos de nuevo en las mallas ya hechas.
Yo de momemento seguiré creando los rasters que aún me queda algo más de media península.

Probado, la verdad es que es una pasada, aunque con el check de activar los contornos de pista es imposible aterrizar o despegar y si le quitas el check, hay sitios como GCXO que pierden toda la chispa.

Pero vamos que esto y un fotoreal y a mi no me sacan de nuevo de canarias!

Pues en Gran Canaria ni hace falta el fotorreal; es una pasada... (cosa que no se puede decir de Fuerteventura, parece una selva amazónica!).

Roque de Agando; La Gomera:

(http://dl.dropbox.com/u/1126231/X-Plane/Agando.jpg)

(http://farm5.staticflickr.com/4140/4810378994_3cfb0b3714_b.jpg)

Antes del Mesh HD ni existía......

La segunda te ha quedado super real  :D :D :D :D

Sí, le puse extreme high a todo en rendering options, claro que me bajó a 0.001 fps  :D

Bueno, por fin he podido volar por distintos lugares que no me son desconocidos:
Tenerife y La Palma en dos palabras IM-PRESIONANTE y Fuerteventura, de risa oiga, quin ha puesto las texturas ???
zona de Igualada, Montserrat y LELL no le aprecio mucha diferencia, y el rio Llobregat por lo del cambio climático esta seco  :'( desde el pantano de La Baells hasta ni se donde aparece de nuevo, lo mismo que en La Cerdanya, hay los árboles del rio pero sin rio  :(  quizas tengo alguna version antigua ??

Felicidades con el trabajo que estais realizando y por favor, no desfallezcais que eso merece la pena, pero MUUUUUUUUUCHOOOOOOOO

Todavía no he llegado por aquí!! pero ya pronto ;)

Lo de los ríos no es un problema de versiones no... es que vienen así de orígen con XP. El Pintadera no los toca.

Cierto, sólo los trianguliza un poco más  ;)


Acabo de subir el script ter2pol (http://dl.dropbox.com/u/1126231/X-Plane/ter2pol.py (http://dl.dropbox.com/u/1126231/X-Plane/ter2pol.py)) para convertir escenarios fotorrealistas creados con el G2XPL a escenarios independientes de la malla (de forma que podamos utilizarlos conjuntamente con estas nuevas mallas).

Al principio de este hilo (http://www.x-plane.es/modules/smf/index.php?PHPSESSID=8e2d93f2b1f5699594bd1f72a94b1626;topic=6626.msg63081#msg63081) comento el uso y los pormenores. Por favor, pruébenlo y me comentan las primeras impresiones...

Les adelanto que el problema de proporción de las celdas de línea de costa está (casi) arreglado, pero aún así deben editarse A MANO las imágenes si queremos eliminar el agua.

Nada, ahora a intentar hacer un script que convierta dichos escenarios G2XPL a escenarios del XP10, para aplicarle la pintadera... ( a ver qué solución queda peor)  ;D

Impresionante lo de Canarias. Ahora los barrancos sí que parecen barrancos. De eso aquí tenemos bastante y hace aún más espectacular el escenario

Pos fale, aunque cuando se disponga del fotografico encima de las nuevas mallas "no hace falta decir nada mas"

Ya puedes! Al menos, versión beta  ;)

Algunas pruebas sobre Tenerife. Malla superHD (pintadera x2, SRTM25/Grrr05 sin nivelar pistas  :P) + escenario fotográfico del G2XPL, zoom 17 (ortos de 5 años), convertido mediante "ter2pol" (texturas muy claras, no adaptadas aún al XP9 ni recortadas las líneas de costa):

Por Anaga:
(http://dl.dropbox.com/u/1126231/X-Plane/TenerifeSHD01.jpeg)

Teide, noreste:
(http://dl.dropbox.com/u/1126231/X-Plane/TenerifeSHD02.jpeg)

Teide, sur:
(http://dl.dropbox.com/u/1126231/X-Plane/TenerifeSHD03.jpeg)

Dándome un chapuzón en la Balsa de Los Silos:
(http://dl.dropbox.com/u/1126231/X-Plane/TenerifeSHD04.jpeg)


Más: https://www.dropbox.com/gallery/1126231/1/Tenerife%20XP10HD?h=d9c78d (https://www.dropbox.com/gallery/1126231/1/Tenerife%20XP10HD?h=d9c78d)

Cestomano, yo soy "limitado" con esas cosas y "no mac" pero "algo a ratos de linux" con "güidous" como puedo ejecutar el script ??  en que carpeta va el script y los tools. gracias por delante, y así mas peña podrá colaborar si son gente xplanera de bien  ;D :D :D :D ;)

Se ha leido usté el primer post? O se le ha pegado lo de vagoneta??  :D :D :D

Es coña.

El tema es: yo lo meto en la carpeta del escenario de canarias ../custom scenery/canarias_fotoreal/ y ahí tengo el script y el dsftool.exe. El script empieza y a los pocos segundos canta que le faltan cosas, pero me pide un .txt que obviamente están en la carpeta TERRAIN pero con el nombre g2xpl_8_16_30312_38312.ter y no con el que busca ni donde lo busca...

Porque busca esto? .\\Earth nav data\\+20-020\\+27-016_TER.txt'

::: ter2pol.py BETA 1.0 - Cestomano - abr 2012 :::

STEP 1: Processing TER files...
Processed TER files: 587
Detected errors: 0

STEP 2: Processing DSF files...
   Processing +20-020 folder...

Traceback (most recent call last):
  File "D:\X-Plane 10\Custom Scenery\Z_Canarias_google\ter2pol.py", line 313, in <module>
    sys.exit(main())
  File "D:\X-Plane 10\Custom Scenery\Z_Canarias_google\ter2pol.py", line 306, in main
    (nDsf, nDsfErrores) =  procesaDsf(os.path.join(dirScenery, "Earth nav data", subcarpeta), dirDsftool)
  File "D:\X-Plane 10\Custom Scenery\Z_Canarias_google\ter2pol.py", line 122, in procesaDsf
    fTer = open(sTxtOrigen, "r")
IOError: [Errno 2] No such file or directory: '.\\Earth nav data\\+20-020\\+27-016_TER.txt'
>>>

Vaya! No existe un archivo "+27-016_TER.txt" en la carpeta +20-020 (dentro de Earth Nav Data del fotorreal) ??

Si sí, entonces el problema puede venir de esa doble barra extraña que aparece. Repaso el script as ver...

EDITO: El script parece correcto en ese paso. Please, verifica si existe el archivo "+27-016_TER.txt" y otro "+27-016_POL.txt" en dicha carpeta +20-020 y me dices.

en la carpeta +20-020 solo hay ficheros DSF, como dios manda  :D

Pues el problema está en que el dsftool no se ha ejecutado.

Haz una cosa: prueba a ejecutar el script así:

> python ter2pol.py . dsftool.exe

(que exista espacio ante sy después del .)

No pasa nada con la doble barra, el caso es que busca un txt y renombrando el archivo xxxx.ter a xxxx.ter.txt ya tira.
El mismo caso que con el pintadera, salvo que ademas había que escribir "_XP10 al final del archivo (antes del .txt)

¿Debería haberlo dicho antes? :D es que llevo ya 20 años peleándome con ordenadores y esas cosillas que salen en scripts o programas las encuentro tan habituales que lo hago casi sin darme cuenta... (en serio, sin fanfarronerías)

Por cierto, ESPECTACULARES las capturas, a ver si lo consigo en los Pirineos ;)

Complicado. El fichero no existe :))

EDITO: ejecuto via cmd...

D:\X-Plane 10\Custom Scenery\Z_Canarias_google>ter2pol.py . dsftool.exe


::: ter2pol.py BETA 1.0 - Cestomano - abr 2012 :::

STEP 1: Processing TER files...
Processed TER files: 587
Detected errors: 0

STEP 2: Processing DSF files...
   Processing +20-020 folder...
Converting '.\Earth from DSF to text as data\+20-020\+27-016_TER.txt'
ERROR: Error convertiong '.\Earth to data\+20-020\+27-016_TER.txt'
Traceback (most recent call last):
  File "D:\X-Plane 10\Custom Scenery\Z_Canarias_google\ter2pol.py", line 313, in
 <module>
    sys.exit(main())
  File "D:\X-Plane 10\Custom Scenery\Z_Canarias_google\ter2pol.py", line 306, in
 main
    (nDsf, nDsfErrores) =  procesaDsf(os.path.join(dirScenery, "Earth nav data",
 subcarpeta), dirDsftool)
  File "D:\X-Plane 10\Custom Scenery\Z_Canarias_google\ter2pol.py", line 122, in
 procesaDsf
    fTer = open(sTxtOrigen, "r")
IOError: [Errno 2] No such file or directory: '.\\Earth nav data\\+20-020\\+27-0
16_TER.txt'

D:\X-Plane 10\Custom Scenery\Z_Canarias_google>



Y yo, como Mou, me pregunto: pogque? pogque???

Me procesa los TER y produce los POL, pero no observo que me cambie el DSF  eso es normal ??? en cuanto a lo leer, querido Bokepacha, el problema es que solo se escribir y mal, lo imprimí porque leer en pantalla lo tengo fatal ya que al escribir, cuando me equivoco uso TIPPEX para corregir  :D :D :D

hasta que no vea una foto sacada a la pantalla en vez de darle al prtsc, no me lo creo!

No, este no es el caso. El archivo debería existir pues lo crea el propio DSFTool, debe estar dentro de +20-020 y debe tener el nombre original del DSF pero acabado así: "_TER.txt".

Pero qué pasó con la pintadera? tuviste que hacer algo más? El problema es que no he probado ninguna de las utilidades en Windows... y yo creo que acabo antes si lo hago en la máquina virtual :P

EDITO: Acabo de leer el Post de Bokepacha: creo que los tiros van en la línea de ejecución del DSFTool. Al windows no le gustan las comillas simples, sino las dobles  :-X

Intento cambiarlo y subirlo cuanto antes a ver ;)

Pos ala, me voy a comprar una mona y a merendar  :D

Quiero mi dinero de vuelta!!!

Eso no puede ser, ya que cuando alguien pone foto de la pantalla "LO BANEAS"  :D :D :D

 :D

A ver, a ver, no se peleen...  ;D

Descarguen ahora el ter2pol (http://dl.dropbox.com/u/1126231/X-Plane/ter2pol.py (http://dl.dropbox.com/u/1126231/X-Plane/ter2pol.py)) y pruébenlo ambos a ver si va. Si no, vuelvan a escribir lo que aparece y mañana lo miro (que ahora debo salir). Y lo pruebo yo mismamente en Güindos.

Ah, ya comencé el script para allanar las pistas...... eso sí, aunque tengo claro cómo hacerlo no tengo ni p*ñ*t*r* idea de si funcionará...  ::)

Ahora si que parece funcionar. Ala, lo dejo y me voy pensando si baneo a Jordi o no  ;)

Ea, que salía del curro y acabo de llegar a casa (ahora me espera el bar)


¡BINGO!

Puede que por eso mismo no me procesaba el DSF (tanto en pintadera como en ter2pol) y como no entiendo de Python ni lo comprobé dentro del script.
Después de hacer celdas con el pintadera como loco, lo tenía tan asumido que se me olvidó decirlo (sorry), tenía que tirar de XGrinder, una vez procesados todos los dsf con el pintadera se los metía de golpe y a esperar.

Quien saque pol de celdas interiores (sin costa) que me diga que tal va, porque yo, o almenos mi ordenador ser ríe de mi cuando cargo el escenario, con la malla hd o con la original, da igual, no le gusta  :D

Afirmativo, parece que los hace todo, voy a probar un vuelito con el ELA de Adrián

FUNCIONA DE MARAVILLA las fotos bien por donde he probado

Gracias José Ángel te debo una birra y algo más para Octubre, posiblemente  ;)

Ahora que ha acabado, tengo 2 tipo de DSF (uno ocupa nada y el otro bastante más) y los ficheros TXT. Que DSF dejo? El gordo no? El resto me lo puedo fundir?

Creo que es el liviano, si observas las fechas el gordo es el original, y los .TER igualmente para reciclar

Pues tiene que ser algo más, porque el tamaño del escenario se dobla y pasamos a 2 GB.

Lo de cambiar a mano toooodas las costas ufff entre varios se puede hacer, pero yo antes lo miraria a hacer en script, pero ahí poco puedo ayudaros por ahora.

Una APP a la 19 en GCLA

(http://img.photobucket.com/albums/v235/bokepacha/x-plane/GCLA_APP.jpg)

Eso si...la bajada de frames con el nuevo fotoreal es considerable. Por primera vez y con todo a tope (HDR, sombras y reflejos del agua) he visto 15-16 fps en la palma y en el sur de tenerife cuando nunca bajaba de los 23.

Es el más ligero, que sólo contiene las definiciones y coordenadas de los pol.

El gordo es el original del fotorreal con su malla y se puede eliminar.

Y los TER y POL se mantienen? Porque ocupa más de un 50% más?

Por cierto, he abierto un post aqui X-Aviation (http://forums.x-pilot.com/index.php/topic/3206-new-photoreal-and-new-hd-elevations-for-spain/page__pid__35507#entry35507)

Pero si quereis que lo borre o algo avisad. Me extrañó no ver nada al respecto.

Una APP a GCXO de regalo

(http://img.photobucket.com/albums/v235/bokepacha/x-plane/GCXO_pano.jpg)

tamaño real

http://img.photobucket.com/albums/v235/bokepacha/x-plane/GCXO_pano.jpg (http://img.photobucket.com/albums/v235/bokepacha/x-plane/GCXO_pano.jpg)


Me olvidaba: DONDE ESTÁN LOS ROQUES DE ANAGA!!!!???? Porqué no salen? Tongo! tongoooo!!! 8)

Buen día Compañeros...

Pues esto es una chulada, les quedo fantástico. Por desgracia yo trate de hacerlo pero no me resulta, creo que estoy colocando mal las cosas o estoy siguiendo mal todos los pasos; serían tan amables colocar unos pequeños pasos para realizar el cambio.

Utilizo Windows 7 Enterprise a 64Bits, he leído que están utilizando Linux y Mac.

Saludos


Continúen así.   ;D

Los TER se pueden borrar así como todos los archivos *_TER.txt *_POL.txt y *_201204XXXXX.dsf que quedan dentro de la carpeta +XX-XXX. Decidí dejar todos los archivos por si se quiere volver a la versión anterior (el DSF +XX-XXX_201204XXXX.dsf es el original). Pero vamos, se puede eliminar si se desea...

Sobre el foro X-Aviation genial !! A ver si me doy de alta y pongo alguna foto :-)


Jajaja, no están!!! Bueno, están pero planos! Eso se debe a que la malla original del XP10 no los contempla y por mucho que triangulicemos con la pintadera...... (por mucho que multipliques un 0, 0 se queda).

Tengo que modificar Pintadera para añadirle también las comillas dobles. Qué lata habrás tenido con el proceso, Grrr05  ;)

EDITO: Pintadera actualizado (problema de las comillas dobles-simples); ahora debería funcionar correctamente.

Por cierto, PLEASE, PLEASE, PLEASEEEEE... algún usuario de Mac podría probar alguno de los scripts y decirme si funcionan sin introducir parámetros??? Y si no, introduciéndolos.

Gracias, Edgar.

La mayoría han probado los scripts en windows (yo, en Linux). He puesto al comienzo de este hilo (en el post nº 1) los pasos necesarios para utilizar ambos scripts. Quizá se me olvida algo... pero en principio, no debería haber mayor problema (sobretodo con ter2pol, es más sencillo de utilizar).

Coméntenme los posibles errores que se vayan encontrando, por favor, a ver si pulo más los scripts y llegan a dejar de ser BETAs.

Ay que envidia me dais!! Tengo esta semana liadísima y encima el finde al igual no estoy así que poco podré avanzar.
Ni siquiera he tenido tiempo de pasarle el Ter2pol en las islas!


Ninguna lata, XGrinder en mano y Pintadera sin parámetros :D

De todas maneras necesitaba el X-Grinder para meter los nuevos rasters así que no fué ningun contratiempo.

Por el otro lado, he visto un par de celdas más en el 42º con los rasters mal georreferenciados y estoy a por la mitad del 41º (esta semana a paso de tortuga...)
También hay un fallo en la celda +42-001, que le puse la +40-001 y con el raster bueno. Puede que hayan aparecido parte de los Pirineos cerca de Teruel.
Actualizaré con todos esos errores subsanados.

¡Bien por el post en X-Aviation!  ;D

Con las texturas convertidas a POL tengo que bajar un punto las opciones del RENDERING pasando de texturas Very Hight a HIGHT  ya que me sale consumo de tarjeta de 1200 y solo tengo 1000, por otro lado, no he notado grandes diferencias en caidas de frames, muy curioso  ::)

Ajá! Algo así me pasa a mí. Consume más VRAM pero el rendimiento.... no lo he notado. Claro, en vez de dibujar unas capas, dibuja otras. Pero la memoria sufre.

Por cierto, recomiendo activar la compresión de texturas. La pérdida de calidad es inapreciable (sobretodo si los escenarios/aviones están bien hechos, con texturas DDS bien comprimidas) y la ganancia de memoria mucha.  :)

Respecto a los POL, encuentro errores que no se veían en el XP9: las uniones de algunos POL se notan (una línea del color de fondo) y de lejos, suele verse polígonos (texturas) que están detrás de los relieves...

Ahora que he tenido un rato he probado de nuevo y efectivamente, he tenido que bajar un punto las texturas, e igual que a vosotros, el uso de vram aumenta pero no noto una caída de fps significativa.

Ya pasaba antes de meterle los pol, pero con ellos queda bastante más acusado. Tiene pinta de ser un bug del mismo X-Plane (o de nvidia?).

Mas progresos  ;)


El Pedraforca tal y como se debe ver
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/pedraforca.jpg)

Montserrat - cara oeste
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/montserratW.jpg)

cara este
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/montserratE.jpg)

Un vuelo por los Pirineos YA !!!  ^-^


Acabo de actualizar los scripts pintadera y ter2pol con algunos cambios menores:

• ter2pol: ahora procesa también las texturas nocturnas si las hubiere
• Ambos scripts: ahora, por defecto, se eliminan todos los archivos temporales, salvo si utilizamos el modificador "-d" (debug mode)

NOTA sobre esto último: Se eliminan los archivos temporales pero no los archivos origen (eso nunca!  :D). Es decir, los archivos DSF originales y los TER se mantienen, por lo de si queremos hacer "marcha atrás".

Podrias sacar una version que deje el escenario preparado como si fuera nuevo? Osea, fuera temporales y ficheros que ya no se usen?

Es que sino a media escala...ir carpeta a carpeta es como un coñazo pero sin el como  ;)

Sí, añadir otro modificador (por ejemplo: "--ihavenofear"  :D) que lo haga. No es nada complicado.

Mañana lo añado.

Se me ha ocurrido algo para allanar las pistas, a ver si se puede plasmar en un script.

Localizar todos los vértices que hay dentro de un boundary y cambiar la altitud de -32768 a la altitud del aeropuerto definido dentro del apt.dat.

¿Simple no? No se si funcionaría, pero bueno, si los vértices siguen teniendo con la v10 el parámetro de altitud será por algo.
Tendría que quedar igual que si se desactiva lo de las pistas y el contorno del terreno, con la diferencia que estará listo para usar el vertextool y aplicar los desniveles correspondientes.
Claro que con el vertextool ya hay que meterle mano, pero por defecto quedarán todas las pistas planas.

Es que editando un raster que cada pixel son 25m de terreno, lo veo imposible para conseguir un posible badén o inclinación real de la pista, los triángulos de la malla en muchos casos tienen aristas de menos de 25m de longitud.

Hombre, como parche inicial bien, para poder volar con estos escenarios, pero si que hay que encontrar algo para poder tener badenes, porque son la parte que le da el toque de realismo en muchos aeropuertos. Por ejemplo en GCXO, aplanando a la altura del aeropuerto...pero es de los que tiene 3. La 12 a una altura, la plataforma a otra y la 30 ya ni te digo, ahí hundida al fondo.

Si solo se arregla usando el vertextool, pues se usa, aunque es bastante coñazo usarlo y si te equivocas en un solo dato has de empezar de cero, pero bueno...al menos si tenemos más vértices, podemos aplicar desniveles más reales.

Mi idea es utilizar el boundary para crear una imagen-máscara que permita copiar el raster antiguo en el nuevo, de forma que los aeropuertos queden igual que en el aeropuerto antes de meter el raster nuevo, es decir, con sus badenes y tal. Espero esta tarde adelantar el trabajo.

Teniendo dos scripts en cabeza (tuyo y mío), alguno debería funcionar  ;)

Por cierto, por lo que he visto, toda las mallas del XP10 tienen altura -32768 (se guía por el raster) salvo las líneas de costa... ¿no es así?  ???

Bueno a ver que sale  :D

En las mallas de la v10 si que he visto vértices con altura definida, pero no he sabido identificar si son líneas de costa.
Si es así, puede que sea algo provisional, pues los dsf tienen 3 definiciones de raster - Elevation, Sea_Level y Bathymetry, pero esta última no tiene ningun raster asociado. Quizás está implementado para crear las lineas de costa (habría que mirar en alguna celda de USA a ver como funciona si es que los hay), pero por nuestra parte, no hay datos de batimetría en el IGN.

Lo de la altitud de los vértices puede que se haya hecho para conservar la compatibilidad retroactiva, pero puede que gracias a ello también se pueda crear una malla "híbrida", entre elevaciones del raster y elevaciones definidas a mano.

Sí, lo de la barimetría lo espero con ansias para el futuro. Creo que en el blog Developer de XP lo mencionaban.

Sería ideal que la malla sólo defina la tierra, tanto lo que está por encima como por debajo del agua (barimetría) y el mar se genere automáticamente a partir del raster del sea_level. Así sería más sencillo definir las costas y se podrían crear numerosos efectos si se desea, como las mareas, oleajes... ver Outerra.  Que por cierto, debe haber datos públicos de barimetría pues el Outerra la implementa... (sé que para Canarias hay barimetría en IDEcanarias (http://visor.grafcan.es/visorweb/default.php?svc=svcIsobatas&lat=28.3&lng=-15.799999999999955&zoom=8&lang=es)).

Lo prometido es deuda!

Actualizados los scripts pintadera (http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py) y ter2pol (http://dl.dropbox.com/u/1126231/X-Plane/ter2pol.py) de forma que, utilizando el modificador -x se eliminarán todos los archivos de origen que no hagan falta.

¡OJO! Este modo es peligroso, pues si el resultado del script no es el esperado, perderemos los archivos originales. Recomiendo, en caso de usarlo, haber hecho copia de seguridad del escenario previamente. Quien avisa...............  ;D

Para más información, utilizar el modificador -h (ayuda).

...

Y por cierto, volviendo otra vez a mi pregunta de ayer... alguien que use MAC ha probado los scripts ? ? ? ? ? ?

Me gustaba más el Ihavenofear xDD

Lo pruebo esta noche.

(a mí también  :D)


Sobre el allanamiento de pistas:

He creado un script, apisonadora.py (http://dl.dropbox.com/u/1126231/X-Plane/apisonadora.py) :P que trata, como había puesto por ahí, de allanar las pistas utilizando el raster original justo para la zona del boundary (borde) indicado para cada aeropuerto que se especifique.

No obstante, los resultados no son los deseados... ¡¡sigue habiendo baches!! (quizá menos, pero los hay).

La razón que he podido dilucidar quizá sea porque el borde de los aeropuertos es muy estrecho. Voy a hacer unas pruebas "a mano" con un borde mayor a ver si rula...

Por otro lado, me he dado cuenta de que existen aeropuertos sin borde definido así que... ¿? Otra cosa sería construir un área aproximada alrededor de la pista (o de cada pista) para copiar el raster original. Nada, pruebas pruebas pruebas...

De todas formas, descarguen el script (si quieren) y pruébenlo. Si lo ejecutan con el modificador -d (debug mode) dejará unas imágenes temporales en la carpeta de uso. Una de ellas, "apisonadora_mask.tiff" es la máscara utilizada para la copia de los rasters (negro = no copia; blanco = sí copia). Se puede hacer pruebas con ella (p.e.: cargándola en el Photoshop como un canal alpha...).

El Uso:

Poner el script en la carpeta que tenga los DSF a procesar. Lo que se necesita es tener preparado (1) el raster original, (2) el raster de alta definición (SRTM25) y (3) los códigos ICAO de todos aquellos aeropuertos que deseemos procesar. Utilicen el modificador -h para más ayuda.

Por ejemplo, para el raster de Tenerife:


(el GCTS no lo procesará porque no tiene borde)

Uff, me voy a descansar un rato.........

Ah... ¡¡IMPORTANTE!! Se necesita tener instalado (a parte del Python) el ImageMagick (http://www.imagemagick.org).

Nada, ya no sé cuál es el problema  :(

He toqueteado a mano la máscara, rasters, etc. y no consigo quitar los baches, siempre queda una serie continua de badenes/cambios rasantes:

(http://dl.dropbox.com/u/1126231/X-Plane/ripple.jpg)

He probado a copiar del raster original una sección muchísimo mayor al aeropuerto y nada. He probado el filtro de desenfoque, varias iteraciones y nada. Siguen lo sbaches... ¿qué ocurrirá?

Me queda pintarlo todo a lo bestia, de un solo color... en fin, por probar...

EDITO: Sí, pintando toda la selección (grande) de un color, sí queda nivelado... pero demasiado perfecto, claro. Nada, a seguir investigando...

Bfff, menudo curro  ;D
Este asunto de los baches nos va a dar por *#&@

He terminado ya con el paralelo 41 y por ahora solo subiré rasters, y al igual que con el Ter2pol, que se lo haga cada uno que el Pintadera ya está estable  :P

Para crear las mallas HD usando el MDT25

-Crear una carpeta temporal y poner el Pintadera.py y el DSFTool.
-Descomprimir (7z) los dsf del Global Scenery que se vayan a usar para el escenario dentro de la carpeta temporal siguiendo la estructura de directorios de las celdas (carpeta temporal\Earth nav data\+XX+YYY).
-Arrastrar todos los dsf dentro del XGrinder y cuando termine de extraer todos los .txt y .raw eliminar los dsf.
-Editar todos los .txt (recomiendo Notepad++), al final del archivo hay dos líneas:
RASTER_DATA version=1 bpp=2 flags=5 width=1201 height=1201 scale=1.000000 offset=0.000000 G:\X-Plane Tools\st12\meshHD\earth nav data\+40+000\+41+003.txt.elevation.raw
RASTER_DATA version=1 bpp=2 flags=1 width=256 height=256 scale=1.000000 offset=0.000000 G:\X-Plane Tools\st12\meshHD\earth nav data\+40+000\+41+003.txt.sea_level.raw

Los números en rojo se deben sustituir por 3601 salvo en las celdas especificadas en los archivos leeme.txt de cada paquete de rasters. En este caso se deben dejar en 1201

-Sustituir los archivos *elevation.raw por los nuevos de alta resolución y volver a arrastrar todos los .txt al XGrinder y esperar a que aparezcan los dsf.
-Ejecutar el Pintadera (python pintadera.py -x), esperar a que termine y ejecutarlo de nuevo, la segunda vez tarda bastante más.
-Eliminar los .txt residuales e instalar los nuevos escenarios dentro de Custom Scenery, en una carpeta que empiece preferiblemente por Z para darle mínima prioridad.

Una primera ejecución del Pintadera multiplicará el número de triángulos en 4 respecto a la malla original, una segunda 16 veces, y el rendimiento puede quedar bastante afectado, aunque la calidad aumenta notablemente.
A criterio personal.

No he podido comprobar visualmente todas las celdas, pero si alguien ve errores (montañas mal ubicadas o que no se corresponden con las sombras que hay en el fotorreal...) que lo diga para corregir los rasters.


Cestomano puedes copiar esto al principio del post, junto con los links de descarga, si crees que me dejo algo lo modificas ;)

Canarias      http://dl.dropbox.com/u/59143574/rasters/rasters_canarias.7z (http://dl.dropbox.com/u/59143574/rasters/rasters_canarias.7z)
Paralelo 43º http://dl.dropbox.com/u/59143574/rasters/rasters%2B43-010_%2B43-002.7z (http://dl.dropbox.com/u/59143574/rasters/rasters%2B43-010_%2B43-002.7z)
Paralelo 42º http://dl.dropbox.com/u/59143574/rasters/rasters%2B42-010_%2B42%2B003.7z (http://dl.dropbox.com/u/59143574/rasters/rasters%2B42-010_%2B42%2B003.7z)
Paralelo 41º http://dl.dropbox.com/u/59143574/rasters/rasters%2B41-009_%2B41%2B003.7z (http://dl.dropbox.com/u/59143574/rasters/rasters%2B41-009_%2B41%2B003.7z)

Los enlaces de los rasters que puse anteriormente ya no funcionan, ahora son estos. Los de los dsf siguen ahí.

Por cierto, no te refieras a los datos de elevación como SRTM ya que pueden haber confusiones, si no a MDT25. La conversión de los rasters del IGN las hago con el formato de los rasters del SRTM, igual que los rasters originales de XP (seguramente me expliqué mal en su dia  :-[).
El SRTM se entiende como fuente de datos.

Sí, y mucho... Hay que investigar eso. En fin, toca seguir comiéndose el coco.



Gracias por el apunte! Todavía estoy algo (bastante) perdido en este mundillo...  :)

Cuando termine con la conversión de los rasters me pondré a ello.

Si te parece bien, conforme vaya sacando rasters por hileras de celdas, te paso los links por MP para juntarlos todos al principio del post.

Ferpecto!  ;)

mmm, creo que este script de Fabian y el QGIS pueden ayudar a comprender un poco más lo de las pistas...

http://www.alpilotx.net/downloads/tools-scripts/ (http://www.alpilotx.net/downloads/tools-scripts/)

(ver los triángulos)

EDITO: Aquí una muestra de Tenerife tras pasarle pintadera 2 veces:

(http://dl.dropbox.com/u/1126231/X-Plane/Tenerife_vectores_p2.jpg)

El archivo GIS ocupa 1.2 Gb !!! Es intratable.  Tarda una eternidad en cargar o en hacer zoom... Voy a probar con el original:

(http://dl.dropbox.com/u/1126231/X-Plane/Tenerife_vectores.jpg)

...y aumentando hasta GCXO, se puede apreciar como está bien definido:

(http://dl.dropbox.com/u/1126231/X-Plane/Tenerife_vectores_GCXO.jpg)

Y tras pasarle pintadera 2 veces:

(http://dl.dropbox.com/u/1126231/X-Plane/Tenerife_vectores_GCXO_p2.jpg)

No entiendo por qué al subdividir los triángulos aparecen baches!! Pensé que afectaban las zonas exteriores pero... no debería. Tiene que ser cosa del raster... habrá que ir píxel a píxel. A ver si consigo cargar el mismo en el QGIS...

Una combinación del DSF y el WMS del callejero de Tenerife:

(http://dl.dropbox.com/u/1126231/X-Plane/Tenerife_vectores_GCXO_comb.jpg)

Al menos, se puede saber hasta dónde debe llegar la selección de terreno a tratar. Ahora queda saber... cómo tratarlo.  :D

Quien se atreve con el vertextool?  ???

Encuentro muy raro eso de que se concentren tantos triángulos exclusivamente en la zona de la pista.
Los pixels del raster son mucho más grandes que esos triangulitos y se forman los baches entre pixel y pixel, aunque uno este justo con un punto mas en la escala de grises respecto al pixel contíguo. En este caso, los rasters originales al tener pixels nueve veces más grandes, el efecto queda algo suavizado como pudiste comprobar con el "apisonadora"

Muy mal asunto y por ahora no se me ocurre nada más...   :-[

Uff! ni nombrarlo! Lo utilicé para modificare la malla de GCHI en el XP9 y no quiero ni acordarme (aunque es mejor que hacerlo a mano, como hice con la malla de El Revolcadero :P). Sólo pensar en utilizarlo con la malla del XP10 da pavor... (eso sin haberle pasado pintadera, jaja)

¡ EUREKA !

He conseguido reducir bastante, y automáticamente, los baches en GCXO. La solución me la diste tú, Grrr05.

En efecto, en la malla original no se notan los baches proque los píxeles del raster son grandes. Lo único que hice fue modificar el código de "apisonadora.py" para que, al reescalar el raster original (para copiar la parte correspondiente al aeropuerto), lo hiciera no bicúbicamente (supuesto suavizado que ya he comprobado que ni haciéndolo en el Photoshop funciona), sino mediante el "vecino más cercano". Es decir, los píxeles se conservan tal cual.

Sólo he hecho una prueba en GCXO pero la pista queda bastante bien; se notan algunos badenes aún pero son suaves y... quizá reales.

No obstante, aún queda modificar un poco el script para que coja zonas mayores y, sobretodo, zonas de aeropuertos sin boundary... pero un principio es un principio.

Tendré que hacer más pruebas hasta corroborarlo del todo (si alguien más se anima a intentarlo, mejor que mejor).  :)

Os estais metiendo un curro acongojante, soys unos CRACK's

Yastábien! baneado!!!!  :D

 :D  :D  :D

(gracias!)

  Yo aquí no escribo que me da vergüenza.  Menudo nivelado el del foro oiga.
 
  Enhorabuena por todo el trabajo y los magníficos resultados.

  Un saludo.

He instalado una copia antigua del escenario de canarias, para probar el último pintadera y me dice sto:

Processing DSF files...
   Processing +20-020 folder...
      Processing data from DSF to target DSF...

Traceback (most recent call last):
  File "D:\X-Plane 10\Custom Scenery\z_Canarias_google2\pintadera.py", line 422, in <module>
    sys.exit(main())
  File "D:\X-Plane 10\Custom Scenery\z_Canarias_google2\pintadera.py", line 415, in main
    (nDsf, nDsfErrores) =  procesaDsf(os.path.join(dirScenery, "Earth nav data", subcarpeta), dirDsftool, bDebug, nRecLon1, nRecLon2, nRecLat1, nRecLat2)
  File "D:\X-Plane 10\Custom Scenery\z_Canarias_google2\pintadera.py", line 171, in procesaDsf
    tri.append( Triangulos(sPalabras[1], sPalabras[2], sPalabras[3], sPalabras[4], sPalabras[5], sPalabras[6], sPalabras[7]) )
IndexError: list index out of range

he estado mirando al rededor de las líneas de código que marca, pero no le encuentro el sentido. He probado con pintadera.py . dsftool.exe pero da lo mismo

Como les propuse a Cestomano y a grrr05, envié un correo a Austin y a Ben comentándoles muy resumidamente este proyecto. De esta forma la gente se lo puede descargar de la zona de descargas para hacer pruebas y análisis de rendimiento en sus equipos sin tener que utilizar el script para realizar la conversión.

Esto es lo que les comenté, ya traducido:

Dos miembros de x-plane.es están trabajando en un proyecto para obtener malla de terreno de mayor definición (similar al proyecto HDmesh de Andras).
El script subdivide los triángulos de la malla para obtener unos más pequeños y conseguir mejor definición. También en otro proceso se obtienen imágenes raster con alta definición para las elevaciones a partir de bases de datos españolas (MDT25 de 25m de resolución).

El proyecto aún está en desarrollo (fase beta) y quería subir la zona de Las Islas Canarias a la zona de descargas de la Web.
Como se ha modificado parte del ArtWork de la malla necesitaba autorización antes de subirlo a la zona de descargas.

Les mande cuatro capturas para que vieran el resultado.

Austin da el visto bueno, y además dice que tiene buena pinta:

yah thats fine with me
looks good!

Es su forma de contestar, el mail más largo que he recibido de él no ha superado nunca más de dos líneas, pero cuando habla se enrrolla como las persianas.
Así que la zona de las Islas Canarias se puede subir a la zona de descargas.

Solo se subirá ahora la zona de las Canarias, porque ya sabemos y así se lo dije a Jose Angel y a Albert que muchos utilizan esto para llenar de tierra zonas de agua, vosotros ya me entendéis, y no iba a pedirle a Austin subir el mesh de todo un país.

Dos líneas!!! Te ha escrito dos líneas!!!

A mi me lo escribe siempre en una  :D

Ya de por si es excelente que Responda...  Sera que le podemos escribir y recibir respuesta del señor Bill puertas... ?

Felicitaciones por este gran desarrollo.   :)

Carlos

Otra cosa no, pero Ben siempre responde los correos y bastante rápido.

Cuando dices una "copia antigua del escenario de canarias" ¿te refieres a un escenario que no es del X-Plane10? Lo digo porque veo la carpeta "z_Canarias_google2" y me suena a escenario hecho con el G2XPL, es decir, para XP9.

Si es así, Pintadera está pensado sólo para mallas del XP10 y no sé cómo funcionaría en el XP9. De todas formas, voy a hacer unas pruebas yo a ver si rula...

Gracias por el "testing"  ;)

Y gracias Emilio por el contacto con LR.



EDITO: Comprobado. El error se da al intentar usar el script con mallas del XP9 (creadas con el G2XPL, en el caso que comprobé).

Las mallas del XP9 pueden tener una casuística de parámetros en los triángulos del agua que no había tenido en cuenta (en XP10 no se da, que yo sepa). He modificado el script para que no dé el error.

No obstante (1) el resultado puede ser imprevisible (por ejemplo, me desaparecen zonas del agua) pero (2) utilizar "pintadera" con mallas del XP9 no tiene sentido, ya que dichas mallas no están asociadas a ningún raster y subdividirla en triángulos no afectará a la calidad gráfica del escenario final, aunque sí al rendimiento (negativamente).

En definitiva:
(1) Utilizar "pintadera" sólo con mallas del XP10.
(2) Se puede utilizar con el XP9 sólo de prueba, pues no da ningún resultado apreciable.

(OJO! "ter2pol" sí que está pensado para mallas XP9, de hecho, las mallas creadas con el G2XPL)

Eurek.................. aghhh!

 :D

No consigo de ninguna manera arreglar GCHI !! Ni a mano ni a máquina. No lo entiendo, incluso copiando el raster original en una zona grande alrededor del aeropuerto siguen los baches.

Lo curioso es que si cargo la malla en el QGIS aparece esto:

(http://dl.dropbox.com/u/1126231/X-Plane/QGIS%20GCHI.jpeg)

Si aumentamos un poco más la cabecera 16...

(http://dl.dropbox.com/u/1126231/X-Plane/QGIS%20GCHI%20detalle.jpeg)

Y un poco más:

(http://dl.dropbox.com/u/1126231/X-Plane/QGIS%20GCHI%20detalle%20m%C3%A1s.jpeg)

Hay una burrada de "minitriángulos". Ahora puedo entender por qué salen esas aristas tan finas en el simulador (especia de zurcos) pero...  al mismo no lo entiendo, pues se supone que todos los vértices de esos triángulos deberían coger el mismo píxel del raster. ¿O cogerá una media de los píxeles cercanos? Entonces sí podría entender el porqué de dichos baches ¿se podrá seleccionar de alguna manera qué media de píxeles debería coger un vértice de un triángulo determinado?

Por otro lado, se me ocurre modificar pintadera para tener la posibilidad de no procesar triángulos pequeñitos. Lo malo es que se quedarían vértices "a medias" (vértices de triángulos pegados a aristas de otros). Eso podría generar algún artefacto visual...

mmmmmmmm

Uy la que se ha liao en día y medio que he estado fuera.

En primer lugar agradecer a Emilio por pedirle el consetimiento a LR.

Sobre los malditos baches, la idea de ampliar por aproximación el raster original me pareció muy buena, pero se me ha ocurrido (sin probarlo aún);
¿Y si probamos de reducir el tamaño de la capa del raster original (por aproximación también) al 50% o al 25%, y despues se aumenta a 3601x3601, con el mismo filtro?

Se perdería una gran cantidad de datos de elevación, suavizando aún mas la pista (creo), quizas no se consiga meter un posible badén pero sí conservar la inclinación real.

Jaja, sí, mucho mensaje...

Con GCHI he probado de todo. A parte de la apisonadora, con photoshop, copiado y pegado del raster original, del propio, pintado de un degradado, etc... y fatal!! Y ahora acabo de probar lo que dijiste y... lo mismo! La única solución que funciona es aplanar todo el área con un mismo color, sin variación alguna. Pero claro, para eso desactivas las slopped runways y ya está.

Lo curioso es que la misma malla HD con el raster estandar (1201) va bien pero si metes el raster 3601 aunque tengas esa zona exactamente igual que en el raster 1201... queda mal.

Probé apisonadora en GCGM (La Gomera) y lo empeoró. Originalmente sólo tenía 3 baches... y al procesar ganó muchos más y más grandes (quizá sólo funcione con aeropuertos lejos de las costas).

Lo curioso es que dos vértices de triángulos muy muy cercanos tengan alturas diferentes cuando ambos están en la misma zona del raster (el mismo píxel). De ahí deduzco que el cálculo de la altura de los vértices no depende del "píxel" del raster en que se encuentre sino alguna otra fórumula... ¿y qué fórmula es esa? Pues ni idea pues la wiki de x-plane no dice nada al respecto (aún).

Sólo se me ocurre una solución... preguntar a Andras (http://www.alpilotx.net/contact/).  ::)

Pues puede que no nos quede otra, de todas maneras Andras ya tiene conocimiento de este proyecto, posteó en el hilo que abrío Bokepacha en X-Aviation.

He estado investigando con los diferentes parámetros de RASTER_DATA, con el "scale" y "offset".

Puede que la fórmula que dices se base en el escalado;

 Scaling factor to apply to DEM pixels post-load

He probado con valores desde decimales hasta 1000, incluso 0, pero no hay ningún cambio visible.
Al igual que el "offset" que deduzco que es la "exageración de altitud".

Ningún parámetro, salvo los del tamaño y bpp, funcionan, lo que me lleva a pensar, que al igual que el ATC, HDR... son novedades de la v10 y quizás no está del todo implementado.
Tambien hay el parámetro "version=1", puede que el uso del formato RAW sea provisional y/o opcional, una vez leí no se si en la wiki o en el blog que por ahora sólo se permitía este formato.

De todos los rasters que he hecho, conservo todos los archivos de conversiones intermedias (hgt, gtiff, etc...), por si en el futuro se pueden modificar.

Otra cosa, los rasters del IGN contienen datos de elevación falsos en zonas llanas y como no, en aeropuertos (unas páginas atrás hay una captura con el MDT original de LESU), así que el Apisonadora no va a ser una opción, si no casi obligatorio.

Andras sabe de vuestro proyecto, pero no mucho. Los detalles os los dejaba a vosotros :)

Cierto! Le mandaré un mensaje y lo pondré al día, simplemente para preguntarle la duda de los vértices. A ver si dice algo...


Sí, yo probé a cambiar Flags a 1 (eliminando el tercer bit) a ver si hacía algo y nada...

Por lo que he leído en Developer, hay puestas muchas cosas "ahí" que aún no están preparadas pero que lo podrán estar, como la barimetría, que ya habíamos comentado. De hecho, incluyen el raster del nivel del mar pero NO se usa... será para un posible futuro. Sobre el terreno es posible que incluso no hayan reflejado aún el introducir rasters de más de esa resolución y el problema de los baches sea un error no controlado por Laminar... (por lo cual, es bueno contactar con Andras más aún).

No he probado a añadir un segundo raster a ver si la cosa peta.

EDITO: ya he enviado el mail a Andras  :)

Ok a ver que dice, pero sus mallas HD tienen el mismo problema con rasters de 3601x3601, ya sean los del IGN o los originales ampliados, aunque no tan exagerado, por su menor número de triángulos.


Yo si, un segundo (tercero contando el sea_level) raster en el DSF sirve para la batimetría.

Entre otras cosas, intenté usar el raster del IGN a modo de mascara pintando todo el aeropuerto como blanco (NODATA) y añadí el original a 1201x1201 debajo, a ver si actuaba como transparéncia pero como era de esperar, ná de ná :D

Al volver a pasar el dsftool con los tres rasters, este último se habia renombrado automaticamente como +xx+yyy.txt.bathymetry.raw

Va por el orden en que estan los RASTER_DATA en el dsf

1º - elevation
2º - sea_level
3º - bathymetry

No he probado a añadir un cuarto, ya que viendo el esquema, no tiene mucho sentido.

Actualizados los rasters en el primer post: Canarias, Baleares y paralelos 40, 41 y 42 (gracias, Grrr05).




Ah, pues más tarde respondo a Andras (a su respuesta) y le pongo ese dato, pues me había comentado la posibilidad de que pudiera ser cosa de los los triángulos alargados...


¡Ajá! Claro, lo pilla como barimetría pues está en la definición, al principio del archivo. ¿Pero y si en dicho cabecero ponemos dos veces elevación?

1º - elevation
2º - elevation
3º - sea_level
4º - bathymetry

Y al final, ponemos como primera capa el raster 1201x1201 original sólo con el aeropuerto; lo demás a NO_DATA (no sé si el valor del píxel es, entonces, el máximo). Y como segunda capa la del MDT25 completa. (y tercera sea_level, que no se usa actualmente).

¿Petará? ¿hará algo diferente?

Pues claro! El RASTER_DEF  o:ps

Si tengo un rato esta noche lo pruebo, lo curioso es que con el raster del IGN con el agujero blanco (no se el valor exactamente, lo pillé con el cuentagotas de un raster original) me creaba en la malla eso mismo, un agujero, algo más profundo que el nivel del mar y con paredes, todo el autogen y carreteras se hundían hasta el fondo. Si lo pintaba de negro, hacia lo mismo pero con una especie de muro picudo e irregular en los bordes, no demasiado alto sobre el nivel del terreno.

Por cierto, el Pintadera me dá problemas en la celda de Madrid (+40-004);
La primera iteración me pinta el terreno como si fuera un desierto, toda la celda con tierra, aunque la malla la trata correctamente.
La segunda no la termina, pero ya es por error del dsftool, puede que por la cantidad de segmentos de carreteras que hay. Cuando el dsftool se cuelga me deja un txt de casi 900mb, y al meterlo en el XGrinder, ni se entera.

Lo he tenido que dejar sólo en una iteración, lo del terreno no importa mucho si se van a pegar las ortofotos, pero la malla... es una lástima por la Sierra de Guadarrama, la parte que abarca dicha celda se nota que la resolución del terreno es inferior a las celdas adyacentes, a parte de los problemas que hay de que los vértices de dos celdas juntas no coincidan por el distinto número de ellos, aparecen pequeños escalones con el cielo debajo.

EDITO: No me acordaba de esto (wiki);

If an elevation mesh is present, the normal vectors can be left as 0.0 – X-Plane will calculate them from raster data.

¿Sería mucho jaleo hacer una modificación del Pintadera para que deje los vectores de normales en 0.0? (sólo de los vértices que tengan -32768 de altitud y conservando los dos siguientes parámetros, en caso que los tuviera)
Sólo para probar, a ver si tiene algo que ver con los baches.

Bueno, ya probé lo de un segundo raster pero... :( Aunque lo compila bien, no lo usa. Al parecer el segundo raster machaca al primero... y todo sigue igual.

Sobre lo de Madrid, te da un error así?


Esto es lo que me sucede, por ejemplo, si intento usar pintadera para la segunda iteración con El Hierro (donde GCHI), por ejemplo. Pero bajo Linux. Si lo hago en Windows no ocurre (aunque sí ocurre si lo intento con una tercera iteración) y no sé a qué se debe, quizá triángulos muy muy pequeños.

Sobre lo de que sólo deja tierra en la primera iteración, ni idea!! tengo que comprobarlo. Y sobre lo de los valores 0, 0 el texto dice que se pueden dejar a cero porque las normales las calcula a partir del raster así que supongo que da igual el valor. No obstante, creo recordar que Pintadera las deja a cero salvo si alguno de los vértices de la triangulación tiene un valor de altura, pues cerca de las costas es lo que ocurre y, en ese caso, haya la media.

Puedo probar a que lo deje siempre a 0, 0 salvo si todos los vértices de los que parte el cálculo tienen valores de altura definidos.

Y sí, lo de los escalones es lógico si no se aplica el mismo número de iteraciones. De hecho, pasará en la unión de las celdas con Francia, supongo. Eso mismo pasa si se utilizan los parámetros de Lat Lon de Pintadera o si añado la funcionalidad de no subdividir triángulos muy pequeños (quizá para evitar el error del que hablábamos al principio), aunque en este caso, los triángulos "no dibujados" (azules celeste) serían muy pequeños.

En fin, a probar de todo un poco... voy a ver lo de las normales.

EDITO: Acabo de probar el raster MDT25 a la celda de LEMD (+40-004) y ha desaparecido, efectivamente, los árboles, edificios, etc. y ha quedado todo como un desierto....... pero sin haber usado pintadera!!!

Es decir, ese efecto no tiene que ver con toquetear la malla... quizá un defecto del DSFTool al volver a convertir a DSF? (tamaño del archivo?)

Ah, y después probé a pasarle Pintadera (la versión actual, 3.6) dos veces y no me dio error...  ???

No tenemos depurador en la consola de Win :D  Me dice que DSFtool.exe se ha cerrado inesperadamente.
Ninguna referencia del error por parte de Python.

Sobre lo del autogen desaparecido, no me había dado cuenta ya que tanto árboles como edificios que uso son escenarios del OSM y lo excluyen, sólo he visto el terreno, tooodo marrón.
Tengo que acostumbrarme a hacer pruebas con el Custom Scenery limpio...

Parece como si el DSFTool tuviera un límite para el tamaño del archivo, y si éste es demasiado grande, lo "trunca", no obstante, las carreteras v10 siguen allí.
Creo que en Barcelona pasaría algo similar de no ser que la mitad de la celda es mar. Hay mucho autogen en ambas celdas, y sobre todo muchísimos nodos de carreteras, cosa que engorda el DSF de forma considerable

Saludos Compañeros.


Ando vuelto loco, pues no puedo acceder a cambiar los archivos .ter a .pol, por desgracia desconozco la sintaxis...

No sé donde colocar los archivos...

No se si debo de crear una carpeta opcional dentro de Custom Scenery y nombrarle como yo quiera o tiene que tener un nombre especifico.

Probé con 2 opciones :

C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\Earth nav data\+10-100

C:\X-Plane 10\Custom Scenery\MMAA_FOTO

en cada uno coloco los 2 archivo y solo me da lo siguiente:

ter2pol.py, line 266 

except getopt.error, msg:

SyntaxError: Invalid syntax


Ayuda...  :'(

Ese error te lo da nada más comenzar el script, justo al intentar leer los argumentos de entrada. Así que tiene que ser cosa de tu Python.

Asegúrate de tener la última versión instalada (del Python).

Ah, y si la carpeta que quieres tratar es:

C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\Earth nav data\+10-100

Debes poner ter2pol.py y el DSFTool.exe dentro de: C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\

Un detalle que podría tener que ver con el tema de los baches, cuando trabajaba con LERS el edificio de la terminal (el grande) lo colocaba bien en un extremo pero flotaba cera de la taxiway y si lo bajaba con el Blender, pasaba al revés, probé lo que comento Vonhinx en http://www.x-plane.es/modules/smf/index.php?topic=6635.0 (http://www.x-plane.es/modules/smf/index.php?topic=6635.0) y curiosamente me llevó de coronilla, el onjeto quedaba perfectamente pegado al terreno, pero en el taxi me aparecieron baches y el avión pegaba unos brincos que ni aparato trialero, quizas creando un objeto con textura alfa para que no se vea encima de la pista podria eliminar esos "socabrones", en fin solo estoy pensando "escribiendo"

Gracias, Jordi.

Aún no lo había escrito, pero Grrr05 hemos estado intercambiando ideas por email y hemos descubierto (99% seguro) la causa del problema: Photoshop.

Efectivamente, al trabajar con Rasters de 16 bits necesitamos una aplicación para el tratamiento de los mismos que funcione a 16 bits y Photoshop... no lo es.  >:( Para ser exactos, trabaja a 15 bits (se come uno). Esa falta de precisión (la mitad) hace que si intentamos hacer un degradado o un suavizado del entorno, falten datos y el resultado siga con baches.

He probado a hacer suavizados mediante ImageMagick (que sí puede trabajar a 16 bits reales) y los resultados son positivos. Ahora Grrr05 está probando con los rasters originales -pues llevaban algo de proceso "photoshopiano"- por si el problema se puede arreglar de raíz y no haga falta pasarle la "apisonadora".

Ay ay ay, este Photoshop y sus bits multiplexados...  :-t-

Eso sí, la cosa marcha y con buenos resultados ;D

 Muchas gracias estimado Cestomano


La versión instalada del Python es :

Python 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>>

La carpeta que quiero tratar se encuentra en está dirección:

C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\Earth nav data\+10-100 ; (+16-100)  Que equivale al Aeropuerto de Acapulco en México. (En está carpeta se encuentran varios DSF de regiones cercanas, que integran las coordenadas +10-100, de los cuales estaré también intentando hacer).

Ahora lo que no entiendo es:

1. Debo de hacer una carpeta para guardar los archivos ya convertidos  a X-plane 10, por ejemplo:

C:\X-Plane 10\Custom Scenery\MMAA_FOTO ó  en X-Plane 9 y de ahí trasladarlos al 10.

2. Colocar los archivos  ter2pol.py y el DSFTool.exe  dentro de que carpeta

C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\  ó  C:\X-Plane 10\Custom Scenery\MMAA_FOTO

3. Una ves colocados los archivos los llamo desde CMD de Windows o directamente desde  Python (command line)

4. Colocar la siguiente sintaxis : C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\python ter2pol.py . DSFTool.exe en cmd ó llamar a Python desde cdm

C:\ cd Python32

C:\Python32>

Python 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>>

y a continuación de las >>> escribir la sintaxis


Una disculpa compañero ya que parece un interrogatorio   :(, pero sinceramente no conocía la programación del Python.


Gracias.

X-Edgar

Primero debes crear un PATH a la carpeta de Python.

Botón derecho sobre Equipo (o Mi PC) -> Propiedades -> Opciones avanzadas -> Variables de entorno
En la ventana "variables de sistema" tienes que buscar la línea PATH y darle a editar;
Al final de todo escribes "C:\Python32" o la carpeta donde tengas el Python. Recuerda que seguramente tendras más definiciones, hay que seraparlas por ";" puntoycoma.

Después, desde CMD vas a la carpeta donde tengas el escenario fotorrealista (C:\X-Plane 9\Custom Scenery\z_g2xpl-terrain\)
Asegúrate que ahí dentro tengas también el DSFTool.exe y el Ter2pol.py

Previa copia de seguridad del escenario, ejecuta el script

--> python ter2pol.py

Cuando termine tendrás dos archivos DSF en la carpeta \Earth nav data\+10-100
Tienes que eliminar el que se llame +16-100_XXXX_XXXX.dsf y dejar el de menor tamaño.

Luego copia la carpeta z_g2xpl-terrain y se la metes al X-Plane 10, tal cual, como escenario adicional.

Saludos compañero.


Seguí las instrucciones al pie de la letra, pero no resulto al momento de colocar la sintaxis me da lo siguiente:


(http://s18.postimage.org/wxccb8brp/CMD_II.jpg) (http://postimage.org/image/wxccb8brp/)


Creo que estoy colocando algo mal.


Muchas gracias por la paciencia.


Saludos.

Igual es problema de la versión de python. Yo creo que no tengo la 3.2.3 sino una anterior.

Yo estoy utilizando la 2.5.4.

Prueba con cualquiera que sea 2.x.x ya que es distinta a la 3x.

Yo tengo la 2.7.2, que es la última que se supone que es compatible con x-plane.

También uso PYTON 272

aparte unas imágenes dee los resultados una vez se elimina el mar que sobra y que se superponía al de x-plane

(http://i178.photobucket.com/albums/w271/jorduran/RobinsonR22BetaII_1.jpg)

el puerto de Barcelona gana un monton tras modificar parte del escenario Catalunya

(http://i178.photobucket.com/albums/w271/jorduran/RobinsonR22BetaII_2.jpg)
(http://i178.photobucket.com/albums/w271/jorduran/RobinsonR22BetaII_3.jpg)

Estupendas imágenes, Jordi. Has metido buena tijera...  ;)


¡ATENCIÓN! Los rasters que hay para descargar en el primer post están en proceso de reconversión. Se ha llamado a obras públicas y está procediendo a alisar las pistas. Cuando estén actualizados, pondré un aviso. De momento, sólo descargarlos a modo de prueba (si se desea).

El procedimiento de alisado de pistas (sin usar el Photoshop) da bueno resultados. Aún así, si algunas pistas no quedan lisas del todo, les dejaré una apisonadora portátil para quien quiera darles un repasito.  ;D

He actualizado el paquete de rasters de Canarias para descargar que hay en el primer post. Ahora sí estan integramente en 16bits  ;D

Las pistas han quedado bastante más suavizadas que antes, pero aún falta un ligero toque de Apisonadora.

Cuando esté todo el asunto resuelto se publicará el escenario de Canarias completo, como se dijo anteriormente.

Iré actualizando los rasters de la península por el mismo orden que hay ahora, y cuando termine la reconversión continuaré con los dos paralelos restantes.

COmo me quiteis la pendiente de GCXO, sus demando  :D

....Y atornillamos la apisonadora en el centro de una rotonda,  8)

¿Así?  Aún quedan pequeños baches (nada que ver con los anteriores) pero esto es arregla... y si no atornillamos la apisonadora  :D

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/GCXO1.jpg)

Hay que tener en cuenta que ahora los rasters tienen 16 bits vs los 15 bits que tenían antes, con lo que se dobla la precisión en cuanto a elevación, y debería ser posible suavizar conservando las pendientes

Genial, mañana pongo a prueba la nueva apisonadora (le quedan unos retoques aún) a ver si mejora :)

El principal problema de la apisonadora son las pistas que están muy cerca de un acantilado, es decir, El Hierro o a la Gomera (hablando de las islas). Pero vamos, incluso se podría hacer un (futuro) retoque a mano.

A ver qué nos depara el jueves!  :-n-

Así así, con la plataforma bien en pendiente, como la de verdad!!!  :D :D

Por cierto, la bola mágica también me ha dicho cómo hacer una aplicación que recorte automáticamente las zonas de mar en las texturas convertidas con el ter2pol... pero no me ha dado muchos detalles, sólo a grandes rasgos, y que la tarea podrá ser laaarga...  ;D

Buen trabajo

Donde tenemos que ir a buscar a la "brujita"  :D :D :D :D que a mano  :-c- :'(

Aaaaajuuaaaaaaaa.... compañeros.


Por fin pude logre convertir los ter a pol, utilice el 3.2, me baje al 2.6 y siguiendo sus instrucciones me encontré el 2.7.2 y también el 2.7.3 que es el que utilice.


Les envío unas fotos, para que me opinen que hacer con las texturas en negro y como pueden ver hay una laguna inmensa hacia el norte del aeropuerto a la cual se le llama Laguna de las ilusiones en el ambiente aeronáutico (Laguna de 3 palos, nombre original)...  :D   No se sabe nada respecto a la creación de ríos y lagunas, ya que en mi caso tendría que sacar una satélite y pegarla.

En el X9 les colocaba una textura en tono verde simulando la imagen satelital utilizando el OverlayEditor, pero para el X10 el OverlayEditor  muestra las texturas y el mesh cada vez que quiero mover un objeto o colocar una textura para ocultar los cuadros negros se bloquea anulando, re-intentando u omitiendo.

Otra pregunta - algo fuera del tema:

En el X9 cuando uno iniciaba una aproximación e iniciaba procedimientos para el aterrizaje, el avión por lógica tendía a levantarse de nariz por la reducción de velocidad y a la ves nos quitaba la visibilidad del panel si en este caso utilizábamos el 2D. Recuerdo que para volver a ver, manipulavamos dos teclas y se bajaba la pantalla, en X10 está opción creo que se perdió ya que solo se puede utilizar siempre que este uno afuera de la cabina y son las teclas R / F.

Saludos y gracias a todos por sus instrucciones para poder visualizar mis imágenes satelitales.


Un Abrazo


X-Edgar


(http://s15.postimage.org/eqybagmkn/737_1.jpg) (http://postimage.org/image/eqybagmkn/)

(http://s15.postimage.org/57omgzz2f/ACA.jpg) (http://postimage.org/image/57omgzz2f/)

(http://s15.postimage.org/gy2jydruv/Overlay_Editor.jpg) (http://postimage.org/image/gy2jydruv/)

Ahora se está usando el WED - World Editor que manipula los escenarios y los aeropuertos, aunque luego no puede usarse el Overlay Editor, por lo menos me pasa a mi. Eso hace que el terreno no se vea o no lo veo  ::)

Actualizado el script apisonadora (http://dl.dropbox.com/u/1126231/X-Plane/apisonadora.py), encargado de allanar un poco más las pistas de los aeropuertos (y plataformas).

He probado todo tipo de desenfoques, suavizados, etc. pero... sigue sin allanar del todo las pistas. Un poco mejor quedan.

Si quieren probar, les dejo Tenerife HD (mallas con pintadera y raster renovado por Grrr05):

http://dl.dropbox.com/u/1126231/X-Plane/ZZZ_Tenerife_prueba_apisonadora.7z (http://dl.dropbox.com/u/1126231/X-Plane/ZZZ_Tenerife_prueba_apisonadora.7z)
(se está subiendo ahora mismo, no sé cuánto tardará)

Pueden probar en GCXO y GCTS; el segundo tiene más baches  :-X

Órdenes utilizadas (con apisonadora):

python apisonadora.py -r7 +28-017.txt.elevation.raw GCTS
python apisonadora.py -b7 +28-017.txt.elevation.raw GCXO
python apisonadora.py -r4 +28-017.txt.elevation.raw GCXO

(para más información de uso, poner: python apisonadora.py -h)

Ahora tengo en mente otro tipo de proceso de las pistas, un poco más manual, pero que para algunos aeropuertos podrá ir bien. A ver cómo sale la cosa...

Esta foto la acaban de tomar desde una avioneta del aeroclub:

(http://dl.dropbox.com/u/1126231/X-Plane/GCXO_hundido.jpeg)

Aún así, hay quien se ha aventurado a despegar y aterrizar un Aermacchi  :D

(http://s16.postimage.org/ubvu1t0u9/339_2.jpg) (http://postimage.org/image/ubvu1t0u9/)

(http://s16.postimage.org/l5djeivlt/339_3.jpg) (http://postimage.org/image/l5djeivlt/)

(http://s16.postimage.org/p5koqrm2p/339_4.jpg) (http://postimage.org/image/p5koqrm2p/)

(http://s16.postimage.org/m04oeasu9/339_5.jpg) (http://postimage.org/image/m04oeasu9/)

(http://s16.postimage.org/uwfgi8jgh/339_6.jpg) (http://postimage.org/image/uwfgi8jgh/)

(http://s16.postimage.org/vagshu3k1/339_7.jpg) (http://postimage.org/image/vagshu3k1/)

(http://s16.postimage.org/4qo7fp30h/339_8.jpg) (http://postimage.org/image/4qo7fp30h/)

(http://s16.postimage.org/dmyzjmtmp/339_9.jpg) (http://postimage.org/image/dmyzjmtmp/)

Eso sí, la pista ha quedado lisiiiiiiiiiiiiiiita...

(sigo investigando)

¿Le has acoplado una draga a la apisonadora o que? :D :D

Van a rodar cabezas por esto.... 8)

Eso es una muy buena zona para practicar con helicópteros  :D :D :D :D

Jaja, no es mala idea. Deberíamos hacer nuestros propiios raster, con mala leche. El Terragen puede ser una buena herramienta para ello...  ;D

Bueno ¡POR FIN! Apisonadora beta 2 (http://dl.dropbox.com/u/1126231/X-Plane/apisonadora.py).

Al final conseguí arreglar convenientemente los filtros de suavizado y que funcionen como tiene que ser. De todas maneras, no todo son buenas noticias: los baches han desaparecido pero... han sido sustituidos por escalones!!

Me explico: el problema de los rasters (de momento, hasta que LR cambie las especificaciones) es que la resolución "de profundidad" de los mismos es de metros. Es decir, el más mínimo cambio de altura se traduce en un metro más.

Si tienes una pista con desniveles de altura y pocos triángulos, no hay problema (DSF originales) pues los triángulos son largos y la diferencia de altura se extiende en varios metros de distancia. Pero cuando tienes muchos triángulos (tras pintadera), estos son más cortos y la diferencia de altura se extiende en pocos metros (mayor desnivel repentino).

Esto lo puedo explicar mejor gráficamente pero no tengo ganas de ponerme a pintar ahora mismo, jaja. El caso es que las pistas que tengan desniveles acusados, éstos tendrán varios escalones para seguir el contorno de dicha pendiente. Cuando acabe con las islas y las suba prueben GCXO y sabrán de qué les estoy hablando.

De paso haré un pequeño manual de uso de Apisonadora (y de los otros scripts, para limpiar el Post nº 1). Ah, recuerden que para usar Apisonadora hay que tener instalado el ImageMagick.

Ale ya he terminado la conversión de todos los rasters... a descansar toca (o sea que me voy al bar)

A ver que tal se lleva la nueva Apisonadora 8)

De paso, comparativa de Sierra Nevada, con el fotorrealista

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/sierranevada.jpg)
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/sierranevadahd.jpg)

Fenómeno !!  ;)

Bueno, pues ya actualicé el primer post (http://www.x-plane.es/modules/smf/index.php?topic=6626.0) con enlaces a todos los rasters así que... a ver quién se atreve a hacer la Península completa (yo me encargo de Canarias).

Por cierto, a ver si alguien se anima a rectificar GCXO, que la E4 cambió hace algún tiempo...  ;D

http://visor.grafcan.es/visorweb/default.php?svc=svcOrtofoto&lat=28.486713359505387&lng=-16.352382171153973&zoom=18&lang=es (http://visor.grafcan.es/visorweb/default.php?svc=svcOrtofoto&lat=28.486713359505387&lng=-16.352382171153973&zoom=18&lang=es)

Yo lo revisaré. Ni sabía que la habían cambiado.

Actualizado pintadera 3.7 beta (http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py).

Se ha incluido la opción (utilizando el modificador "oculto" -a) de que pintadera no subdivida los triángulos de las zonas de aeropuertos, contribuyendo así a disminuir el inevitable efecto "escalón" de las pistas con pendiente (utilizando rasters MDT25). En efecto, si una de las dos pasadas de pintadera a un DSF la hacemos con el modificador -a (Airport Skip Mode  ;D), el efecto escalón disminuirá considerablemente; prácticamente no se notará.

Pero ¡CUIDADO! pues esta medicina tiene unos efectos adversos muy notables en algunos casos!! Al aplicarlo, en las zonas que bordean el aeropuerto podrán aparecer pequeños triángulos sin textura (azules o transparentes). Eso se debe a que se rompe una regla primordial de las mallas y es que un mismo vértice no debería tener dos alturas diferentes... y en este caso podría ocurrir.

Por eso he dejado el modificador -a "oculto" (no aparece en la ayuda del script). Digamos que... cada cual lo use bajo su propia responsabilidad...  ;)

Uooh Genial!!   ^-^

Ahora mis preguntas;

¿Los triángulos sin textura, quedarían tapados por los .pol fotorrealistas? y ¿Son sólo triángulos sin textura o son agujeros en el mesh? Esta última es más por curiosidad.

De todas formas empezaré a investigar también.

Thanks!!

Pues... no lo he probado...  ::)


Me temo que son agujeros en el mesh... De ahí a que éste sea un método "no oficial", por llamarlo de alguna manera.

Prueba, prueba, y comentas...

Ok probado.

Los .pol no tapan los agujeros. y en algunos casos se crean falsos suelos, supongo que por el hecho de que un vértice tenga dos alturas.

Habrá que ser selectivo, pues en LERS me ha quedado perfecto pero en LEIG (en la misma celda) quedan unos efectos un tanto "abstractos" en la malla, a parte que la pista es casi "impracticable" ya de origen, en el Global Scenery).
La diferencia entre estos dos está en el tipo de terreno que los rodea, llano vs montañoso respectivamente.

De todas maneras esto no nos exime de modificar los rasters en algunos aeropuertos, como el caso de LEDA, que las dos cabeceras estan hundidas unos 5mts, así esta en el Global Scenery, en el MDT25 e incluso en el Google Earth. Ben tenía toda la razón acerca de los rasters ;).

Disponible Canarias SHD 1.0.

Espero que lo puedan probar para corregir posibles errores. El enlace de descarga, en el FTP, es:

http://www.x-plane.es/xp_resources/indexlist/index.php?dir=&file=Canarias_SHD_%28X-Plane10%29_1.0.7z

(en http://www.x-plane.es/xp_resources/indexlist/ (http://www.x-plane.es/xp_resources/indexlist/))

Sobre las pistas:

Tal y como he comentado más atrás, aunque apisonadora suaviza bien las pistas, el problema es que los triángulos son muy pequeños, por lo que podrán quedar escalones más o menos notables en ellas. Mi veredicto (de este a oeste):

GCRR (Lanzarote): Escalones en un sentido en el 66% de la pista, no muy molestos
GCFV (Fuerteventura): Escalones en un sentido en el 66% de la pista, no muy molestos
GCEJ (Fuerteventura): Perfecto
GCFJ (Fuerteventura): Un barranco en mitad de la pista, ¡insalvable!
GCLB (Gran Canaria): Un escalón brusco en mitad de la pista.
GCLP (Gran Canaria): Escalones en el 50% de las pistas; no muy molestos.
GCXO (Tenerife): Escalones a lo largo de toda la pista siguiendo su superficie ondulada. Algo molestos
GCTS (Tenerife): Escalones en un 33% de la pista, poco molestos
GCGM (La Gomera): Perfecto, la pista es llana
GCER (La Gomera): Perfecto
GCLA (La Palma): Escalones poco molestos en parte de la pista. Una de las entradas a plataforma (la más al norte) tiene un bache enorme ¡cuidado con las ruedas!
GCLX (La Palma): Perfecto
GCHI (EL Hierro): Escalones poco molestos en parte de la pista. La cabecera 16 tiene un bache en la zona de giro


NOTA: GCEJ, GCFJ, GCLB, GCER y GCLX se pueden descargar desde http://www.x-plane.es/modules/smf/index.php?topic=5330.0 (http://www.x-plane.es/modules/smf/index.php?topic=5330.0)

Genial!!

Con tu permiso, he empezado a pasar las tijeras por las costas del fotorrealístico  ;)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalmahd1.jpg)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalmahd2-1.jpg)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/lapalmahd3.jpg)

Buen tijeretazo!!

Yo acabo de convertir los dos scripts en versiones oficiales :P y subirlos a mi web, a parte de añadir una reseña de descarga también en el ORG.

A ver si la gente va probando el escenario de Canarias SHD a ver qué fallos se podrían corregir.

Ok empiezo yo con los fallos  :D

- Bajo rendimiento

Están previstas un par de actualizaciones de XP que deberían solucionarlo aunque sólo sea de forma parcial:
-Ejecutable de 64 bits - solucionaría tiempos de carga y problemas de memoria sobretodo con el fotorrealístico como .pol encima, con lo que se permitiría un nivel de detalle mas alto en las opciones de render.
-Hardware Tessellation - Dinamizaría la creación de la malla, lo que llevaría a eliminar triángulos inútiles, como los triángulos consecutivos con cada vértice a la misma altura (véase grandes explanadas y aeropuertos)

-Relieves en que se muestra la textura de la parte no visible desde el punto de vista (más acusado con el fotorrealista)

Ni idea pero a mí me recuerda mucho a un antiquísimo bug de OpenGL (¿a alguien le suena el término "wallhack"?)
-La solución podría estar en una futura actualización de OpenGL (drivers de gráfica) o que el mismo Ben lo arregle dentro de XP.

Para quien se atreva "HDizar" la península; esperad una caída de rendimiento brutal, nada comparable al de Canarias SHD, sobretodo con los .pol. Puede llegar a ser imposible cargar fotorrealistico con texturas "Extreme" y con dos iteraciones de Pintadera, sobretodo en celdas de montaña, así que tendreis que elegir entre calidad de texturas o calidad de terreno (o buscar el equilibrio ;)).



En otro orden de cosas, estoy recortando el mar de las texturas del escenario fotorrealistico de Canarias que hay en el ftp, para usarlo como pol.
Llevo casi la mitad de las texturas y si todo va bien esa próxima semana lo tendré terminado.

Yo tengo "recortados" la zona de la costa catalana casi en su totalidad. Tengo que probar lo de la "pintadera" pero con una sola interacción o sea pasar de 1 triangulo a cuatro a ver cuando me decido a probarlo bajo windows

Yo tengo las islas de La Gomera, El Hierro y La Palma hechas, pero desde hace tiempo pues estaban procesadas con el Gmaps y a mayor resolución. Ahora estoy procesando Tenerife y GC a mayor resolución. Pondré los enlaces de descarga en mi web ;)

Ok pos a esperar entonces (no sabes lo que me quitas de encima :D)

Se lo están currando mucho chicos, muchas gracias.

Saludos...


Compañeros e intentado con varios programas como GIMP 2 y el Photoshop CS5 Extended y no he podido hacer transparente la zona recortada, pues me sigue saliendo el entorno recortado en blanco a pesar de que al guardar la textura aparezca recortada.

Una vez más necesito su ayuda.


Gracias.

En PS, cuando cargues la textura, asigna la capa como "Capa a partir de fondo". Si es correcto cuando elimines las partes de mar en vez de salir en blanco saldrá una trama de cuadros grises y blancos, eso significa que es transparente.

...y en Gimp, tienes que pinchar en la capa, botón derecho, seleccionar la opción "añadir canal alfa". Antes de recortar.

Por cierto, he probado a poner un DECAL a los POL de los escenarios fotorrealistas y quedan MUY BIEN (a mi fe). Voy a ver si modifico ter2pol para ponerle esa posibilidad  :)

Puede poner un ejemplo sobre el tema, caballero ?? Gracias Jose Ángel

Of course! :)

Por suerte había sacado una foto ayer, pues etsoy actualizando el sistema y no puedo abrir aún el XP10...

(http://s7.postimage.org/ushjvcsav/decal.jpg) (http://postimage.org/image/ushjvcsav/)

Se nota, sobretodo, cerca, en la esquina inferior derecha, p.e.

Actualizado ter2pol versión 1.1. (http://www.cestomano.com/mas/xplane/#ter2pol)

Se ha añadido la posibilidad de que los archivos POL tengan una definición DECAL para crear texturas más realísticas.  ;)

(http://s7.postimage.org/pku7pkbif/decal.jpg) (http://postimage.org/image/pku7pkbif/)

Para ello, ejecutar ter2pol con la opción -b.

SI ya has convertido escenarios y modificado las imágenes DDS (por ejemplo, recortándolas) y te interesa probar esta opción, no hay problema, pues ter2pol no afecta a las imágenes. Se vuelve a ejecutar de nuevo (con los DSF y TER originales) y ya está.  :)

Bueno Apreciados compañeros, esto es lo que hago.

python instalado, DStool descomprimo y coloco todo lo de esta carpeta en  la siguiente ruta sin ejecutar nada en absoluto solo lo copio en la siguiente ruta
Custom Scenery/ZZZ colombia HD, asi he llamado la carpeta de trabajo, dentro esta :

carpeta estan: Earth nav data, tools, 3 ejecutables uno llamado DDSTool , otro DSFTool y otro  obj converter, un archivo llamado obj view, otro archivo llamado XGrinder, otro archivo pintadera.py y otros archivos de tipo readme correspondientes a los anterioores ejecutables mas otro llamado README_FIRST.

Abro la carpeta Earth nav data y tomo las carpetas  +00-070/+00-080/+10-070/+10-080/+10-070 y -10-080, que creo corresponden a mi pais colombia.
luego tomo los archivos que estan alli click derecho y les coloco F2, escribo en ellos despues de un punto 7z, al hacerlo posteriormente, los selecciono y aplico click derecho sobre ellos y  en el menu subyacente que corresponde al 7z selecciono Extraer  aqui, se realiza un operacion y aparecen los mismos archivos pero noto que algunos con la extension 7z, sin embargo pasa  que al colocar el cursor sobre estos archivos aun aparecen como archivos DSF, aun así una vez realizado esto, ingreso al sistema DOS y aplico el comando  sugerido en el readme de la aplicacion pintadera y me aparece que ese tipo de comando "python" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutables.

y hasta ahi llego, no se que estara mal la verdad no soy experto en DOS ni mucho menos en otras actividades referentes, tengo activada la oipcion ver carpetas ocultas de win 7.
espero esto halla ilustrado en parte lo que estoy haciendo, aclaro que convertí algunos escenarios del FSX con FS2xplane al x-plane 10 que funcionan de maravilla, claro desactivando la opcion del simulador que sigue el contorno del terreno con las pistas, pero las ubicaciones y las pista son totalmente operables, el autogen es perfecto, y creo que la malla de terreno no la tocó para nada la subsecuente conversión, espero me pouedan orientar mis amigos y colegas, pues quisiera tener mis escenarios del Global Scenery en Custom Scenery de mi pais en una mejor resolución mil gracias de antemano

Por lo que comentas, el problema está en el Python que, o bien no está bien instalado o bien le falta añadir la ruta del mismo al path del sistema.

No recuerdo bien cómo se hacía en Windows pero creo que debes modificar la variable de entorno PATH, añadiéndole la ruta al python (raro que no lo haga él mismo en la instalación). Las variables de entorno (en WXP) se pueden ver en Panel de Control, Sistema y... no recuerdo qué ficha.

Que yo recuerde a mí no me lo hizo en W7. Como siempre, MS protegiendo a los usuarios de... ellos mismos :D

Orciva2000 aquí tienes los pasos para crear el PATH
http://www.x-plane.es/modules/smf/index.php?topic=6626.msg64085#msg64085 (http://www.x-plane.es/modules/smf/index.php?topic=6626.msg64085#msg64085)

No hace falta que tengas todo el Scenery Tools dentro de la carpeta, con el DSFTool.exe es suficiente, y te recomiendo procesar los archivos de uno en uno ya que si falla uno te puedes volver loco por saber cual és.

Por cierto, usa la versión 2.x.x de Python, con la 3 no tira.

Excelente canarias, he realizado un vuelo gran canarias  - tenerife excelente escenario felicitaciones,;
Bueno  he desinstalado el phyton 3.x.x y lo he cambiado por el python 2.7.x, he realizado lo del Path, y bingo...en DOS ya reconoce el python, una vez proceso los archivo DSF con el 7z, realizando los cambios en las extensiones, uno a uno,conforme a su consejo, entro en DOS, utilizo el comando python pintadera,py y me genera un error ( error 2 ) en el que no puede abrir el archivo pintadera.py, y bueno pues vi en un foro que cestomano  coloca : "Actualizado pintadera 3.7 beta"., pero al intentar descargarlo me aparece una advertencia: "el archivo que esta intentando descargar puede dañar su ordenador", asi es de que STOP. estas advertencias asustan algo lo admito, aun así no desconfió del archivo, pero prefiero esperar sus sabios consejos, pues veo que ya han realizado mucha investigación y han experimentado en esta área.
Pero mis amigos grr05 y cestomano, sigo intentando, la verdad no se si todo estro se debe al win 7.
pero no me rindo que opinan ustedes? ah...mil gracias por su ayuda ha sido muy efectiva.

Orciva, que yo sepa la versión de pintadera beta 3.7 ya no existe ¿en qué foro la has visto?

En este mismo hilo, en el primer post, tienes la última versión, la 1.0. También estará siempre accesible a través de mi web: www.cestomano.com/mas/xplane (http://www.cestomano.com/mas/xplane) (y en el ORG: http://forums.x-plane.org/index.php?app=downloads&showfile=16417 (http://forums.x-plane.org/index.php?app=downloads&showfile=16417)). Las tres páginas las mantendré actualizadas y centralizan la descarga hacia mi web por lo que siempre será la última versión.

Nos dices que te da un error, "error 2", ¿sólo eso? La única forma de poderte ayudar es que nos detalles todo. Copia y pega aquí todo el texto de la ventana DOS cuando te da el error o una captura de pantalla. Si no, es como si le dijeras a un médico que tienes tos por email... no creo que te pueda diagnosticar  ;D

¿3.7b? De donde has cogío eso? :D


Un consejo: no hace falta renombrar los dsf si tienes el 7zip bién instalado, el menú contextual te permite abrirlo sin renombrarlo. Abre los dsf desde la carpeta Global Scenery y descomprímelos en la carpeta temporal, así evitarás conflictos por culpa de los nombres de archivo.

No, es este http://www.x-plane.es/foro/index.php?topic=6626.0 (http://www.x-plane.es/foro/index.php?topic=6626.0) ;)
Si tienes más problemas coméntalos en ese hilo, ya que aquí se está desviando el tema original.

ok gracias, vamos a ver como realizo las capturas y las posteo aqui para que se den una idea de lo que estoy haciendo, ya que no he podido hacer funcionar ese scrip pintadera.

Al estar unois días fuera, tengo que revisar muuuchas cosillas, pero efectuare las pruebas pertinentes  ;)

Microsoft Windows [Versión 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Reservados todos los derechos.

C:\Users\user>python pintadera.py
python: can't open file 'pintadera.py': [Errno 2] No such file or directory

C:\Users\user>

esto es lo que aparece una ves ingreso el comando python pintadera.py en DOS,
no es error 2 si no (Errno 2 ), les había comentado que aparecía error 2 y no es así, disculpas, alguna idea?

perdón que lo postee en este lugar yo se que me sugirieron en otro hilo, para que no se pierda el tema original.

Ya que no quereis pasar vosotros el tema donde toca, lo paso yo, pero no costaba nada hacer caso a los consejos y seguir el tema en el post correcto.

saludos.

SI tienes "pintadera.py" justo dentro de "C:\Users\user" no debería darte error. Pero lo lógico es que lo tengas en tu carpeta de escenario, en cuyo caso deberías ejecutar pintadera en dicha carpeta, no en "C:\Users\user".

Es decir, si tu carpeta con el escenario a tratar estuviera en (por ejemplo):

C:\Users\user\X-Plane\Custom Scenery\ZZZ Prueba\

Entonces deberías poner "pintadera.py" y el DSFTool ahí dentro y ejecutar "pyhton pintadera.py" ahí dentro, es decir:

C:\Users\user\X-Plane\Custom Scenery\ZZZ Prueba\> python pintadera.py

Por si quieren probarlos, he "resubido" La Palma (http://i.minus.com/1337150057/m9yUb3MB-N3dHgb6APYNug/dzpTQg129LMuK.7z), La Gomera (http://i.minus.com/1337150057/wZuOg_yTdzNWuH13Q09wGw/dhZ3MwJCFhSRt.7z) y El Hierro (http://i.minus.com/1337150057/thwPX7aP-bpYab4gCvKqaQ/dPnd8a8887ZGP.7z) fotorrealísticos a zoom 17, en formato POL (independientes de la malla), con las texturas ajustadas en gamma para XP10, con DECALs para darle ese efecto más detallado en el escenario y "transparentadas" charcas, embalses y demás para que se pueda ver agua realista (del X-Plane) en las zonas en que el X-Plane10 tuviera definida agua.

Si puedo subo unas capturas esta tarde.

Todos ellos son con datos fotográficos de hace 3-4 años. Ahora estoy reprocesando Tenerife con datos fotográficos de 2011 y tengo al fuego un script para crear escenarios fotográficos a partir de cualquier servicio WMS (como el PNOA, p.e.). Muy útil para fondos de aeropuertos, por ejemplo.

Acabo de subir la primera BETA del script/aplicación ter2xp10:

http://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py (http://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py)

Por si andan perdidos, les refresco la memoria  ;)

Cuando hice ter2pol surgió también la idea de hacer una aplicación que adapte escenarios hechos con el G2XPL no solo a POL (independientes de la malla) sino convertidos a la malla del XP10 directamente. Pues bien, este es ter2xp10.

Ventajas frente a ter2pol: Los escenarios son más eficientes; esto es, utilizan menos RAM y sube el rendimiento en fps.
Desventajas: Las líneas de costa son las del escenario original del G2XPL (malas comparadas con el XP10).

Entonces??? Creo que vendrá muy bien para escenarios sin mar (interior de la península) o en aquellos en que, habiendo mar, no nos importe mucho perder la calidad del XP10 en las líneas de costa. Lo bueno es que se le puede pasar pintadera y meterle los rasters que hizo Grrr05 para conseguir el mismo nivel de detalle pero más eficientemente. Se mantiene autogen, vegetación, carreteras...

Les dejo unas imágenes y datos comparativos:

GCXO con escenarios POL:
(http://s17.postimage.org/4iephlcjv/ter1.jpg) (http://postimage.org/image/4iephlcjv/)

GCXO con escenarios creados con ter2xp10:
(http://s17.postimage.org/ozznt8onf/pol1.jpg) (http://postimage.org/image/ozznt8onf/)

Puerto de Santa Cruz con escenarios POL (sin recortar aún):
(http://s17.postimage.org/g68rc51or/ter2.jpg) (http://postimage.org/image/g68rc51or/)

Puerto de Santa Cruz con escenarios creados con ter2xp10:
(http://s17.postimage.org/etr2a9497/pol2.jpg) (http://postimage.org/image/etr2a9497/)

Con las primeras pruebas que hice, pase de unos 20fps a 26-27fps con el escenario creado con ter2xp10. Y en consumo de RAM, de 795Mb a 758Mb (no mucha diferencia). Todo en EXTREME HIGH resolution, pero en una ventana (aún no he probado con el XP10 a tamaño total). Juzguen por ustedes mismos...

Ter2xp10 aún está en fase beta. El modo de uso es muy muy similar al ter2pol con la excepción de que por cada archivo "pepito.dsf" (del escenario g2xpl original) debe existir un archivo "pepito_xp10.dsf", el cual debe ser el DSF correspondiente del Global Scenery del XP10 ya descomprimido (y renombrado, añadiéndole ese "_xp10"). Sí, parece un poco rollo, pero ya digo que es una beta; para la versión 1.0 espero que esto no haga falta.

En mi ejemplo de Tenerife, tenía dentro de la carpeta +20-020:
+28-017.dsf   --->   (el archivo del escenario creado con el g2xpl)
+28-017_xp10.dsf   --->   (el archivo copiado desde el Global Scenery del XP10, ya descomprimido)

Esta noche lo pruebo  ;D

Es que no dais decanso al personal para efectuar pruebas, QUIERO VOLAAAAAARRRRRR   :D :D

Solo faltaria poder ajustar la linea de costa, que con el escenario xp10 por defecto + los POL del fotorreal no ajusta bien, y tampoco con los espigones de los muelles, todavía no se que decisión voy a tomar  :-u-

¡Tongooo! Esto copia la malla del G2XPL enterita!! :D (pero con posibilidad de usar rasters, que es lo importante)

También he visto que las orillas de los ríos han desaparecido, el agua "corta" a saco con la tierra.

Espero que mi comentario sea constructivo (es lo que tiene usar betas jeje)

Y gracias!! ;)

Sacto!  ;D ter2xp10 no tiene una gran ciencia. Básicamente:

- Copia la malla del g2xpl pero cambiando el valor de altura (cuando no es agua) a -32768
- Y le añade tod el autogen, objetos, carreteras, orillas del mar, etc y el raster que tenía la malla del xp10

Resultado: imágenes fotográficas (dle G2xpl) pero con todos los avances de la malla del xp10. Es decir, si parece poca definición se le pasa pintadera y ya está. Y en el caso de España, se le pueden añadir los rasters a 3601.

Por eso, salvo el detalle de las orillas del mar y (se me olvidó ayer decirlo) los ríos, charcas, etc., el resultado es similar a las mallas del xp10 pero con fotográficos.

La decisión, desde mi punto de vista es: o (1) alto rendimiento a costa de perder ríos, lagos, etc. y orillas del mar -ter2xp10- o (2) menor rendimiento (y curro de recortar imágenes) pero con orillas mejor conseguidas y lagos, charcas, ríos, etc. (que también hay que recortar) -ter2pol-. En fin, no se puede tener todo en esta vida... (piensa, Jordi, jaja)

Yo, para Canarias, lo tengo claro: ter2pol ;-)

PD: Estoy con lo de automatizar la descompresión de mallas del XP10. Será un añadido, así que si ter2xp10 beta 1 (actual) no da errores, ya se puede usar. Por cierto, al igual que su hermano gemelo, la opción -b añade DECALs.

Ok pos ahora mismo me pongo a ello.

Sobre automatizar la descompresión, el 7zip de güindous (y supongo que ídem para las otras plataformas) tiene el ejecutable desde línea de comandos, a no ser que te metas con la ingeniería inversa, que visto lo visto... :D.

... ay que tiempos aquellos cuando ívamos con el PKUNZIP :D

Le próxima semana me compro un periquito y le enseño a coger una carta, pongo cartas con todas las opciones y ver cual escoge el periquito  :D :D :D :D :D

"Non das trabajo carallo" que diría un gallego  ;) o:k   :-w-

jajajaja, podría ser una buena opción.

Acabo de actualizar a la beta 2 de ter2xp10 (http://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py).

Ya no es necesario(*) disponer del archivo DSF del XP10, el mismo solito lo saca del Global Scenery y lo descomprime. Eso sí, es necesario tener instalado el 7z y que el mismo esté en el PATH del sistema. Si no está en el path, se puede pasar la ruta de acceso a él por parámetros.

(*) No es necesario pero si se pone, ter2xp10 no buscará dicho archivo en el Global Scenery sino que utilizará el que encuentre. Esto puede ser útil para copiar mallas del XP10 con otros rasters y... no sé qué más...  :P

Por cierto, detectado un error: si se pasa pintadera a un escenario creado con ter2xp10 ocurren cosas extrañas en el mar. Sé de dónde viene el problema (extraña definición del G2XPL de los patches de mar, con 6 parámetros)... ya veré si lo corrijo en pintadera o en ter2xp10 (seguramente en el segundo)...

Dos cosas:

1º - Al pasar el Pintadera ha desaparecido buena parte del agua.

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/ter2xp10_2.jpg)


2º - Estas mallas no me gustan, se han cargado el Pedraforca  :'(

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/ter2xp10_1.jpg)

Esta es con la malla de XP10 con Pintadera 2x

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/pedraforca.jpg)


Por otra parte, al ser celdas de interior, el aumento de rendimiento ha sido brutal, he pasado de los 20fps a los 60fps (limitado), los tiempos de carga se reducen considerablemente y el dsf ha pasado de ocupar 96mb a 75mb.
Una tercera iteración de Pintadera sigue siendo inviable desde mi punto de vista.

Jordi cuando termines con el perico pásamelo, que también voy a tener que ser selectivo :D

Eso si, los DECALs le dan un buen toque de realismo, ahora queda ver si se puede eliminar este maldito tinte verde que el ICC nos puso en toda Catalunya.

Sí, es lo que había puesto en el post anterior.

El caso es que acabo de corregirlo pero......... sigue ocurriendo!!  :'(

Tendré que investigarlo, pero hoy ya mi cabeza no da para más.

Supongo que es una chorrada... ya miraré a ver, jej!

LO del tinte lo estuve mirando hace tiempo pero mis conocimientos informáticos, de fotochop o gimp son limitados, es poder crear un batch para que los corrija todos, aunque los que son fronterizos con Aragón, Valencia y Francia deberian hacerse a mano

Si te refieres a cambiar el tono, es cierto. Las ortofotos no están corregidas del todo y habría que hacerlo... si uno quiere máxima calidad. Pero tampoco se nota mucho si no se hace :P

Si te refieres a cambiar el gamma es muy fácil: mogrify (de Imagemagick) para convertirlos todos a png y XGrinder/DDSTool para volverlos a convertir a DDS (los de transparencias DXT5 y los q no DXT1).

Si te refieres a tinte del pelo, yo escogería castaño cobrizo, es de los más vivos y relampagueantes...  :D

El problema no es este, si no nuestros políticos  >:(

Por lo que tengo entendido, el Institut Cartográfic de Catalunya dejó sus imágenes aéreas a Google con la condición de que tendrían un color verdoso, para que en Google Earth, Catalunya se vea de un color diferente al resto de España.

Estas mismas fotos se pueden ver desde el visor OrtoXpres del ICC, pero sin el tinte.

Patético, vamos...

Por qué será que no me extraña? buffff


Sobre ter2xp10-pintadera, nada, hice unos cambios pero sigo sin obtener resultados positivos:

(http://s18.postimage.org/4l7oewot1/Sbach300_2.jpg) (http://postimage.org/image/4l7oewot1/)

(http://s18.postimage.org/uw7a4v1xx/Sbach300_3.jpg) (http://postimage.org/image/uw7a4v1xx/)

Patchs de 6, de 5, de 7 parámetros........ alguien sabe la diferencia de un Patch de agua de 6 parámetros respecto a los demás??? No he encontrado nada en internet :(

Seguiré probando...

he probado a quitar las líneas de costa (las playas, digo) ya que estaban mal alineadas... pero no afecta. Tendré que revisar pintadera pues...

Una cosa un tanto extraña es el color del mar de estos DSF (los procesador con ter2xp10) frente a los originales. En la siguiente imagen se puede discernir claramente la línea que separa una celda de otra... fíjense en el color del mar.

(http://s18.postimage.org/vri69q7it/mar.jpg) (http://postimage.org/image/vri69q7it/)

El de la izquierda, más verdoso, corresponde a la celda convertida del g2xpl al formato xp10. El de la derecha, más azulado, es del propio xp10.

No lo entiendo, pues la celda del g2xpl la he convertido, con todos sus objetos py parámetros (menos patchs de terreno) al formato xp10...

(nota, en esta imagen no había pasado pintadera, si no no se vería el mar así)

Nada, desisto!  :'(

Viendo con el QGis la distribución de triángulos en el mar, antes y después de pintadera, existen cosas extrañas: no sólo hay triángulos, sino otros polígonos. No sé por qué el G2XPL los crea así, el caso es que se ven "bien" pero cuando éstos se subdividen, choff!

Tenerife convertido con ter2xp10. Antes de pintadera:
(http://s17.postimage.org/6lmf4d0az/TFmar1.jpg) (http://postimage.org/image/6lmf4d0az/)
(http://s17.postimage.org/7lcq02fgr/TFmar3.jpg) (http://postimage.org/image/7lcq02fgr/)

Tenerife convertido con ter2xp10. Después de pintadera:
(http://s17.postimage.org/7mmnthhaj/TFmar2.jpg) (http://postimage.org/image/7mmnthhaj/)
(http://s17.postimage.org/88bmplccr/TFmar4.jpg) (http://postimage.org/image/88bmplccr/)

Y digo "bien" entre comillas porque en los escenarios creados con g2xpl hay numerosos huecos (triángulos azules o invisibles) en las costas. A lo mejor no era tan malo que aparecieran algunos de esos triángulos cerca de los aeropuertos aplicando "pintadera -a"...  ::)

De momento, dejo el tema. Queda ter2xp10 usable para escenarios sin mar/ríos/lagos, a no ser que no se le quiera pasar pintadera (que sería una pena).

Una pregunta (un tanto estúpida, supongo)

¿Los BEGIN_PATCH 0 son parches de agua?

De ser así si se modifica el Pintadera para que no los procese, deberían desaparecer estas anomalias.
Aunque no se si también afectaría a los rios y costas.

He hecho también un montón de pruebas a mano, para intentar meterle los .ter a las mallas de xp10, sin el Pintadera, pero es que no doy con nada...

Menudo lio... c;ra

 :) Amigo mío, esa puede ser la solución! GRACIAS!

Efectivamente, los BEGIN_PATCH 0 son los patches de agua. En una de las primeras versiones de Pintadera me saltaba los patches de agua por la simple lógica de "pa' qué dividirlos si no les afecta el raster"? Pero empezaron a aparecer los famosos triángulos invisibles/azules en las costas, no sé si recuerdas. De manera que le puse que tb. dividiera esos patches (aunque a costa de bajar el rendimiento un poco). Dividir sólo los patches de agua pegados a la costa era una tarea imposible.

Pero claro, para este caso, qué más da que queden triángulos transparentes si de hecho, los escenarios g2xpl, ya los tienen???

Lo pruebo y digo algo   ;)

PD: El que se debería  c;ra soy yo, jaja

Hecho!

Y como era de esperar, funciona  :)
(al menos con mar, con ríos no he probado)

(http://s18.postimage.org/qv94idq8l/aguabien.jpg) (http://postimage.org/image/qv94idq8l/)

No he subido aún pintadera a mi web pero aquí se puede conseguir modificada:

http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py (http://dl.dropbox.com/u/1126231/X-Plane/pintadera.py)

Hay que usar el modificardor -w para que NO procese el agua.

(al igual que el modificador -a, está oculto, es decir, no sale en la ayuda de Pintadera)

PD: Por cierto, no sé qué toqué en X-Plane que ahora me sale ese mensajito en la pantalla, acerca de la velocidad, ¿alguien sabe lo que es? Nunca lo había visto...

Perfect, con los ríos también funciona ;)

Sobre las imágenes que subí del ter2xp10, he visto que la malla del g2xpl convertida mantiene muchísimos vértices con su altitud original.
Éstas corresponden a la celda +42+001 (si quieres probarlo tú mismo hay los aeropuertos LESU y LECD), y el caso es que el raster apenas actua, la malla es aparentemente la misma del g2xpl salvo por el efecto de suavizado que crea el Pintadera.

Son muy pocos los vértices a -32768 y practicamente es como si no hubiera raster, de aquí la baja definición de las montañas en comparación con las mallas del XP10 procesadas.

Creo que sé por qué ocurre, aunque ahora mismo no tengo solución en la cabeza.

Ter2xp10 rastrea los patches de agua en el escenario g2xpl para saber cual es el punto más alto. Luego, al convertir los escenarios, asigna -32768 sólo a aquellos patches cuya altura sea superior; el resto lo deja igual.

Eso lo hago así porque si no el agua de mar podría quedar a alturas insospechadas, ya que no se le puede asignar -32768 y, no es siempre 0 (sólo hay que ver los patches del xp10). Mi idea funcionaría bien con el mar pero no había caído en los ríos y lagos, que están a más altura (de hecho, pensaba que el g2xpl no los procesaba hasta que vi tu foto del río con huecos). Así que en esa celda, toda cota de altura inferior al mayor de los ríos o lagos, no les asigna el -32768.

¿Cómo arreglarlo? Se me ocurre ponerle que sólo contee la altura de mar que sea mayor de un cierto valor (5, 6, 7...)... A ver si esta tarde lo miro.

O eso o le asigno directamente -32768 a todos los patches que no sean agua... total, el problema de no hacerlo podrían ser los famosos triangulos azules/invisibles que ya existen... Tengo que hacer pruebas con celdas como la que nombras.

Entendido. Teniendo en cuenta que en esta misma celda hay lagos por encima de los 2400mts, normal que no procese casi nada  :-[

¿Has probado con dejar los parches de agua a -32768? El raster "sea_level" debe tener alguna función, además, en las celdas de interior también tiene alturas definidas, pero de una forma algo extraña, como si se hubiese tomado la altitud de todos los cuerpos de agua de la celda y se hubieran interpolado las zonas sin agua.

Sí, eso es lo que más me mosquea de los patches de agua, que no siguen el raster correspondiente. Me imagino que la unión de los dos no es correcta y les habrán aparecido ciertos triangulos transparentes en las pruebas (a los de Laminar) por lo que terminaron por estrenar el XP10 así... pero lo dejaron ya preparadito para cuando puedan hacer funcionar dichos rasters. De hecho, ya ves que contempla la barimetría.

Me imagino que en el futuro (ESPERO!) utilizarán capas independientes para el agua y otras para el terreno (incluyendo la barimetría) y se unirán ambas perfectamente (como en Outerra). Al menos, así debería ser, no este "arreglo para salir del paso" (que lleva así muchos años). Y es que no tiene sentido unir ambos terrenos.

Por eso, lo de los rasters está muy bien pero en líneas de costa no sirven de nada :( Y es lo que menos se puede arreglar (y por eso sacar a flote algunos roques es tan difícil). En fin, tiempo al tiempo...

Bueno, ya está ter2xp10 modificado para el tema de ríos y lagos.

Beta 2.2: http://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py (http://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py)

Le he puesto una constante (se puede modificar al comienzo del código) para que sustituya por -32768 valores mayores que 3 SIEMPRE, sea el nivel de agua máximo encontrado el que sea (si el nivel es 0, cualquier valor mayor que cero será convertido). Se puede poner dicha constante a 0 y todos los vértices de patches de terreno serán convertidos a -32768 salvo los de nivel del mar.

Resultado cerca de la Cerdanya (ter2xp10 -w y pintadera una vez, raster original):

Bien el río... salvo sus orillas, con zonas transparentes... (no me he fijado en el original a ver si difería mucho):
(http://s18.postimage.org/9r47z3pr9/Sbach300_2.jpg) (http://postimage.org/image/9r47z3pr9/)
(http://s18.postimage.org/eeaa0vd45/Sbach300_3.jpg) (http://postimage.org/image/eeaa0vd45/)

División entre celda "aprepará" y celda original siguiente:
(http://s18.postimage.org/d32isehid/Sbach300_4.jpg) (http://postimage.org/image/d32isehid/)

Un laguito que había justo entre ambas celdas:
(http://s18.postimage.org/kn078702t/Sbach300_5.jpg) (http://postimage.org/image/kn078702t/)

Por cierto, tengo que hacerle una modificación a ter2xp10 (sencilla) para que elimine las orillas de la malla del xp10, pues quedan horrorosas ahí sueltas... (se pueden ver las susodichas en la mitad derecha de esta última imagen).

hagan pruebas y me dicen  ;)

ter2xp10 beta 2.3 (http://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py). Corregido un error por el que no detectaba bien el DSFTool en Windows.

He iniciado las pruebas de PINTADERA en la zona de La Cerdanya y el río parece el Guadiana pero por la zona en que no se ve, son solo una pasada del pintadera no aprecio mucha diferencia, sigo con pruebas y cuento lo que observo

P.S. no se puede ejecutar el pintadera con los escenarios de la v9 ???, esos tiene la mayoría de los rios  :-X

Nop pero... quizá se pueda hacer una triquiñuela para convertir los del XP9 al XP10 usando ter2xp10 y luego pintadera... todo es probar ;)

Funciona salvo que los rios tienen el aspecto de las fotos de más arriba ;)

Primero ter2xp y luego pintadera, (y el raster!!)

Pues le he metido 2 pases con el Pintadera del fotografico, el DSF ha subido de 5.000 a 17.000 y a 55.000, así a pelo, ni ter2xp10 ni na de na y veo los rios "gonitos" mejora bastante el escenario y de FPS MUUUY buen.

Seguiré con mas pruebas, ahora con los rasters de grrr5 y otras chapuzas

Los rasters no van a hacer nada con el fotográfico de la v9, ya que sus mallas tienen las alturas definidas en el mismo dsf.
Como ya dije muchísimos posts atrás, para que un vértice obtenga la elevación desde el raster, ésta debe estar definida en -32768 metros. Es algo que unicamente está implementado en la v10.

Aquí está la gracia de pasarle el ter2xp10 antes, basicamente lo que hace es copiar la malla del fotográfico en un dsf nuevo, redefiniendo a -32768m la altitud de todos sus vértices, además de copiar el autogen de la v10.
De esta manera se pueden usar los rasters en el fotográfico de la v9. El inconveniente es que el agua queda separada de la tierra, a un nivel inferior. Eso es debido a que incluso en la v10, los vértices que unen tierra con agua deben tener una altitud definida fisicamente si o si, es decir, en números dentro del dsf. Esos vértices no deben tomar la altitud del raster, y como en el ter2xp10 si la toman, las masas de agua quedan separadas del terreno en su vertical.

Recuerda que después de todo eso, si vas a meterle los nuevos rasters, sigue cada uno de los pasos al principio del post, ya que hay que cambiar los parámetros de las medidas del raster dentro del dsf.

Si, hoy quiero pelearme con uno de tus rasters  ;) y ver que pasa con los rios, que para mi son casi imprescindibles  :D

Vale, gracias Cestomano y Grrr5 por vuestro trabajo, partiendo de los fotograficos de xp9 1º el ter2xp10.py y siguiendo las instrucciones instalando la malla SHD y procesando el pintadera.py 2 veces con el "-w" para el tema de los rios ( el mar todavía lo lo he probado) los resultados son EXCELENTES, dejo una muestras, lástima del color amarillento que generó ICC para google, algún dia sabré como poderlo modificar por lotes, que imagen pòr imagen es una  :-[ :(

El Pedraforca en primer término
(http://i178.photobucket.com/albums/w271/jorduran/ec135_5-1.jpg)

Cerca del pantano de La Baells, con Berga al fondo y Vilada en primer término por la derecha, a la izquierda "les canals de Sant Miquel" http://ca.wikiloc.com/wikiloc/view.do?id=847955 (http://ca.wikiloc.com/wikiloc/view.do?id=847955)
(http://i178.photobucket.com/albums/w271/jorduran/ec135_9.jpg)

La Serra del Cadi y el Pedraforca al fondo
(http://i178.photobucket.com/albums/w271/jorduran/ec135_8.jpg)

Preciosas!! Aunque ese río aparece con el agua separada... ya yaya, aún no está resuelto el tema ese con ter2xp10 y los mapeados g2xpl antiguos... tiempo al tiempo!!

Por cierto, he subido la versión (que he llamado) BETA 1.5 de pintadera (https://dl.dropbox.com/u/1126231/X-Plane/pintadera.py).

Esta versión incluye una importante mejora, que consiste en mejorar el modo "airport exclude" (modificador -a) de forma que se puedan "saltar" zonas de las celdas, para no ser procesadas, pero SIN generar triángulos azules/invisibles. Es decir, manteniendo la malla coherente.

¿Qué se consigue con ello? Muy fácil, no procesando los aeropuertos, evitar los baches en las pistas que tanto nos fastidian.

De momento, esta versión que he subido, aunque funcional, sólo permite excluir una zona rectangular por celda, introduciendo las coordenadas como parámetros (ver ayuda de pintadera: pintadera -h). Pero voy a intentar que se salte zonas poligonales varias, definidas estas mediante archivos KML o, incluso, introduciendo los códigos ICAO de los aeropuertos para que se los salte automáticamente.

Les mantendré informados. Mientras tanto, si quieren probar pintadera BETA 1.5 (indicándole áreas rectangulares de aeropuertos para que se las salte) sería genial!!  :)

Se me ocurrido (que bestia, pienso  todavía) una prueba para el tema de los aeropuertos, ver LESU con la opcion de "las pistas siguen el con............"  con la v10 un derrumbe que tapa buena parte de la pista y además la zona de giro al final de la pista es impracticable al igual que en la otra cabecera para acceder al parking mañana cuento el resultado del método "prueba-error"

Ja! Ese maldito LESU, que me tiene frito... Conseguí arreglarlo parcialmente con las mallas del XP10 unicamente tocando el raster, pero no me convence en absoluto pues el resultado es el mismo que desactivando el slopped runways pero conservando (en parte) la colina que hay tocando a la pista. Aún no he probado el raster modificado con las malla del fotorrealista del G2xpl. Creo que esta pista tiene algo de desnivel así que si llega a ser posible usar el Pintadera a partir de un polígono definido en un KML, lo ideal sería tratarlo de ese modo. En LESU hay que conservar tanto las pendientes que hay en ambas cabeceras como la colina que se levanta tocando a pista, si no pierde su gracia (y una posible castaña en caso de rachas fuertes de viento cruzado)

(http://www.enciclopedia-catalana.com/fototeca/fotog/A027243.jpg)

Acabo de probar el nuevo Pintadera y si le meto los parámetros -a y las coordenadas no encuentra el dsftool, lo que me obliga a tener tanto el dsf como el *_XP10.txt.
He probado con pintadera.py -a . . 1.521723 1.511550 42.230550 42.232517 y también definiendo las rutas tanto de dsftool.exe como del archivo dsf a procesar y nada  :-[. Si no le especifico ningún parámetro funciona bién, como las versiones anteriores.

Si lo utilizo con el *_XP10.txt (prescindiendo del dsftool) llega un punto que me aparece el error IndexError: list index out of range (línea 295) dejando el txt a medias.

La celda, como siempre es la +42+001 y las coordenadas son de LECD, que en el global scenery la pista está perfecta y con el pintadera le salen escalones como es de esperar  :D

¿Da igual el orden de las coordenadas siempre que sea lon-lon-lat-lat? es decir E-W-N-S o W-E-S-N por ejemplo?

Sí, da igual el orden, mientras sea primero las longitudes. De todas formas, eso lo voy a quitar en la versión final.

Una cosa: ten en cuenta que si metes coordenadas, debes especificar la ruta del DSFTool. Es decir, deberías ejecutarlo así:

pintadera.py -a . DSFTool.exe 1.521723 1.511550 42.230550 42.232517

En la versión que estoy trabajando ya no habrá que especificar el DIR_Scenery (nada de poner el punto). Lo que no sé es si poner la ruta al DSFTool al final, pero podría ser un coñazo para detectarla. mmm, lo pensaré...

Sobre el error, en cuanto acabe con las últimas modificaciones lo pruebo, qu ea mí me está dando un error con un triángulo invisible que me tiene frito  >:(

Vale no había caído en escribir sólo DSFtool.exe, le metía la ruta entera sin el exe  ::)

El problema que tengo ahora es que hasta el lunes no voy a poder hacer nada, me ha explotado la fuente de alimentación (literalmente) del PC de escritorio donde tengo todo el tema... me quedará por ver si la explosión no ha afectado nada más de dentro de la torre, (cruzo los dedos)  :D

Uy!! Espero que tuvieras costumbre de hacer copias de seguridad!!!

Suerte!

(no consigo acabar con el dichoso triángulo...)

He probado con diversos ajustes del "boundary" y el resultado con SHD (2 pasadas del pintadera con el raster de Grrr5) y no hay forma de tenerlo medio-decente tanto con " las pistas siguen ......" como sin marcar la opción.

Suerte con la explosión de la F.A. y que solo sea ésto, si precisas algo que esté en mis manos, ya sabes

Una imagen vale más que mil palabras...

(https://dl.dropbox.com/u/1126231/X-Plane/llueven_camiones.jpeg)

Eso es lo que pasa cuando una carretera atraviesa un triángulo "invisible".

Nada, llevo dos días a piñón con esto y no consigo dar con la solución.

Cómo? Al pasar pintadera dos veces con la misma zona de exclusión indicada, pueden surgir estos triángulos invisibles en la zona límite de la exclusión... pueden surgir o no.

Lo curioso es que no son invisibles, realmente. Tienen su textura, pero está por debajo. Es decir, se ven invisibles desde arriba pero si bajas con la cámara por debajo del supuesto límite de terreno, la textura de dicho triángulo aparece justo sobre tu cabeza, digo cámara. Mientras que el resto de triángulos (malla), son invisibles vistos desde debajo.

Es decir, la malla es visible desde un lado, pero no desde el otro (desde abajo). Estos triángulos están como invertidos: son visibles desde abajo pero no desde arriba.

¿Alquien sabe o cree saber algo relacionado con esto? ¿tendrá que ver con las normales de las texturas? ¿la forma en que se escriben los triángulos? (por ejemplo, siempre deberían escribirse en el orden de las agujas del reloj pero no al contrario (p.e.)? ¿cuál es el sentido de la vida?  :D (que contesten los Monthy Python)

EDITO: Un ejemplo de triángulo invisible. Visto desde arriba y desde abajo:

(https://dl.dropbox.com/u/1126231/X-Plane/tri_up.jpeg)

(https://dl.dropbox.com/u/1126231/X-Plane/tri_down.jpeg)

15:44h... el momento del  :-j-

Por fin !!! me iba a estallar la cabeza!!

Efectivamente, los triángulos sueltos en las mallas (primitivas nº 0) se definen ordenando sus vértices en el sentido de las agujas del reloj; si no, la textura sale por abajo.

Después de averiguar eso fehacientemente tuve que rastrear el código una y otra vez, sobretodo la función que dividía los triángulos en los límites de la zona de exclusión en dos... pero por mucho que probé no conseguí nada. Por mil maneras que lo probé salía lo mismo.

Hasta que me di cuenta de algo: el error del triángulo sólo lo daba en la segunda iteración de pintadera. Eso me dio una pista que me llevó a otra cosa que modifiqué y era el sentido en que se desmembraban triángulos de una tira de triángulos (primitiva nº 1) que se encontraba en el límite de una zona de exclusión. Y, efectivamente, los triángulos "desmembrados" pares se estaban enviando a la función de dividirlos invertidamente. Claro, esta situación se daba pocas veces, y en el caso de Las Islas, sólo en una segunda iteración de pintadera ya que en la primera sólo existen primitivas de tipo 0 (las de tipo 1 las crea pintadera, en este caso).

Bueno, no me enrollo más, sólo estaba desahogándome  :D

Ya sólo me queda leer los ficheros KML; espero no tener ninguna otra sorpresita.

Ya te comentaré otras cosillas que pasan o pasaban con los rasters de Grrr5 y 2 pasadas de pintadera y desactivando " la pista sigue........" en LESU

Con " las pistas siguen ........."  queda la pista "abollada" se aprecia en la cabecera y en la otra cabecera peor aun  :(
(http://i178.photobucket.com/albums/w271/jorduran/ec135_11.jpg)

Desmarcando " las pistas ........" aparece una llanura descomunal de muuuchos metros  >:(
(http://i178.photobucket.com/albums/w271/jorduran/ec135_10.jpg)

Bien por los triángulos "invertidos", a ver si mañana le cambio la FA al PC y puedo continuar con eso.

Sobre LESU tengo un raster modificado que lo deja perfecto, pero demasiado. La pista queda completamente llana, pero el problema de los 15 bits de Photoshop que se comenté con anterioridad no dejan mucho margen y hay que mirárselo bien. También quería aprovechar este raster para allanar LECD y posiblemente el helipuerto de Tírvia (es algo que tengo pendiente), aunque ya digo, puede que quede demasiado perfecto. Si el pintadera puede excluir polígonos definidos en un KML facilitará enormemente el trabajo, ya que la modificación del raster será mínima..

Sí, el efecto de desactivar "las pistas..." es muy drástico, pero no te preocupes por las abolladuras a partir de ahora ;)


Pues bien, aquí dejo Pintadera BETA 2.0 (https://dl.dropbox.com/u/1126231/X-Plane/pintadera.py).

Pongo BETA pues aún hay que hacerle pruebas; yo sólo he hecho unas pocas en Tenerife, y funciona bien tanto con ICAOs como con KMLs. Con dos pasadas (no he probado más).

Según decía unos post más atrás, ya no se introducen coordenadas ni existe el modo -a pues ha sido sustituido por el modo -z "Zone Exclusion Mode"  ;D

El modo de uso:

python pintadera.py [opciones] [ruta al DSFTool] [ICAOs/ficheros KML ...]

Pintadera se debe poner siempre dentro de la carpeta del escenario a tratar y la ruta al DSFTool sólo hay que especificarla si no está en la misma carpeta o se usa el nuevo modo de exclusión (-z), en cuya caso es obligatorio. Usando dicho modo, podemos poner ICAOs de aeropuertos que queramos que se excluyan del proceso de Pintadera (para evitar abolladuras) o archivos KML (generados con el Google Earth, por ejemplo, o algún software GIS) de zonas concretas.

Los archivos / ICAOs pueden estar en el orden que sea y un archivo KML puede tener más de un polígono. OJO! Archivos KML, no KMZ !!
Un ejemplo:

python pintadera.py -z DSFTool gcxo mar_zona_norte.xml mar_zona_sur.xml zona_gcts.xml

En este caso, pintadera se salta GCXO (¡ojo! un rectángulo que engloba más o menos el aeropuerto, puede que no sea perfecto) y tres zonas que tengo definidas en tres archivos KML; la primera es un polígono que alberga la zona del mar al norte de Tenerife, el segundo lo mismo pero del sur, y el tercer archivo es un polígono que he definido yo alrededor de GCTS porque no me gustaba mucho el rectángulo automático  ;)

Una cosa importante: el modo -z excluye zonas determinadas para evitar, por ejemplo, abolladuras en las pistas. Si al usar el raster más definido de 3601 existieran abolladuras de algún tipo ANTES de pasarle pintadera, entonces, al pasarle esta, éstas no se arreglarán, pero no se añadirán nuevas. La pista quedará igual. Habría que trabajar en ese caso, un poco con el raster...

Yo lo he probado, ya digo, con GCTS y GCXO y va de maravilla  ;)

mmm, se me había olvidado añadirle el modo complementario, es decir, "modo de inclusión de zonas" (Pintadera sólo procesará las zonas especificadas).

Lo haré en un rato esta tarde, si puedo. La modificación es muy sencilla.

joer, ahora que había aprendido a decir "penicula" ahora lo llaman "flin 3D"  :D :D

Veremos que consigo  :-c-

Ahora que había conseguido decir calendario, lo llaman almenaque.  :D

Pintadera 2.0 BETA 2 (https://dl.dropbox.com/u/1126231/X-Plane/pintadera.py).

En esta beta2 se pueden especificar, a parte de zonas de exlusión, "zonas de inclusión" (modificador -zz); es decir, que pintadera sólo procese las zonas especificadas (o unas u otras, naturalmente).

Además, he simplificado un poco la llamada al script para que no haga falta especificar el DSFTool (salvo que queramos).

El modo de uso:

python pintadera.py [opciones] [ICAOs/ficheros KML ...]

Pintadera se debe poner siempre dentro de la carpeta del escenario a tratar; la ruta al DSFTool sólo hay que especificarla si no está en la misma carpeta o se llama diferente. Para ello utilizar el modificador -t seguido del nombre/ruta al DSFTool. Pero ya digo, si lo ponemos en la misma carpeta nos ahorramos estos pasos (debería modificar el resto de scripts para que hagan lo mismo).

Modo de exclusión -z o de inclusión -zz:

Usando dichos modos, podemos poner ICAOs de aeropuertos y/o archivos kml que definan zonas (polígonos) que queramos que se excluyan (en el primer caso) o se incluyan (en el segundo; es decir, que sólo se procesen dichas zonas) del proceso de Pintadera.

Ejemplos de exclusión: en aeropuertos para evitar abolladuras, en zonas llanas o de mar para aumentar un poco el rendimiento (menos triángulos innecesarios).
Ejemplos de inclusión: en zonas muy definidas orográficamente que queramos el máximo detalle.

Los archivos / ICAOs pueden estar en el orden que sea y un archivo KML puede tener más de un polígono. OJO! Archivos KML, no KMZ !!

Ejemplo:

Primero ejecuto pintadera dos veces así:

python pintadera.py -z gcxo mar_zona_norte.xml mar_zona_sur.xml zona_gcts.xml

En este caso, pintadera se salta GCXO (¡ojo! un rectángulo que engloba más o menos las pistas del aeropuerto, definido de cabecera a cabecera) y tres zonas que tengo definidas en tres archivos KML; la primera es un polígono que alberga la zona del mar al norte de Tenerife, el segundo lo mismo pero del sur, y el tercer archivo es un polígono que he definido yo alrededor de GCTS porque no me gustaba mucho el rectángulo automático  ;)

A continuación ejecuto pintadera una vez más así:

python pintadera.py -zz barrancobadajoz.xml

Pues he definido un polígono a lo largo del abrupto barranco de Badajoz y quiero recogerlo al máximo detalle.

Una cosa importante: el modo -z excluye zonas determinadas para evitar, por ejemplo, abolladuras en las pistas. Si al usar el raster más definido de 3601 existieran abolladuras de algún tipo ANTES de pasarle pintadera, entonces, al pasarle esta, éstas no se arreglarán, pero no se añadirán nuevas. La pista quedará igual. Habría que trabajar en ese caso, un poco con el raster...

Por cierto, si no se han bajado Canarias SHD ¡no lo hagan!

Voy a reprocesarlo con pintadera 2.0 para mejorar los aeropuertos. Del mismo modo, si puedo, saco a flote ciertos roques que quedaron planos (Roques de Anaga, Roque de Garachico, ...)

Parece ser que la única baja a causa de la explosión ha sido la misma fuente así que ya puedo empezar a trastear con el nuevo Pintadera  8)

Ahora ya puedo decirlo:
¿Mande?
¿Te suena el dicho "en casa del herrero cuchara de palo"? :D :D

Si que tengo copias pero es sólo de lo que tengo terminado ya que lo voy pasando al equipo de simulación, pero nada más, son copias "parciales"  ::)... voy a comprarme otro disco de 2tb...

Ale pues, al lío otra vez.

Jordi, usa este raster para la +42+001
http://dl.dropbox.com/u/59143574/rasters/%2B42%2B001-RASTER-LESU.7z (http://dl.dropbox.com/u/59143574/rasters/%2B42%2B001-RASTER-LESU.7z)

LESU queda más o menos decente (con pequeños baches que hay que arreglar con Pintadera 2) pero el terreno es bastante parecido a la realidad, aunque solo lo he probado con la malla original del XP10.
Este raster es provisional así que no está incluido en los 7z que hay en el primer post.

Oido y bajando, mañana lo cocino  :D :D



Yo es que ya soy viejo y esas cosas ..................... 

lo de poder INCLUIR o EXCLUIR una zona puede ser fantástico pero he de averiguar lo de .xml

Eso es fácil, desde Google Earth, con la herramienta "añadir polígono" y guardando como KML (ojo que por defecto está en KMZ).

Los archivos KML en realidad son XML pero "(c) by google inc." así que también se supone que podría servir cualquier software GIS.

No estoy seguro si KML es 100% google (bajo xml) o no, pues muchos programas GIS lo usan, como tú dices, y otros servicios WMS. Será un estándar... creado por ellos?

Cambiando de tema, he conseguido sacar a flote el principal Roque de Anaga. La razón de por qué no estaba en el Canarias SHD es que los rasters no lo tenían (raro porque el roque pequeño sí). Al final, lo copié del raster original, aunque tuve que aumentar su altura de 50 metros a unos 170 que tiene realmente:

(https://dl.dropbox.com/u/1126231/X-Plane/RoqueAnaga1.jpeg)

(https://dl.dropbox.com/u/1126231/X-Plane/RoqueAnaga2.jpeg)

El que lo conozca, verá que realmente no parece una "cabeza de oso" en el simulador, pero da bastante el pego.

(http://3.bp.blogspot.com/-Ez4MOGsJlE0/TZNy72xxs-I/AAAAAAAAAO4/0Y8rs4lGaa0/s1600/1-tfn-roques-de-anaga.jpg)

El Roque norte y el de Garachico siguen llanos, a pesar de que me inventé el Roque de Garachico en el raster (no estaba ni en el original ni en el 3601). La razón es que no debe tener alturas definidas en -32768... habría que hacerlo a mano !!  ???

Eso no debe de ser problema para el "creador" y dueño de Tagoror  ;)

Jeje, en qué alta estima me tienes!   :-m-


Acabo de actualizar ter2xp10 (https://dl.dropbox.com/u/1126231/X-Plane/ter2xp10.py), versión beta 2.5, corrigiendo un error con el modo -b (si se usaba varias veces añadía varias líneas de DECALs a los TER, ahora no añade más de una) y adaptándolo al modo de uso de pintadera (sin especificar dir_scenery ni dsftool). También he añadido un modificador nuevo para unas pruebas que está haciendo Albert a ver si van bien ;)

Confiamos en tiiiiiii

 :D jeje, ni yo mismo lo hago

Bueno, ya está "a flote" el Roque norte de Anaga:

(https://dl.dropbox.com/u/1126231/X-Plane/RoquesAnaga.jpg)

Me queda el de Garachico para terminar con los Roques de Tenerife... pero algo me dice que no haré más, buffff

La razón por la que algunos roques en XP (éste norte de Anaga y el de Garachico) son planos es que tienen tan pocos triángulos que todos sus vértices están en contacto con el agua y claro, no pueden tener altura. Al pasarles pintadera, los vértices intermedios adquieren el valor medio, es decir, 0, y por eso "no crecen".

Para conseguirlo tengo que hacer un truquito: aplico pintadera por zonas (modo -zz) sólo en el roque deseado. Luego abro el archivo DSF convertido a texto y busco el patch correspondiente a dicho roque (un poco coñazo, mejor tenerlo localizado previamente) y, visualizando la malla mediante el QGIS miro qué vértices son los que deberían tener altura, los busco "a mano" en el archivo de texto y les asigno -32768. Luego vuelvo a convertir el TXT en DSF y ¡Voilà!

Después se le pasa Pintadera un par de veces más a la zona y les quitas el efecto piramidal.

Como dicen los yankis; In God We Trust :D

Buen trabajo

Corregidos algunos errores en Pintadera (https://dl.dropbox.com/u/1126231/X-Plane/pintadera.py) con los modos -z y -zz (gracias por el aviso, Grrr05). Ahora "debería" funcionar bien ;-)

Una fotica del Roque de Garachico, recién sacado a flote:

(https://dl.dropbox.com/u/1126231/X-Plane/RoqueGarachico.jpg)

Quiero aportar unas fotos de Anaga que tome hoy.

(http://i806.photobucket.com/albums/yy348/evaristo2008/IMG_0152.jpg)

(http://i806.photobucket.com/albums/yy348/evaristo2008/IMG_0153.jpg)
 
En cuanto pase por Garachico, hago alguna.

FUNCIONA!! Hasta ahora todo OK.


¿En serio que estos pedruscos no aparecen en los rasters del IGN? Bueno como cuando estaba bajando las hojas ya rellené la encuesta marcando la casilla "Se deberían actualizar más a menudo". Lástima que no hubiese ninguna para marcar "Urgente"  :D
Pero bueno, a callarse toca que por suerte nos los dejan gratis y con licencia para hacer lo que le entre en gana a uno, salvo para venderlos!

Y ahora la pregunta del millón, ¿GrafCan tiene sus propios datos de elevación?
Si me pasais las coordenadas puedo mirar si existen en el MDT05 y si están podría recomponer el raster con el resto del MDT25, aunque creo que son los mismos datos pero reducidos de tamaño.

Ey! Muy buenas!

Con la Archer II del aeroclub?  ;D


Bueno, he terminado (creo) con la malla de Tenerife. En cuanto tengas las mallas rehechas de las 7 islas las subo definitivas pero, de momento, y por si quieren probar, les dejo la de Tenerife:

https://dl.dropbox.com/u/1126231/X-Plane/ZZZ_Tenerife_SHD_2.0.7z (https://dl.dropbox.com/u/1126231/X-Plane/ZZZ_Tenerife_SHD_2.0.7z)

Tiene los 3 roques a flote y los aeropuertos con las pistas sin baches (alguno que otro en rodaje pero muy leve).


Pues se supone que los han obtenido ellos para IDEcanarias. Los datos eran gratuitos antes pero  por problemas de solvencia se han puesto a la venta. Por si quieres ojear:

http://tiendavirtual.grafcan.es/index.jsf;jsessionid=4E96FDFCA054865DFCE2C2EDF6F3AC45 (http://tiendavirtual.grafcan.es/index.jsf;jsessionid=4E96FDFCA054865DFCE2C2EDF6F3AC45)

De todas formas, sólo faltaban dos Roques y ya están puestos  ;)

Ale a bajar otra vez  :D

Lo de los rasters lo decía porqué como habias dicho que te lo habías "inventado"... el finde lo pruebo.

Si la archer, jajajaj
Gracias por tu curro.

Esa no es la DSD no?

P.D: Es usté un ilegá, volando por debajo de los 500 pies!!! Que lo se! que no mide tanto! que tengo como 50 fotos y videos haciendo lo mism...digooo que me han contado que no es tan alto!

Es un efecto visual... está por encima de los 500 pies.  :D

La DSD? Si la consiguieron sacar de las montañas de la Orotava y repararla... jajaja. Es su sustituta, la Piper PA¿28? Archer II... mira por dónde, la primera compra que le hice a Carenado.

La DSD está muerta, esta es otro del club. La verdad la ultima vez que mira la altitud eran entre 500 y 600 pies jajjajjaj
Estas son las pruebas jajajaj.

(http://i806.photobucket.com/albums/yy348/evaristo2008/IMG_0149.jpg)

Seguro que tenías mal calado el altímetro, jajaja

Lo supero!! 400 y pocos :D

(http://i1048.photobucket.com/albums/s370/xgrrr05/misc/IMG_0935.jpg)

Eso es dentro del espacio de LERS, no me olvidaré del "India Charlie Echo, SUBA AHORA MISMO" (eso mismo con voz de cabreao)

Buena foto, jajaja

Malditas restricciones de lo divertido...  :D :D ;)

Ese era el momento más o menos

(http://i1048.photobucket.com/albums/s370/xgrrr05/misc/IMG_0924.jpg)

Pero si es la cessna de cuadro blanco de Carenado!  ;D

Me imagino el controlador de turno, jaja

Casi, es una F172N (Reims), hay que modificar el paintkit de Carenado :D


No hombre no, que en LERS son muy simpáticos, el problema está al llegar a mi pueblo y pasar a LEBL, ahí la cosa ya cambia  >:(

He actualizado el raster +42+001 que hay al primer post, dejando LECD y LESU decentes.

Importante: Para "HDizar" esta celda con dos iteraciones, hay que excluir unicamente LECD (en ambas iteraciones), si se hace lo mismo con LESU no se formará correctamente el terreno y quedará un churro como el que aparece en el Global Scenery.

El comando es python pintadera.py -z LECD dos veces

En caso de no querer pasar el Pintadera en la celda entera, se puede usar un polígono definido con Google Earth en un kml para que únicamente se aumenten el número de triángulos en la colina de LESU, en este caso lo suyo sería crear un polígono que abarque toda la colina dando unos 200 metros de margen hacia el exterior para que el Pintadera sólo aumente la definición en dicha colina.

Entonces el comando sería python pintadera.py -zz archivo.kml (ojo, con las dos zetas!) dos veces igualmente, pero además es necesario incorporar el nuevo raster siguiendo las instrucciones del primer post (omitiendo los pasos de Pintadera), ya que el raster original no sirve.

Así es como quedan con la celda entera procesada y con "las pistas siguen.......":

LECD
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/LECDok.jpg)

LESU
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/mesh/LESUok.jpg)

Excelente, han quedado muy... "aterrizables".

A ver si termino yo con las Canarias

De hecho, LECD ha quedado intacto respecto a la malla orignal, he recortado todo su area en el raster del mdt25 y he pegado el trozo correspondiente del raster original, ampliado mediante el bicúbico suavizado de PS.

Ese casi-bache que se ve y la inclinación transversal aparecen igual en el Global Scenery. Habría que acabar de pulirlo un poco pero si me meto a ello ahora, no terminaré nunca jeje.

Eso es cierto! Ayer estuve con el aeropuerto de El Hierro y es completamente imposible dejarlo bien! Llegué a procesar las cabeceras con pintadera independientemente pero nada, al final las dejé lisas.. en este caso la malla del XP9 que preparé en su día está mejor en ese aspecto (sólo tiene un par de triángulos pero pude mover los vértices fácilmente... con el XP10 ni me atrevo).

Lo pruebo y comento  ;) pero mas tarde  :D

Actualizados los rasters +41+001 (LERS,LEIG) y +41+002 (LEBL,LEGE,LELL).

Han quedado casi impecables, menos LELL que se ha perdido el terraplen, pero bueno, de orígen tampoco viene así que que mas da ;)
En LERS ha quedado una ondulación mínima sólo en la pista, cosa del desnivel de 2 metros que tiene, pero es usable 100% (y que c**o, que esta pista está viejita!)
Y el badén de LEIG es más o menos como el que hay en el real.

Terminado, ¡por fin! Canarias Super HD 2.0 (https://dl.dropbox.com/u/1126231/X-Plane/Canarias_SHD_%28X-Plane10%29_2.0.7z).

Con todas las pistas de los aeropuertos arregladas, SIN BACHES(*), y varios Roques sacados a flote  :)

No he conseguido subirlo al FTP así que lo dejo de momento en el Dropbox.

Si ven algo raro o notan algún error ruego me lo comuniquen lo antes posible.

Al lado de mi casa había una cuestecita para el coche que no veo en el raster...taliban de las cuestas!!!

Asfalto o cemento?  ;D

Muchas gracias

Bien! a ver si esta noche puedo pasarme por allí.

Con el SHD 2.0 he visto estas marcas en el escenario de Hierro, ¿cuál puede ser la causa?.
(http://i1180.photobucket.com/albums/x412/LuisAngel50/X-Plane/c4_3-1.jpg)

(http://i1180.photobucket.com/albums/x412/LuisAngel50/X-Plane/c4_4.jpg)

Cestomano te lo dirá mejor que yo pero creo que es porqué el fotorrealístico de El Hierro está creado para la v9 y eso es lo que pasa al usarlo en la v10. Pasa practicamente con todos los escenarios convertidos con el Ter2pol al usarlos en la v10, ya que en la v9 no hay ningún problema, por desgracia, en éste último no se pueden usar las mallas SHD.

Es muy extraño porque tanto la v9 como la v10 utilizan la proyección Lat/Long con el datum WGS84, pero es como si el diámetro del geoide de la v10 fuera ligeramente mayor, o alguna otra historia con las coordenadas.
Los archivos .ter o .pol de un fotorrealístico emulan la georreferenciación de las texturas, y es extraño que los mismos archivos con exactamente las mismas coordenadas del centro de la textura provoquen estas separaciones en la v10.

Exactamente: el XP10 mete muchos errores con los POL que no pasaba con la versión 9.

Me ocurre con todos los escenarios fotorrealistas basados en POL (no los TER) y se nota en muchos casos, mucho (como en ese caso). Y no sé cómo arreglarlo!!! (no puedo)

En GCHI tenía todas las texturas bien "hechitas" en el XP9 y poco antes de terminarlo me llegó el XP10 y... Susto!! esas líneas !!! bufff  :'(

Por cierto, Luisangel, esos bordes de las montañas me parecen muy picudos. Seguro que estás utilizando Canarias SHD 2.0 ?? Si tienes GCHI instalado acuérdate de no poner (o eliminar si lo tienes puesto) la carpeta "ZZZ GCHI".  ;)

Gracias. OK eliminada ZZZ_CGHI ^-^

 ;) Ajá!

La verdad es que es un coñazo lo de los escenarios. Uno va metiendo carpetas y carpetas al Custom y analizar cuál interfiere con cuál es un coñazo problema.

Otro ejemplo: el Canarias fotorreal es incompatible con el Canarias SHD, como es de suponer. Pero se le puede olvidar a uno por ahí instalado...

Y otra cosa, en cuanto a mallas he detectado que en el XP10 no se sigue al pie de la letra el orden alfabético para asignar prioridades... a saber cómo !!

Actualizados Pintadera a las versión 2.0 y Ter2xp10 a la 1.0. Es decir, he quitado lo de "beta" (ver primer post de este hilo).

No han cambiado desde la última beta. Simplemente, añadí los "leeme.txt" y los actualicé en mi web  :)

EDITO:

Ya está Canarias SHD 2.0 en el FTP. Gracias, zxplane  :)


También está actualizado en el Post nº uno. Lo quito del dropbosss

El administrador, zxplane, ha subido un formidable artículo, acerca de las mallas HD, a la página de inicio de x-plane.es (http://www.x-plane.es).

No dejen de leerlo!! :-)

Gracias, zxplane

Tras unos dias de poder "re-crear" y probar diversas opciones de las fotográficos de la 9 para la 10, pongo una serie de datos que he tomado y que puede servir para que otros usuarios puedan evaluar sus "propias" necesidades.

Por defecto en LELL con el EC-135 y con la misma meteorología y rendering
Las cuadriculas empleadas han sido 41+1+2+3 y 41+1+2+3
otros escenarios que se cargaban:
APT BARCELONA
APT LELL
CATALUNYA
OPENSCENERYX
RUSCENERY
SPAIN CITYS MARZO 2012
XSPAINROADS MARZO 2012


                                                 tiempo de carga                            FPS
                                                                                         2D                  3D

escenario por defecto XP10                      2:25                     30                   27
con el fotografico de la v9 (ter)                 2:50                     24                   24
tras ejecutar TERXXP10                           3:30                     23                   23
con TER2XP10 + PINTADERA                    4:40                     23                   23
2ª PASADA DE PINTADERA                     NO ME CARGA  :D :D :D :D

he pasado a 1 pintadera los 41+0+2 y 41+0 y ya me carga

                                                             8:00                   22/23               22

Los tiempos de carga se hacen bastante pesados para dos iteraciones del pintadera en mi equipo aparte de que no carga, pero para alguna zona "especial" merece la pena.

el rendering lo tenía así, y que cada x-planero tome sus propias decisiones
(http://i178.photobucket.com/albums/w271/jorduran/rendering2.jpg)
     

Tranquilo que en la 10.10 se arregla  :-n-

Ahora en serio, hasta que no tengamos el exe de 64bits y el hardware tessellation, mal asunto para cargar un número "decente" de celdas  :-[

Sobre los fotográficos, nueva noticia de datos de BING  http://www.omicrono.com/2012/06/bing-maps-se-arma-con-165-tb-de-imagenes-nuevas-guerra-de-mapas/ (http://www.omicrono.com/2012/06/bing-maps-se-arma-con-165-tb-de-imagenes-nuevas-guerra-de-mapas/)

Acabo de echar un vistazo rápido y veo que está con una resolución más que aceptable, y parece ser que el color es bastante homogéneo, almenos en Catalunya.

Peroooo...

General Restrictions. We do have some restrictions on your use of the Services. In developing Company Applications, and in using the Services, you may not, nor may you permit your customers to:
[...]
(s) Save, download, print, distribute, transmit or manipulate the bird’s eye imagery, or offer others that ability, through your Company Application.
[...]

En resumen, estamos en las mismas que con google y no nos dejan hacer na :(

Pero al menos, con las fotos actuales se puede trabajar en OSM, antes era imposible, a ver si termino unas zonas y te las mando para pruebas, son La Cerdanya y Cadí (Saldes, Gosol, Tuixent, etc)

Que envidia!!! Y que buen trabajo
A ver si alguien me echa una mano a conseguir unos escenarios fotorealistas mas decentes para las Baleares
Miren esta captura de pantalla
http://www.hiboox.es/go/imagenes-100/bk-117-1,5f6d7648230f027807f6a86bdc268c7d.png.html (http://www.hiboox.es/go/imagenes-100/bk-117-1,5f6d7648230f027807f6a86bdc268c7d.png.html)

La verdad es que en ese post se ha perdido un poco el hilo original jeje.
Aquí lo que tienes es entre otros, un script para convertir un escenario basado en TER ya existente a un escenario overlay basado en POL.

Lo que tienes que hacer es crear de nuevo el escenario con nuevas ortofotos, ya que el fotorrealístico de la v9 no está muy fino en las Baleares.

Esto tendría que resultarte más útil, es del mismo creador, que no para de regalarnos herramientas :D
http://www.x-plane.es/foro/index.php?topic=6926.0 (http://www.x-plane.es/foro/index.php?topic=6926.0)

Con ésto puedes crear un escenario basado en POL con ortofotos extraidas de cualquier servidor WMS, si en Baleares no los teneis propios, te recomiendo el PNOA que cubre el pais entero a una resolución más que aceptable.
Los escenarios basados en POL pueden mermar el rendimiento considerablemente, pero tratándose de islas no tendría porqué haber problemas, ya que en su día se hizo con las Canarias y funciona perfectamente.

Muchas gracias grrr05, en ello estoy.
Ya os contare y pondre unas capturas

Estoy mirando el Canrias HD mesh y me he dado cuenta que tiene menos archivos que el de Alpilotx, me refiero a que el Canarias HD tiene de +27-016 hasta +29-014 y en cambio el de Alpilotx tiene mas archivos de +27-013 hasta +29-014.

A Canrias HD le faltaría +27-016 y +29-014
Bueno eso creo, si no está es que seguramente no hace falta.

Vuelve a descargarlo porqué están todos.

Ah vale lo bajare de nuevo

Vale, la +27-013 pertenece al Sáhara Occidental...

Seguramente Alpilotx trazó un rectángulo de 3x6 celdas y se salió del archipiélago.

Ah vale vale, ya decía yoo, gracias

Dichas celdas SÍ están en Canarias SHD. Vuévelo a descargar (y vigila que el ftp no corte la descarga). Son 11 DSF en total.

PD: Por cierto, me acabo de dar cuenta de que hay un archivo leeme "fantasma" de la v1.0 dentro de la carpeta del escenario, terminado con ~. La razón es que estos archivos son ocultos (backups) para Linux y ... no lo vi al empaquetar...

Si hay 11, es lo que dice grrr05, +27-013 hasta +29-014 es de Sahara. Me explique mal

grrrr05, ¿porque en tu proceso de convertir .asc a RAW no lo hiciste todo con el global mapper?

Estaba probando el proceso y veo que en el global mapper se pueden abrir varios .asc a la vez y te los une automaticamente. Esto elimina la necesidad del MicroDEM.

Luego veo que te deja exportar a GeoTIFF y tambien a RAW, por lo que no entiendo la razon de hacerlo con FWTools y posteriormente con photoshop.

Por ultimo me gustaria preguntarte cual es la razon por la que hay que invertir verticalmente el TIFF.

Estoy intentando entender la dinamica de todo esto. Espero que no sean muchas preguntas jeje.

Gracias

400 y pico € de programa, los pagará su m...

Por eso buscar la alternativa, como FWTools, Grass, MicroDem o lo que sea, pero ahora ya da igual.
Todo lo que queríamos hacer está hecho y los rasters de todo el país están en el primer post.


Había que exportarlo a GTiff para poder tratar las imágenes para eliminar NODATAs que se convertían en "ruido" y para juntar los rasters del IGN con los originales del STRM3 para crear los rasters de las celdas fronterizas, no hay datos gratuitos de la misma resolución ni de Portugal ni de Francia.

Finalmente prescindimos del PS y se trató todo íntegramente con ImageMagick, ya que el PS es inacapaz de trabajar con 16bits, se come uno y lo deja en 15, con lo que la resolución vertical (eje Z) de los rasters se reduce a la mitad.

Por que así está especificado en los DSF. Cosas de los desarrolladores, así lo decidieron... Los rasters originales también están invertidos.

Vale, entonces el objetivo era usar global mapper lo minimo posible con el fin de poder llegar a prescindir de el. Es que como vi que lo tenias que usar de todas formas no entendia porque no lo usabas para todo.

Se que ya estan todos los rasters en el primer post (gracias!) pero queria entender el funcionamiento de todo esto.

Bueno basicamente esto es el proceso de transformación de los rasters del IGN (.asc) a STRM3 (.raw) que es el único formato que puede leer el X-Plane10 por ahora. Ben nos insinuó que probablemente en un futuro se puedan usar directamente GTiff de 24 o 32 bits, pero no se, éste formato ocupa muchísimo más ya que la resolución vertical aumentará considerablemente (siempre que la fuente de ésos datos pueda llegar a esas resoluciones)
Pero cómo los datos del IGN tienen una resolución vertical de 1m, con 16 bits es suficiente.

Luego hay que tener en cuenta la malla, que a diferencia de los MSFS ésta no utiliza Tessellation, viene compilada de "fábrica" y para poder utilizar rasters de mayor resolución y que la malla pueda aprovecharlos hay que subdividir los triángulos. Aqui es donde entra en juego el script Pintadera de Cestomano.

Creo que desde la versión 10.10 se pueden utilizar otro tipo de rasters. Al menos, se puede especificar en el DSF si es de tipo entero 16 bits, 8 bits, 32, si es en coma flotante... pero claro, no hay mucha información escrita acerca de ello, así que se pueden hacer pruebas con otros formatos a ver si los pilla o no.

Sobre el Pintadera, el problema es que(*) a medida que subdivides triángulos, los fps bajan. La "teselación" evitaría ese problema y aumentaría el nº de triángulos tanto como fuera posible allí donde los necesites (donde estés más cercas). Sería un gran adelanto.

(*) Eso sin mencionar que la conversión de mallas complejas de TXT a DSF mediante el DSFTool puede petar, sobretodo en Linux...

Pintadera actualizado a 2.1 (http://www.cestomano.com/mas/xplane/#anadidos).

Se ha corregido un error (incomprensiblemente detectado ahora ???) con el orden de los vértices en los abanicos. En algunos casos, el resultado podía ser desastroso (triángulos invisibles).

Hoy intente convertir un fotoreal ter a pol con el ter2xp10.py pero no lo conseguia, al final detectaba error.

Por variar un poco...me pongo a hacer unos edificios próximos a LEMG. Dado que hay cierta pendiente en sus inmediaciones...los edificios (OBJ) se presentan sólo con una parte (esto, creo que depende de dónde haya situado el centro-objeto en Blender) sobre el terreno...el resto flota, se mantiene en suspensión sobre un punto.

(http://img534.imageshack.us/img534/8292/0rxz.png) (http://imageshack.us/photo/my-images/534/0rxz.png/)

¿cómo podría aplanar una determinada zona?...cómo le digo a Apisonadora que la zona X (¿tal vez a través de un kml?) necesito que sea plana!!!

He probado con los nuevos rasters de SimHeaven...por si las flies...y esa zona siempre me la deja en pendiente.

Cualquier ayuda será bienvenida... ;D

Modificar la malla del terreno es una tarea ardua y... apisonadora no resulta ser lo ideal que uno se imagina, pero puedes probar. Ya ni recuerdo como se hacía, pero creo que:

1º) Debes copiar la malla del terreno de tu Global Scenery a una carpeta nueva del Custom Scenery (no la de LEMG, otra de nombre similar y menor prioridad, como "ZZZ LEMG"). Y debes descomprimir dicho archivo DSF pues estará en 7z.
2º) Defines un polígono KML y lo cargas con apisonadora siguiendo las instrucciones que... no recuerdo donde están  :D
3º) Cruzas los dedos!

Mejor que eso que siempre es un coñazo y si tienes instalado un fotorrealista no te servira de nada, es modificar el objeto añadiéndole un par de plantas para abajo (como dos sótanos). Así, una parte del edificio se podrá ocultar pero otra, los sótanos se mostrarán en vez de quedar un espacio vacío.

Puedes probar con los atributos del objeto   ATTR_xxxx

http://www.x-plane.es/modules/smf/index.php?topic=6919.msg65384#msg65384 (http://www.x-plane.es/modules/smf/index.php?topic=6919.msg65384#msg65384)

Ojo que el ATTR_draped no sirve para esos casos, es para convertir un objeto en el equivalente a un "draped polygon", aunque el objeto tenga volúmen si definimos este atributo quedará completament aplastado en el suelo.

La mejor solución (siempre que no se quiera trastear con la malla) es la de Cestomano, alargar la parte inferior de los objetos. Pero si el desnivel no es muy pronunciado siempre se puede optar por el atributo TILTED para rotar el objeto en función de la inclinación del terreno (LECD es un claro ejemplo, con los hangares).

-Apisonadora, que yo vea, no permite una KML.

Pensé en crear una APT en esa misma zona, y entre meterle Pintadera+Apisonadora... ver cómo va el DSF creado...y "llevarmelo" al otro escenario. Si no...crearé un OBJ hard creando la zona que me interesa y poniéndole una textura... y arreando.

Me estoy planteando trastear con la malla...

Gracias por la ayuda!!!

Noooooooooo... no te vayas al lado oscuro !!!!  :D

Si puedes trastear con objetos, te será mucho más fácil. Lo de la malla es un mundo mu complejo; esperemos que los guys de x-plane lo faciliten más en el futuro  >:(

A que parecía que este hilo había muerto, eh? No, aún queda tela...  :D

Hoy me he puesto a trastear con Pintadera para ver si conseguía hacer una cosa: hasta ahora, Pintadera, al dividir triángulos asignaba a los vértices nuevos el valor -32768 (dicho vértice tendrá la altura que indique el raster) si alguno de los dos vértices de los que dependía tenía ese valor. En caso contrario (patches de agua y costas), el valor era una media de dichos dos vértices.

Este cálculo no tenía mayor problema salvo en el caso de pequeños roques o islotes donde todos los vértices de sus triángulos estaban en la línea de costa. En ese caso, el roque era plano y por más que le pasaras Pintadera.... seguiría siendo plano.

Ese problema me lo encontré en varios Roques de Canarias SHD y para poder darle altura tuve que recurrir al trabajo de chinos: asignarle valores -32768 a todos los vértices a mano. Precisamente ese es el motivo por el que me ha dado muuucha pereza trastear con el HD de AlpilotX para generar el nuevo Canarias SHD 3.0 (el resto de trabajo, es juego de niños).

Pues bien, se me ocurrió una modificación de Pintadera que hace ese trabajo automáticamente... y lo mejor ¡¡funciona!!  :-j- :-j-

(http://s3.postimg.org/fsyfym67z/roques_de_Anaga.jpg) (http://postimg.org/image/fsyfym67z/)
(aquí se puede observar el segundo roque de Anaga -derecha- con altura. Sin la modificación, hubiera seguido siendo plano)

Ahora solo me queda depurar un poco el código y subirlo (eso sí, ahora Pintadera tarda muuucho más). Y empezar a trastear de una vez con Canarias SHD 3.0.  ;D

Pues hace un par de dias estaba leyendo casi las 26 páginas, ya que estoy mas perdido que en medio del Atlántico y sin GPS y francamente, la empanada mental ahora es superior a la que tenía, debe de ser cosa de la edad, como mi X-Plane fucniona con una cierta decencia, impropia de algunos políticos, mejor no toco nada.  :D

jaja, no te preocupes, Jordi, yo tb. me lío... y explicándolo, más aún.

No preocuparse, dicha actualización me supone un gran paso para mí y el desarrollo de Canarias SHD 3.0 pero dudo que le importe mucho a los demás  :( pero bueno, lo dejo patente para quien se quiera sumergir en estas aguas.

Sobre Canarias SHD, este es el planteamiento paso a paso que tengo:

1º) Partir de los DSF HD 2.0 de AlpilotX de Canarias (tengo su beneplácito). E ir isla por isla.
2º) (para cada isla) Pasar Pintadera excluyendo las zonas de los aeropuertos.
3º) Pasar Pintadera una segunda vez solo a algunas zonas (analizarlo primero).
4º) Buscar el raster de Canarias SHD 2.0 y analizar si necesita algún ajuste fotochopiano.
5º) Introducir el nuevo raster ajustado.
6º) Comprobar que todo esté bien, sobretodo los aeropuertos. En caso contrario hacer los ajustes necesarios (mover vértices si fuese necesario, como en GCHI...  :-d-)

Bueno, este último paso quizá debería hacerlo antes de pasar pintadera, para evitar mover muchos vértices. Y quizá hacer el paso 4º y 5º antes que el 2º y 3º...

Cuidado con este, precisamente en el HDv2 de Canarias el dsftool me petaba en algunas celdas con la segunda pasada de Pintadera.

A ver ese Canarias SHD 3  ^-^

Sí, así es. Por eso lo de aplicar la segunda pasada solo por zonas, para que no crezca demasiado. El caso es que se supone que el HD de AlpilotX ya tiene más triángulos que el base de X-Plane 10, del cual partí para Canarias SHD 2.0. Por lo que una pasada (o pasada y media) debería coincidir más o menos con dos pasadas en Canarias SHD 2.0.

O eso espero...

Si voy terminando islas, las voy subiendo de manera temporal para ver si "alguien" se anima a hacer de beta tester, jeje

No se mi máquina lo soportará, pero me tienes para probarlo  ;)

Gracias  :)

No debería consumir más recursos que Canarias SHD 2.0  ::)

Pintadera (http://www.cestomano.com/mas/xplane/#pintadera) actualizado a la v. 2.3  :)

Más información acerca de los últimos cambios en el fichero leeme.txt. Aunque se me olvidó añadir que ahora se presenta un porcentaje durante la ejecución para hacernos una idea de cuánto queda por procesar de cada archivo DSF.

El nuevo Pintadera puede tardar 2 o 3 veces más al ejecutarse en una isla (o zona con varias masas de agua). Pero los resultados son mejores así que vale la pena no usar el modificador -f, el cual haría funcionar Pintadera como en versiones anteriores (más rápido).

Mentira!! lleva 6 horas y aún anda por el 50%, estoy trasteando con el fotorreal de SimHeaven para meterle los rasters del MDT25  ;D
Espero no estar perdiendo el tiempo (bueno, el de mi CPU), pero está añadiendo cantidad de vertices con -32768, teniendo en cuenta que las mallas de SimHeaven no tienen ni uno de estos.

 ???  ???  ???

6 horas ?? ?? ??

Pero espera! Pintadera no sirve para fotorreales del g2xpl, pues precisamente no utilizan raster... a nos ser que definas tú los vértices a -32768.

A ver: la celda tiene agua? Y has creado zonas de exclusión para que Pintadera no repase el agua? Si no es así, es lógico que tarde muchíiiisimo (debí haberlo mencionado en el readme) puesto que dividirá entonces todos los triángulos de agua y guardará en una lista en memoria todos eso vértices... y para cada triángulo de tierra cuyos vértices no sean -32768 (cosa que en un escenario normal solo ocurre en las orillas pero en los fotorreales de g2xpl ocurre en TODOS) Pintadera tendrá que comprobar todos y cada uno de ellos que no se encuentren en la lista mencionada anteriormente... y eso es tortuoso.

Por eso te tarda taaaaanto (y más que tardará).

El efecto secundario es precisamente lo que comentas: que los vértices nuevos serán de -32768 así que si existe raster... ya no tienes que hacerlo a mano!  ;)

Ya me cuentas cómo acabó.

La celda tiene poca agua, básicamente rios y pequeños lagos (+42+001, que mejor sitio para esas cosas que los Pirineos jeje) pero no le he metido ninguna exclusión.

Creía recordar que con versiones anteriores ya se excluía el agua automáticamente y que NO procesaba los triángulos que tenían alturas definidas en sus vértices, por eso lo he probado nuevamente con la 2.3 -aún no ha terminado...-
Mientras el Pintadera iba haciendo le he echado un vistazo al txt saliente y todos los PATCH de terreno tienen vértices nuevos con -32768, cosa que antes no pasaba  ;D

A ver que sale de los fotorreales y si se pueden mover fluidamente, lo que está claro es que aparece una malla "híbrida" cuyos triángulos subdivididos toman la elevación del raster, el cual va a ser del MDT25  8)

Ah, claro, Pirineos, je. ENtonces no he dicho nada  ;D


No, eso no pasaba. Siempre se procesan... solo se excluyen triángulos que estén en las zonas de exclusión. Bueno, luego estaba el modificador -w que creo que sí hacía lo que tú decías, pero los resultados eran imprevisibles y por eso lo mantenía oculto.

Sí, todos los vértices nuevos del terreno, salvo los que estén pegados al agua, tendrán altura -32768 (salvo si se ha usado el modo -f)


Pues sí, va a ser curioso. Una malla que a priori no tenía sentido pasarle Pintadera porque no usaba raster ahora sí lo tiene y utilizará el nuevo raster en 9 de cada 12 vértices (tras un Pintadera).

Yo noto bastante la caída de frames de los fotorreales de zoom 17 frente a los de 16 (ambos de Simheaven) así que esa malla cuatriplicada en triángulos puede ser una bomba para mi CPU. Ya me contarás cuando la pruebes...

...y haya terminado Pintadera, claro ¿estuvo toda la noche?

Eso me hace replantear la ejecución del nuevo código y utilizar listas ordenadas para que la localización de vértices sea más rápida. No sé si se aceleraría mucho la ejecución.

Detectado error en Pintadera, acerca de las zonas de inclusión y puede que de exclusión  :(

De momento, no localizo dónde está, pero sé que está por los resultados inesperados... Buff  :'(

EDITO: Bug localizado. Bueno, en realidad no es un bug, es un "mal hacer". Resulta que las zonas que caen fuera de las zonas de inclusión no es que no se procesen, sino que se procesan sin dividirse... y en caso de tiras de triángulos o abanicos de triángulos se convierten a triángulos sueltos, lo que acarrea que, sin aumentar el nº de vértices, aumente la complejidad de la malla y el uso de memoria.

Nada, tengo que arreglaro... ahora, a buscar la manera.  l;tura

Bueno, después de 12 horas de ejecución, la malla ha mejorado sensiblemente... claro que ha sido sólo una ejecución (con 2, impensable creo...), eso si, a pesar de haber procesado la malla ya modificada para LESU, desapearece el bache y el contorno queda mas perfilado, pero por contra en LECD parece como si un enjambre de stukas hubiera azotado el aeródromo, las alturas físicas no coinciden con las del raster  :'(

De todas maneras con las mallas de Simheaven HDv2 no merece mucho la pena ya que la subdivisión entre cuatro apenas se aprecia, quizas con un par de iteraciones se note mucho mas, pero probablemente afecte muy seriamente al rendimiento (por no decir las 48 horas requieridas por celda  :D)

Eso quiero verlo!! Sube fotos!!  :D

Ahi va

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/lecd_zps35b22585.jpg)

Mi madre, o los vértices de raster y simheaven no coinciden mucho (el híbrido) o... tendrás que crear una zona de exclusión para el aeropuerto para que no se vea afectado y...

...esperar otras 12 horas  ;D

No no, no voy a hacerlo otra vez  :D

Compara tu mismo, aunque a simple vista no se aprecia nada, lo suyo es descargar las dos imágenes y pasarlas en plan slide-show. Ni caso de los FPS, es un poco contradictorio ya que la captura con la malla de Pintadera va a 45 fps y la malla sin tratar la movía a 17... cosas del X-Reloaded supongo.
La segunda imagen es la de la malla con Pintadera, hay unas cuantas sombras mas y un pelín mas de definición en el horizonte, pero es algo que prácticamente pasa desapercibido, ya recuerdo que el punto fuerte de Pintadera estaba en la segunda ejecución y con estas mallas lo veo inviable   :D

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/Cessna_172SP_12_zps299ad10f.jpg)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/Cessna_172SP_11_zpsbfda4fa9.jpg)

Que poco ojo tengo, pero no es la misma imagen jajajaja

Uff... se nota en algunas zonas "un poco". Pero vamos, no vale la pena pienso yo.

A saber cómo está de definida esa malla de Simheaven... más triángulos que la original seguro pero ¿cuántos?

A ver si esta tarde tengo tiempo de arreglar Pintadera, aunque el error (desoptimización) solo afecta cuando se utilizan zonas de inclusión y un poco las de exclusión.

En el Pedraforca se nota un detalle mas real  ;)

Es mi punto de referencia a la hora de trastear con las mallas, por eso siempre empiezo en +42+001  ;)

Pintadera (http://www.cestomano.com/mas/xplane/#pintadera) actualizado a la v. 2.4 :)

Corregido error Optimizada la ejecución cuando se utilizan zonas de exclusión y, sobretodo, de inclusión.

Anteriormente, las zonas excluidas (ya sea porque estaban dentro de zonas de exclusión o fuera de zonas de inclusión) se convertían a primitivas de tipo 0 siempre, ya fueran de tipo 0, tipo 1 o tipo 2, con el consiguiente aumento en el consumo de memoria y ralentización.

Ahora, con Pintadera 2.4, las zonas excluidas limpiamente se guardan tal y como estaban (primitivas de tipo 0 como 0, tipo 1 como 1 y tipo 2 como 2), por lo que el escenario consumiría la misma memoria en estas zonas. Solo en las zonas limítrofes (en los bordes de las zonas de exclusión/inclusión) las primitivas se convertirán siempre a tipo 0 (si no lo hago así, buffffffffffffff....).



GLOSARIO:

Primitivas: las estructuras tridimensionales más sencillas que conforman la malla del terreno.

Primitivas de tipo 0: triángulos (definidos como tres vértices con sus 3 coordenadas, sus normales, etc. y tipo de superficie)

Primitivas de tipo 1: tira de triángulos. Una sucesión de triángulos, donde los vértices 2 y 3 de un triángulo dado son los vértices 1 y 2 del siguiente. De esta manera, se ahorra memoria pues para una tira de X triángulos solo se almacenarían (X + 2) vértices. Si hubiéramos utilizado primitivas de tipo 0 (triángulos solitarios) hubiéramos necesitado X*3 vértices en memoria.

Primitivas de tipo 2: abanico de triángulos. Parecida a la tira de triángulos pero donde el vértice 1 de todos los triángulos es el mismo y el nº 3 sería el nº 2 del triángulo siguiente. Para un abanico de X triángulos solo se almacenarían (X + 2) vértices, por lo que ocuparía la misma memoria que una primitiva de tipo 1 (pero tiene otra forma, claro).  ;)

Por fin he conseguido reunir algo de tiempo y ponerme a trabajar en Canarias SHD 3.0 que lo tenía aparcado desde hace.......  ::)

Acabo de subir una versión beta de Tenerife (solamente) para ver si alguien (mejor, "álguienes") puede probarla y decirme su parecer, qué ve mal, bien, etc.

Les recuerdo: Canarias SHD 3.0 estará basado en la versión HD2 de AlpilotX de Canarias, pero mejorada con los rasters de Canarias SHD 2.0 (mejorados éstos a su vez) y pintadera.

Les dejo instrucciones de instalación:

1. Entrar en Custom Scenery\Canarias SHD 2.0\Earth nav data\+20-020 y renombrar el archivo 28-017.dsf a 28-017.SHD2 (o algo así; vamos, para no perderlo).
2. Descargar el nuevo archivo DSF desde https://dl.dropboxusercontent.com/u/1126231/X-Plane/%2B28-017.dsf y colocarlo en la carpeta anterior.
3. Cargar X-Plane y probar Tenerife: Los Rodeos (GCXO), Tenerife Sur (GCTS), El Vallito (ZZEV), Izaña Militar (GCIM), etc. rodaduras, pistas, plataformas...

En esta versión he allanado El Vallito e Izaña Militar (ambos incluidos en Tenerife VFR) porque los pobres estaban de inclinados...

Fallos conocidos: hay un bache en la calle de GCTS que no he conseguido arreglar aún.

A ver si detectan más errores.  ;)

GRACIAS!

...nadie se ofrece?

Bueno, me voy a ir unos días de vacaciones así que supongo que a la vuelta haré yo mismo de betatester...  ::)

Para cuando degreses te hare un informe si mi pc lo soporta  :D

Gracie  ;)

Si soporta Canarias SHD 2.0 soportará esta beta.

Eso sí, recomendable instalado Tenerife VFR para tener las "pistas extra"

Me han dado autorización para despegar en "TUS" aeropuertos para mañana. ya te diré a tu vuelta

Permiso de la comandanta?

jeje, gracias. Esperaré informe ;)

Pues si, el primer dia de aterrizar tras 11 dias fuera de tu aeropuerto, requiere de trabajos especiales y de mantenimiento de correo electrónico

Un poco mas tarde .......................... primer vuelo GCXO-GCXO por la 12 y siguiendo por la autovía hasta alcanzar la casa de la novia de Evaristo (la puso él) virada a la derecha y subiendo por la costa hasta el Roque de Anaga, siguiendo por la costa hasta Santa Cruz y llegando a Los Rodeos, sin problemas el escenario.

Mañana otra ruta y te cuento. Como puedes observar, la peña pasa de betatester, menuda colaboración  :'( :'( :'(

Cuando tenga la nueva gráfica pondré tu tenerife vfr y probaré la nueva malla.

Otra prueba por GCTS solo por la costa hasta Los Gigantes y regreso, de momento no le encuentro problemas, iré dando mas vueltas

Gracias a todos!

No sé cuándo podré seguir con este tema... lo peor es que se me habrá olvidado todo  ::)

Se me ha ocurrido que puedo matar dos pájaros de un tiro y hacer lo siguiente: juntar escenarios fotográficos Simheaven (g2xpl) + mallas HD2 Alpilot + raster MDT25 para conseguir una malla UltraHD fotográfica.

Para ello he partido de las mallas fotográficas de Simheaven, ya con malla HD2, y le he metido el MDT25. Dicho MDT no haría nada pues las mallas producidas por g2xpl no lo admiten directamente. Tuve que hacer un "truquito" (mediante una modificación del ter2xp10).

Una vez hecho esto, le puedo pasar Pintadera y conseguir más triángulos... hasta aquí, todo "bien". Ejemplo:

Tenerife (sur+Teide). Escenario fotográfico z17 con HD2 (lo pueden conseguir en: http://simheaven.com/?wpfb_s=esp&page_id=238&wpfb_list_page=1 (http://simheaven.com/?wpfb_s=esp&page_id=238&wpfb_list_page=1)):
(http://s30.postimg.org/4u2m1d0p9/TF_ortoz17_1_HD2.jpg) (http://postimg.org/image/4u2m1d0p9/)

Tenerife (sur+Teide). Escenario fotográfico z17 con HD2 + MDT25:
(http://s30.postimg.org/wip98vnpp/TF_ortoz17_1_UHD1.jpg) (http://postimg.org/image/wip98vnpp/)

Tenerife (sur+Teide). Escenario fotográfico z17 con HD2 + MDT25 y una pasada de Pintadera:
(http://s30.postimg.org/ho0nupe4t/TF_ortoz17_1_UHD2.jpg) (http://postimg.org/image/ho0nupe4t/)

Biennnn, ¿no? Se nota la ganancia en detalles. Peeeeero, miremos esta otra zona de la isla:

Tenerife (roques de Anaga). Escenario fotográfico z17 con HD2:
(http://s30.postimg.org/9owazmz0t/TF_ortoz17_2_HD2.jpg) (http://postimg.org/image/9owazmz0t/)

Tenerife (roques de Anaga). Escenario fotográfico z17 con HD2 + MDT25:
(http://s30.postimg.org/lfa8h0rt9/TF_ortoz17_2_UHD1.jpg) (http://postimg.org/image/lfa8h0rt9/)

Tenerife (roques de Anaga). Escenario fotográfico z17 con HD2 + MDT25 y una pasada de Pintadera:
(http://s30.postimg.org/mvlqz5uq5/TF_ortoz17_2_UHD2.jpg) (http://postimg.org/image/mvlqz5uq5/)

¡Horror!  ??? La nueva Pintadera, que consigue dividir triángulos también en líneas de costa, se peleea con la modificación de ter2xp10 que apliqué y se generan estos molestos triángulos blancos...

Vale. Esto creo que lo puedo solucionar con un poco de paciencia.

Sin embargo, ocurre otra cosa mucho peor relacionada con la aplicación de ter2xp10: Las masas de agua no costeras... DESAPARECEN.

Tenerife (balsa de Taco, en Los Silos). Escenario fotográfico z17 con HD2 + MDT25:
(http://s30.postimg.org/5antnsogd/TF_ortoz17_3_UHD2.jpg) (http://postimg.org/image/5antnsogd/)

??? ???

mmm, seguiré investigando a ver qué puede estar pasando. Si encuentro la solución, en breve podría tener un escenario fotográfico con HD3 de AlpilotX más raster MDT25 de Canarias (y pasaría de Canarias SHD 3.0  ;D)

Bien! Ya conseguí arreglar este último y peor problema. Al final pasé del ter2xp10 y me hice un script/programita nuevo que, "simplemente", asigna -32768 a la altura de los "vértices de tierra no costeros". Y lo pongo entre comillas porque ahí es donde está el problema.

Distinguir entre un vértice (de un patch) de tierra y uno (de un patch) de agua es fácil. Ahora bien, distinguir un vértice de tierra que linda con agua (es costero) es algo más complicado. Al final usé una idea que había añadido a Pintadera en las últimas versiones pero con una modificación pues los escenarios generados por g2xpl tienen la extraña característica de que los vértices de tierra costeros no coinciden exactamente con los vértices costeros de agua (se ve un pequeño triángulo blanco que separa ambas zonas)...

...y de ahí radica precisamente el problema número 1 de Pintadera que supongo que podré arreglar aplicando la misma modificación.

Tenerife, Montaña Roja. Escenario fotográfico z17 con HD2 + MDT25 (no hay triángulos blancos en la costa):
(http://s1.postimg.org/ff2h5970b/TF_ortoz17_4_UHD1.jpg) (http://postimg.org/image/ff2h5970b/)

Tenerife, Montaña Roja. Escenario fotográfico z17 con HD2 + MDT25 + una pasada de Pintadera (aparecen los triángulos blancos en la costa; cosa que espero poder arreglar en breve):
(http://s1.postimg.org/hxo65xsqj/TF_ortoz17_4_UHD2.jpg) (http://postimg.org/image/hxo65xsqj/)

Se ve la luz al final del tunel...  ;D

Menos mal que va refrescando el tiempo, que si no fuese así se te cocía el pelo  ;)

:D

Ya sabes, con el temporal, he aprovechado estos días a ratitos para sentarme tras el ordenador...

Bueno, ya modifiqué Pintadera y conseguí pasarlo sin crear (muchos) triángulos blancos.

Seguiré con las pruebas...

Mirando la documentación del G2XPL, resulta que tiene implícito en su algoritmo la creación de triángulos blancos (triángulos vacios, sin tierra ni agua) si son muy pequeños (por ahorrar tiempo y "perfomance"). Por ello supongo que tengo tantos problemas con la conversión y ampliación de densidad de triángulos... de hecho, éstos se "amplifican" y se hacen muy patentes.

Estudiaré un método mejor de hacer todo esto y, por otro lado, intentaré crear yo los escenarios mediante G2XPL utilizando de arranque la malla SHD 3.0 que tenía por ahí en el horno... a ver qué sale mejor.

Seguiré informando

Cańa

Por finnnnnnnnn....  :D

Ya está disponible Canarias Super HD 3.0: Descargar desde esta web (http://www.x-plane.es/modules/TDMDownloads/singlefile.php?cid=24&lid=144) o desde mi página (http://www.cestomano.com/mas/xplane/#canariasshd).

Las principales novedades de esta versión son:

- Malla de origen HD Mesh 3.0 de AlpilotX (Canarias SHD 2.0 partió de la malla por defecto de X-Plane), con todos los overlays, masas de aguas, costas, etc. actualizados.
- Usada la última versión de Pintadera (mejora el "levantamiento" de vértices nuevos a nivel de mar, p.e.: roques, penínsulas...)
- Arreglado bache en la 34 de GCHI
- Allanado el terreno para el helipuerto de Izaña Militar y de El Vallito (disponibles en Tenerife VFR)

Para instalar, simplemente, copiar/mover la carpeta "zzz Canarias SHD 3.0" al Custom Scenery y cargarse, si existiera, "zzz Canarias SHD 2.0". Eso sí, en el scenery_packs.ini debe figurar con baja prioridad; después de todos los escenarios, pero antes que otros escenarios que tengan definidas mallas, por ejemplo, los de Simheaven fotográficos o el HD Mesh 3.0 de AlpilotX.

NOTA: Solo para X-Plane 10!!! (versión 10.30 o superior).

****************************************************

Sobre el tema que estuve trabajando hace unas semanas con los fotográficos de simheaven para aplicarles la malla SHD, lo he dejado. Los triángulos blancos son insalvables. Solo me queda probar a construir yo mismo el escenario con el g2xpl a partir de mi malla. Lo dejo para más adelante.  ::)

Gracias, lo pruebo
Edit: Casi de verdad.

(http://i806.photobucket.com/albums/yy348/evaristo2008/Sintiacutetulo_zps9e0c599f.jpg) (http://s806.photobucket.com/user/evaristo2008/media/Sintiacutetulo_zps9e0c599f.jpg.html)

(http://i806.photobucket.com/albums/yy348/evaristo2008/Sintiacutetulo2_zpsbdb1f5cb.jpg) (http://s806.photobucket.com/user/evaristo2008/media/Sintiacutetulo2_zpsbdb1f5cb.jpg.html)

La malla tb tiene el tema que tiene la malla de alpilot?, me refiero a datos no solo de la elevación,  tb lleva datos de puentes, carreteras etc?

Edit: mira en el Hierro el papi de la rwy 16 se derrumbo jajjajaj.

En efecto, tiene todos los "overlays".  ;)


Cierto, es uno de los "known issues" (que no puse). Con el aeropuerto de El Hierro me estuve peleando tooooda la tarde para arreglar la cabecera 34 y quitar baches que aparecían en la pista. Cuando terminé y vi que una luz del PAPI 16 estaba caída... casi tiro el ordenador por la ventana.  8)

En serio, es muy difícil corregir esto, es a ciegas, prueba y error y cada paso que das acarreas unos efectos secundarios acojonantes. Si arreglo lo de los PAPIs aparecen baches en la pista así que... "el mal menor".

Gracias por el testeo!! (se agradecerán más testeos)  ;)

(PD: En la malla de AlpilotX y en el recut de X-Plane de el Hierro también existe dicho problema, creo recordar)

En el evento testearé más en profundidad.
Gracias por el esfuerzo.

Una comparativa:

Tenerife VFR + malla por defecto XP 10.32:
(https://dl.dropboxusercontent.com/u/1126231/X-Plane/TVFR%20default.jpg)

Tenerife VFR + malla HD 3.0 de AlpilotX:
(https://dl.dropboxusercontent.com/u/1126231/X-Plane/TVFR%20HD%20Mesh%203.0.jpg)

Tenerife VFR + Canarias SHD 2.0:
(https://dl.dropboxusercontent.com/u/1126231/X-Plane/TVFR%20C%20SHD%202.0.jpg)

Tenerife VFR + Canarias SHD 3.0:
(https://dl.dropboxusercontent.com/u/1126231/X-Plane/TVFR%20C%20SHD%203.0.jpg)

Como se puede apreciar, la mejora es sustancial respecto a la malla por defecto del XP y también se nota respecto a la HD 3.0 de AlpilotX. Eso sí, respecto a Canarias SHD 2.0 no hay mucha diferencia...

...la ventaja de esta versión 3.0 es, precisamente, la fuente (HD Mesh 3.0) por lo que tiene los overlays (edificios, carreteras, ...), masas de agua, costas, etc. actualizados. A parte de las otras cosicas mencionadas  ;)

Hola Cestomano, agradecido por tu trabajo. Yo tenía puesto tus escenarios de la versión: SHD 2.0 y ahora les he puesto estos nuevos de Canarias SHD 3.0.

Me lo acabo de bajar, justo ahora, y estoy dando una vuelta por las inmediaciones del Aeropuerto Tenerife Norte.

Gracias!

Un saludo!

Zeni

Cestomano estaría bien saber como hacían en simheaven para incorporar las mallas de Alpilot a los fotoreales. Porque falto incorporar las mallas a Baleares y Canarias. Sabes algo del tema.

Gracias por tu trabajo. Leva tu disco duro para que copies el fotoreal

Solo sé cómo generar un escenario nuevo fotográfico con el g2xpl a partir de una malla actualizada...

Sí, llevaré disco  ;)