Mallas \"Super HD\" (Canarias SHD) y escenarios foto independientes de malla

10 Abril, 2012, 11:57:19

#45

Cestomano

Superusuario

Desconectado

Mensajes: 5484

Me cansé de la capa; ahora sólo vuelo en avión...

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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.

¡¡NO contesto dudas por mensaje privado!!

x-plane.cestomano.com
www.spainuhd.es

[

10 Abril, 2012, 12:38:26

#46

galvedro

Usuario Iniciado

Desconectado

Mensajes: 286

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

Pues una información más Giñar

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.
crash

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).

10 Abril, 2012, 13:54:08

#47

grrr05

Superusuario

Desconectado

Mensajes: 4361

If it ain't broke don't fix it

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

Cita de: galvedro en 10 Abril, 2012, 12:38:26

Pues una información más Giñar

Bien, esto es genial, muchas gracias Giñar

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!

Albert Ràfols
www.spainuhd.es

10 Abril, 2012, 17:09:07

#48

jorduran

Superusuario

Desconectado

Mensajes: 9988

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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

Un buen aterrizaje es el que sales andando.
Un gran aterrizaje es cuando el avion puede seguir volando.

Telefonica ha cerrado mi WEB sin preaviso.
PHOTOBUCKET A CORTADO LAS FOTOS

10 Abril, 2012, 18:38:30

#49

Cestomano

Superusuario

Desconectado

Mensajes: 5484

Me cansé de la capa; ahora sólo vuelo en avión...

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

Cita de: grrr05 en 10 Abril, 2012, 13:54:08

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

Saludos

¡¡NO contesto dudas por mensaje privado!!

x-plane.cestomano.com
www.spainuhd.es

[

10 Abril, 2012, 19:21:55

#50

grrr05

Superusuario

Desconectado

Mensajes: 4361

If it ain't broke don't fix it

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

Aquí tienes
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 Cheesy

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


« Última modificación: 10 Abril, 2012, 19:25:41 por grrr05 »

Albert Ràfols
www.spainuhd.es

10 Abril, 2012, 20:38:19

#51

galvedro

Usuario Iniciado

Desconectado

Mensajes: 286

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

Cita de: grrr05 en 10 Abril, 2012, 13:54:08

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.

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"

10 Abril, 2012, 21:04:15

#52

grrr05

Superusuario

Desconectado

Mensajes: 4361

If it ain't broke don't fix it

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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.

Albert Ràfols
www.spainuhd.es

10 Abril, 2012, 22:07:20

#53

Cestomano

Superusuario

Desconectado

Mensajes: 5484

Me cansé de la capa; ahora sólo vuelo en avión...

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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

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

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).

¡¡NO contesto dudas por mensaje privado!!

x-plane.cestomano.com
www.spainuhd.es

[

10 Abril, 2012, 23:00:20

#54

zxplane

Administrador
Superusuario

Desconectado

Mensajes: 4289

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

¡¡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?.

10 Abril, 2012, 23:22:08

#55

Cestomano

Superusuario

Desconectado

Mensajes: 5484

Me cansé de la capa; ahora sólo vuelo en avión...

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

Cita de: zxplane en 10 Abril, 2012, 23:00:20

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. Giñar

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)

¡¡NO contesto dudas por mensaje privado!!

x-plane.cestomano.com
www.spainuhd.es

[

11 Abril, 2012, 00:34:07

#56

grrr05

Superusuario

Desconectado

Mensajes: 4361

If it ain't broke don't fix it

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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

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 Sonreir


« Última modificación: 11 Abril, 2012, 00:37:11 por grrr05 »

Albert Ràfols
www.spainuhd.es

11 Abril, 2012, 09:44:55

#57

galvedro

Usuario Iniciado

Desconectado

Mensajes: 286

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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?

11 Abril, 2012, 10:02:37

#58

grrr05

Superusuario

Desconectado

Mensajes: 4361

If it ain't broke don't fix it

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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.

Albert Ràfols
www.spainuhd.es

11 Abril, 2012, 10:49:10

#59

galvedro

Usuario Iniciado

Desconectado

Mensajes: 286

En línea

Re: Convirtiendo escenarios fotorrealistas independientes de la malla

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/)

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


« Última modificación: 11 Abril, 2012, 10:54:35 por galvedro »

Tags:

Páginas: 1 2 3 [4] 5 6 ... 30 Ir Arriba

Imprimir

« anterior próximo »

Ir a:

www.x-plane.es.

MySQL | PHP | XHTML | CSS

Página creada en 0.093 segundos con 19 queries.