Foro x-plane.es

pues eso,comentaros mis primeros(y únicos)pasos con esta aplicación,para que sirva como mini tutorial y se anime mas gente.

como muchos sabeis es una utilidad para crear escenarios fotorrealistas sin apenas esfuerzo,o sea,la calidad no va a ser como la de spain uhd asi sin mas,luego lo vemos

Primero:
pues si no tenemos la aplicación descargarla ;D,en este enlace;https://www.dropbox.com/sh/cjjwu92mausoh04/AACt-QzgMRwKDL392K_Ux3cPa?dl=0,el autor cuelga la ultima version,no se compromete a actualizar el enlace que tiene en el .org,por algo sera...la version actual es la 1.20  
lo que descargamos es un .zip que de momento vamos a descomprimir en el escritorio para tenerlo a mano

segundo:
una vez descomprimida la carpeta entramos y buscamos ortho4xp/bin/ortho4xp_v120b.exe. recomiendo hacer un acceso directo para mas comodidad.
no hay que instalar nada,es portable 100% y perfectamente podemos meterla en un disco externo y ponerla a trabajar en el pc que queramos

tercero:
cuando pinchemos se abrirá una ventana de comandos(que no cunda el pánico,esa la minimizamos)y a la vez una ventana de interfaz que va a ser con la que funcionemos.
en este punto os pido perdón por no poner mas capturas,pero si dedico tiempo a aprender ese tema no se si estaría escribiendo esto.
bien,en la ventana de interfaz pincharemos en earth tile map(veréis que vamos a ir de arriba a abajo paso por paso,es muy sencillo)y accedemos a un mapa mundial.cada uno elegirá lo que quiera,pero aquí yo voy a poner granada como ejemplo.
desplazamos el mapa pinchando con el botón DERECHO del raton y arrastramos,pinchamos sobre granada y aparecerá un rectángulo amarillo,esa zona es la que vamos a fabricar.una vez seleccionado vamos a cerrar la ventana del mapa,luego vemos las demás posibilidades que ofrece,de momento vamos a ir al grano.
ya de vuelta en la ventana principal,vereis que en el apartado tile coordinates ya os aparece latitude:37 longitude -4,vamos bien.
el cuadro custom build_dir ni caso,es para elegir otra carpeta donde guardar las tiles que encarguemos.

cuarto:ya sabemos que vamos a hacer,ahora vamos a elegir base source,que es el servicio publico o privado al que vamos a solicitar las fotografías que son la materia prima.de momento trabajaremos con BI,que en cristiamo es BING,de Microsoft,ofrece una cobertura casi global con una calidad bastante uniforme.
AQUI VIENE LO BUENO ;);base zoom level:
es muy sencillo,mayor el numero,mayor la resolución,la trampa que el crecimiento es exponencial,por ejemplo,a zoom level(ZL)16,granada pesa 2,21 gb,a ZL 17 ,multiplicamos mas o menos por 4 y nos vamos a casi 9 gb y si nos da por probar a ZL 18 sube a casi 30 gigas.
no cometáis el mismo error que yo,cuando complete la peninsula a ZL18 ocupando 1700(MIL SETECIENTOS)GB resulta que en España peninsular(con pocas excepciones) no pasa de ZL 17(gracias Albert)
bueno,vamos a seleccionar ZL16,rapido para probar y nos dara suficiente calidad para ver si nos interesa seguir probando.
sea source y sea zoom level lo dejamos en blanco.no deis tampoco a custom zoomlevel de momento,eso sera para la siguiente que hagamos

quinto:
en el apartado build vector data solo nos aseguraremos de tener en la casilla Min_area el valor 0.01,¿por que?no lo se,no os voy a engañar,me va bien asi.
pinchamos en step 1:bulid vector data y empiezan a salir un monton de letritas en el cuadro de al lado...ni caso,esta construyendo los datos de ríos carreteras,etc.despues de poco tiempo nos sale un mensaje de completed in xxx sec(según el pc y la zona)

sexto:
build base mesh.vamos a encargar las mallas sobre las que luego dejaremos caer las fotos.yo solo toco el valor Curv_tool,y lo dejo en 1.0   ¿que es?pues no como funciona,solo lo que hace...
a MENOR valor,MAYOR la complejidad de la malla.vamos a experimentar y vamos a introducir 3.0,todo lo demás en blanco.
pinchamos en build base mesh y....mas letritas,pero ahora debéis fijaros en un numero;Mesh triangles: 1,281,270
ahora repetimos pero con el valor 1.0.borrara los datos anteriores y ahora el resultado sera muy distinto,el numero de polígonos ha subido a 3,239,540.
este numero dependerá de la zona,en zonas accidentadas saldrán mas polígonos y en zonas llanas menos a igual valor.
¿Cuánto es seguro?pues el impacto depende del pc,no he hecho pruebas comparativas,solo deciros que en pirineos tengo un tile con 7 millones largos de polígonos y no noto mas uso de ram ni menos frames,solo sed prudentes con este valor y tenerlo vigilado.

séptimo
aquí suele haber mas dudas,eb el apartado build tile hay dos tareas independientes a realizar,primero vamos a hacer el paso 2.5(build masks)
esto no son ni mas ni menos que texturas que suavizan el cambio de tierra a agua,es decir líneas de costas.no es imprescindible pero hace mucho por la calidad.
dejaremos en blanco skip downloads, skip converts y clean unused dds/ter files,marcaremos las cuatro restantes
valor mask width.significa como de ancha va a ser la textura transparente que mezcla costa y agua,y aquí nos referimos a Todas las masas de agua que existan,incluso balsas de riego.el pasarse no es malo,yo dejo el valor 8 y a correr.lo que veremos en ríos y lagos con este valor es que el agua aparece igual que en las fotos(ríos verdes o amarronados,embarcaderos,etc)pero debajo siempre habrá agua en la que amerizar o hundirse(eso ya cada cual)y mostrara los reflejos y brillos típicos de xplane.
para el que no le convenza o en zonas donde la foto tenga algún problema,reduciremos el valor,a 0 la delimitación tierra agua la definirá solo la malla,y tendremos costas y ríos poligonales

octavo.pues sin tocar nada mas pinchamos en step 3:Build Tile(no hace falta esperar que termine el paso anterior)
yo he hecho trampa y ya la tengo terminada hace un rato,si la vais a hacer es momento de tomar un descanso(no muy largo)

vale pues ya se han llenado las barritas de progreso y nos aparece un mensajito que dice completed in xxxx sec(según pc y ZL)pues ya esta el tile hecho 8)
solo nos falta el autogen,sin el solo vamos a volar en sobre fotos planas

noveno :
en el apartado build overlays  vamos seleccionar la casilla custom build dir,lo que abrira una ventana del explorador de archivos.¿que estamos buscando?el archivo dsf donde xplane guarda los datos que colocan todas las casitas,arbolitos y demás que aparecen en el autogen,esto no va a interferir con los demás escenarios que tengáis instalados.la mayoría de nosotros tenemos dos opciones,el autogen por defecto de xplane o el que viene con el hd mesh de altpilotx.como el que se seguro que todos teneis es el de xplane vamos a localizar ese.
seleccionamos la carpeta de xplane/global scenery/x-plane 10 Global scenery /earth nav data(xplane 11 es lo mismo)seleccionamos carpeta y pinchamos en build overlay
la aplicación siempre va a buscar en la carpeta earth nav data,si teneis el hd mesh  la buscais en custom scenery y tendréis un autogen muy superior
y ya esta,nuestro escenario terminado,¿pero donde esta?

decimo y ya volamos:

entramos en la carpeta de ortho4xp y entramos en tiles.alli nos encontraremos la carpeta zOrtho4XP_+37-004.esa derechita al custom scenery.ya todos tenemos claro el orden de los escenarios,recordad que solo las mallas deben tener prioridad mas baja que un escenario fotográfico.

ahora buscamos la carpeta yOrtho4XP_Overlays.esta carpeta contiene el autogen,y debe ir justo encima del escenario fotográfico.debemos copiar la carpeta entera en custom scenery.

pues esta es una captura a ras de suelo (para sacarle pegas) de lo que acabamos de hacer en xp 10 a 4k sin plugins ni ningún otro addon


(https://s13.postimg.org/uoypoxifn/c4_18.jpg) (https://postimg.org/image/uoypoxifn/)

y esta es con otro tile a ZL17 con los mismos parámetros y en la misma posición y hora del dia

(https://s2.postimg.org/z491rt9w5/c4_16.jpg) (https://postimg.org/image/z491rt9w5/)

como veis la diferencia a corta distancia es tremenda,pero a lo lejos incluso a 4k es inexistente,cada uno debe valorar los gb y su estilo de vuelo

desde el punto de vista de las prestaciones,siempre que no agoteis la vram incluso tendréis mas fps que con las texturas de xplane,a mi me va mejor incluso con el autogen del hd mesh

pues nada familia,si os sirve de algo el ladrillo,yo soy el que os da las gracias,y si teneis problemas,que los tendréis,aqui me teneis.
por supuesto hay mucho mas que añadir peeero,primero lo básico.

por supuesto,agradezco muchísimo aportaciones y correcciones o zascas

Gracias, gentec !!!

Pero como diría jordi, lo ideal es que lo pongas en la Wiki  ;)
http://www.x-plane.es/modules/mediawiki/index.php?title=Portada

(que pa\' eso está)

 
 o:k

Gracias infinitas, Gentec !!

Hacer algún pinito con ortho4xp es algo que siempre me rondaba, pero la mandra me podía más.

Con este tutorial lo has puesto tan fácil que no voy a poderme resistir de probar a hacer un escenario que me daba vueltas hace tiempo.

Ignoraba que se podía escojer una malla superior a la malla por defecto de X-Plane. Tengo la de AlpilotX, y un fotorreal sobre esa malla, y a ZL17 (impresionante la diferencia a baja altura) tiene que ser brutal.

Ahora cualquiera se resiste !!

Bajando la aplicación !!

Como dice Jordi Durán y Cestomano, esto se merece un sitio en la Wiki !

lo he puesto como mensaje normal para mantenerlo abierto y poder centralizar las dudas,pues esta muy incompleto y básico.cuando tenga un rato lo paso añadiendo la utilidad para hacer varios tiles a la vez,que se gana mucho tiempo,y varias cosas mas.

¿el acceso y escritura a la wiki es libre?

Me corrijo a mí mismo.
Veo que no se puede escojer una malla en particular. Lo que sí se puede seleccionar es el Overlay de AlpilotX, pero no su malla HD. Así es como Gentec lo ha explicado, pero lo he entendido mal en mi entusiasmo

Una vez bajado el programa y leídas las instrucciones que incluye, veo que los datos de elevación los baja de un proveedor que publica los datos de SRTM, que son de 3\\\'\\\' de arco (de Ferranti).

No sé si hay alguna manera de conseguir datos de elevación de más calidad. Si no me equivoco, los datos de elevación por defecto de X-plane son de más resolución que los SRTM... es así ?

De Ferranti tiene datos a 1\\\'\\\' de arco, pero son por interpolación...

Dependiendo de los proveedores de cada país, suelen existir datos de elevación bastante mejores que los proveedores con covertura global, pero por supuesto hay que transformarlos y mergearlos para que ocupen enteramente una celda de 1ºx1º.
La SRTM cubre todo el planeta tanto con resolución de 1 segundo como de 3 segundos, los primeros tienen mucho ruido y los segundos son los que usa X-Plane por defecto (90 metros). También existen los de la agencia japonesa JAXA, también de 1 segundo y son bastante mejores que los SRTMGL1, pero lo malo es que son DSM, modelos de superfície, no de terreno, lo que significa que árboles y edificios y demás elementos que no sean terreno igualmente están allí, se pueden tratar con software como GRASS o SAGA para "eliminar" ese exceso de información, pero no es tarea facil ni mucho menos rápida.
De hecho, trastear con datos de elevación nunca es facil cuando solo tienes coverturas parciales y/o distinta resolución, y eso es lo que suele pasar al usar datos exclusivos por países, siempre que estén disponibles.

Las mallas por defecto de XP utilizan datos MDT90 (un dato de elevación cada 90 metros).

Las HD de AlpilotX también, aunque sus mallas tienen los mismos puntos (pero los raster, que definen las alturas, son los mismos MDT90).

Las UHD de AlpilotX utilizan MDT30, pero la fuente de datos, si no me equivoco, no es pura; es una interpolación a partir de la 90.

SpainUHD 1.0 utiliza MDT30 puro (por suerte, tenemos esos datos libres en España), salvo en Portugal, que utiliza MDT90. La antigua Canarias SHD también.

SpainUHD 2.0 utiliza MDT25 puro.

Tagoror utiliza MDT30 cuyo raster ha sido fabricado a mano por el menda  :D


Lo que he visto del Ortho4XP y que no me ha gustado (también pasaba con el g2xpl) es que no utiliza rasters, sino define las elevaciones de la malla en los propios vértices, como en las mallas de XP9. Los rasters se introdujeron en XP10 y supusieron una gran mejora en el tratamiento de la orografía; no entiendo este paso atrás...  :(

EDITO: Grrr05, te me has adelantao...  ;D

En Portugal utilicé SRTMGL1 de 30 metros y no veas el coñazo en los aeropuertos, pero el resto de la orografía lo merecía.
También es cierto que los SRTMGL1 y AW3D de JAXA tienen muchas zonas en blanco (NO_DATA) debido a nubes y otras interferencias durante la toma, estos los tuve que interpolar con SRTM3, otro handicap a la hora de tratar con datos de elevación...  :D

 :-X

(corregido)

Gracias gentec,tremenda guía. :-m-

Sorprendente... X-Plane usa datos MDT90?

Me sorprende por lo siguiente: Tengo un mesh en una resolución de 76m para Fs2002-2004 y ocupa 3 DVDs monocapa, o sea, 14Gb

(http://i1371.photobucket.com/albums/ag319/jcanos/wel2_zpshmsscplk.jpg)





En la otra cara consta la resolución: 76m y en algunos lugares, 38m

(http://i1371.photobucket.com/albums/ag319/jcanos/wel1_zpsrp3ifmbr.jpg)


Me sorprende que X-plane necesite 8 DVDs de doble capa. (?)


Pero si que es cierto que, cargando estas mallas en FS2004, la resolución aumenta hasta un nivel cuando menos muy parecido al de X-Plane.

Quizás los datos estén manipulados de una manera que ocupen mucho más espacio...


Me alegra saber que el mesh HD de AlpilotX es de 90m... interpolado como los de Ferranti. Eso significa que con esa calidad de datos ya se pueden conseguir resultados decentes. Creía que la resolución de las mallas de Ferranti era algo obsoleto para la calidad de mallas que creía que teníamos con AlpilotX y otros...

Así, pues, la cosa no es tan grave.  :)

Aquí está la principal diferencia entre las mallas de XP y FS, en el segundo los vértices en realidad son una matriz de triángulos generada a tiempo real, mientras que en XP los vértices son fijos y están codificados en el DSF, ergo ocupando espacio en disco, pero en cuestiones de rendimiento es mucho mas eficiente, pues no hay que ir recalculando la malla según la posición del avión en cada momento, se cargan en memoria y aire (y mientras vamos volando se van cargando en segundo plano cuando llega el momento, no en un proceso constante y no requiere ningún tipo de cálculo a tiempo real), el inconveniente de esas mallas estáticas es que una vez creadas son casi imposible de editar, pero el resto todo son ventajas. El sistema de mallas de FS va por capas y parches, lo que suele traducirse en mal rendimiento. Evidentemente en XP han optado por el rendimiento en contra de la versatilidad de FS  (hablando de mallas, claro).

Por cierto, las mallas HD de Andras usan mayoritariamente los datos de 30 metros de Jonathan de Ferranti y en algunas partes usa los AW3D de JAXA, también de 30 metros, pero que yo recuerde ninguna de sus mallas usan datos de 90 metros, salvo el Global Scenery, claro.

Por supuesto  ;) y en el supuesto que no tengas acceso, un privado a Zxplane y contento de que la xpeña colabore

Como los datos de 30m de de Ferranti están obtenidos por interpolación a partir de datos de 90m(*), tenemos que los datos de elevación HD de Andras proceden de un mesh de 90m.

Si todo y así se ven tan bien, pues esa es la buena noticia.

Veo que, además, en la web de de Ferranti (viewfinderpanorama.org) se ofrecen datos de elevación de 1\'\' de arco, que deben ser los interpolados a partir de los cuales Andras ha hecho los suyos HD.

Eso significa que si se eligen esos datos de elevación en ortho4xp (por lo que leo en el manual, se puede hacer) se pueden conseguir unos \"fotorreales HD\" más que decentes.

(*) Como mínimo es lo que siempre he creído. Otra buena noticia sería que fueran de 30m \"de verdad\"

hpara probar el tema de elevaciones he hecho un tile(40-5) a zl11 y he grabado una situación en xp10,asi lo único que varia es la malla.

esta captura es dejando solo el ortho4xp con el curv_tool en 1.0
(https://s2.postimg.org/50rbvqvb9/c4_19.jpg) (https://postimg.org/image/50rbvqvb9/)

después he descargado el DEM de http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org1.htm la casilla 40 -5,que después de descomprimir me aparece un archivo .HGT.en el apartado build base mesh seleccionamos la casilla custom dem file y buscamos su ubicación,el programa reconoce el archivo sin problemas.cuando fabrique la malla veréis que tarda mas y genera mas polígonos.el resultado sera esto:


(https://s10.postimg.org/of7fxtnfp/c4_20.jpg) (https://postimg.org/image/of7fxtnfp/)

para ver la diferencia tendréis que descargaros las imágenes y pasarlas rápido con el visor de fotos de windows,porque no hay mucha.
he usado los archivos a 1 segundo,de los que hay muy poca cobertura,si hutilizo los de 3 segundos de arco,los resultados van a ser creo que muy parecidos

Eso siempre depende de la calidad de los datos, al igual que pasa con las fotos, mayor resolución no tiene porque ser lo mismo que mayor definición, y de hecho los datos de 1 segundo de Jonathan estan hechos por interpolación partiendo de los de 3", pero por ejemplo en Italia se pueden conseguir unos datos puros de 20m que no tienen nada que ver, lo mismo se puede aplicar a nuestros mdt25, la diferencia entre esos y los SRTM (y derivados) es la toma de datos, los primeros parten de lidar con aviones a baja altitud, los segundos están tomados desde el espacio mediante una técnica basada en el reflejo de ondas de radio. Aunque se puede obtener la misma resolución espacial en ambos métodos, la definición nunca será la misma.

Hay mucha gente que no tiene claro en qué consisten los datos de elevación, por si acaso dejo una expliacación de lo que nos podemos encontrar por ahí y el porqué unos datos con mayor resolución no tienen por que ser mejores.

Los datos de elevación son sencillamente imágenes (de ahí que siempre los vamos a encontrar catalogados como "raster" en los sistemas de información geográfica, aunque podamos encontrarlos en decenas de formatos distintos, pero la representación es tan simple como que cada valor de color representa una altitud concreta.

Y esto es un pequeño test para mostrar la diferencia entre resolución y definición.

-La típica carta de ajuste. Imaginemos esto como una pequeña parte del planeta, donde hemos hecho una foto desde 50 kilómetros de distancia con una cámara de mierda o con mal tiempo, lo que prefiráis.
Esto es lo que ha capturado la cámara. Ahora tenemos -supuestamente- datos de elevación con una resolución espacial de 3 segundos de arco y unas dimensiones de 256x192 pixeles.

(http://i.imgur.com/cdzoGNH.png)

-Ahora la ampliamos 9 veces mas, el equivalente a una resolución espacial de 1 segundo de arco, las dimensiones ahora son 768x567.

(http://i.imgur.com/kKpo2qQ.png)

Bien, se puede ver como el area que ocupa es mucho mayor, sin embargo es una vulgar ampliación, se ha ampliado cada pixel por igual, con lo que la resolución espacial sigue siendo la misma, sólo que cada pixel (la información de altitud) ocupa 9 veces mas. No hay nueva información, lo que antes era un punto en un pixel ahora es un cuadro que ocupa 9 pixeles, de ahí los bordes con dientes de sierra y demás defectos de la imagen.

-Pues repetimos la ampliación pero esta vez usando un filtro bicúbico, que no es más que una fórmula matemática para calcular la interpolación de nueva información. Es un cálculo totalmente artificial y se basa en la información existente.

(http://i.imgur.com/1geLTnx.png)

La diferencia es notable, han desaparecido los bordes de sierra y las líneas ya no aparentan tan gordas, pero toda la imagen parece borrosa, lo que significa que se aprovechan mas los píxeles debido a la interpolación, con lo que la resolución espacial sería prácticamente de 1 segundo de arco, pero la nueva información es escasa, ya que está basada en la existente de la imagen anterior. Obviamente no podemos "reproducir" lo que no existe, pero esta aproximación es plausible y por lo tanto, válida.

- Y por último, la misma zona del planeta pero fotografiada con una cámara (y unas manos) mejores y a 100 metros de distancia.

(http://i.imgur.com/ezcnIup.png)

Poco que decir ¿no? Se ha capturado lo que realmente existe, sin ningun tipo de alteración. No hay que añadir ni quitar nada, la información contenida es totalmente verídica, con lo que tenemos una resolución espacial de 1 segundo de arco con una definición total, lo máximo que permite cada pixel..


Pues eso mismo ocurre con los datos de elevación y los procesos de tratamiento que mete cada uno, es exactamente lo mismo, sólo que los datos de elevación tienen esta apariencia:

(http://i.imgur.com/EfTOwLJ.png)

Puede que algunos ya lo supiérais, pero es que mas de uno se ha quedado pillao al decirle que utilizo Imagemagick para suavizar aeropuertos con precisión submétrica  :D

Una explicación clara y muy didáctica.
 ;)

La última imagen no son datos de elevación, es una foto de un cerebro  :D :D  MUY CLARAMENTE EXPLICADO. Gracias

Es el valle de la Cerdanya y Andorra, se puede apreciar LESU ;)

La imagen está reducida unas 20 veces pero fijándose se puede ver la diferencia entre los MDT25 de 25 metros (mitad inferior) y los AW3D de JAXA de 30 metros ampliados a 25 por interpolación (mitad superior), en esta celda precisamente hay datos combinados por ser fronteriza.

Para crear o modificar algún contenido en la Wiki, el único requisito necesario es ser miembro registrado en la Web.

Aquí hay un tutorial muy bueno de ortho4xp
https://www.youtube.com/watch?v=2fqT2OPgEeE

Pues ya he empezado  a hacer pruebas, sobre todo de cara a valorar si realmente el mesh de 3 segundos de arco de de Ferranti es superior al mesh por defecto de X-plane, suponiendo que el de Ferranti se basa en una interpolación del de 90m de X-plane, cosa que en realidad no sé.

Si fuera así, no habria diferencias muy dramáticas entre la malla por defecto y la de de Ferranti.

Situémonos, pues:

Como test he utilizado una montaña bastante despiadada con las mallas de poca calidad: El Pedraforca.
Para quien no la conozca, se trata de un pico doble (de ahí su nombre), que cuesta representar correctamente con una malla de escasa precisión.

Aquí tenemos al Pedraforca representado con la malla por defecto de X-plane:

(https://s25.postimg.org/irbjrox7j/A_pelo_total.jpg)


No está mal.... se puede adivinar (sólo adivinar) que el pico es doble

Aquí lo tenemos ahora con el HD-Mesh de AlpilotX, que es en realidad el de de Ferranti, pues si no me equivoco, Andras (AlpilotX) lo obtuvo de allí.


(https://s25.postimg.org/g16t88pwf/AlpilotXmesh.jpg)

Esto es otra cosa. El doble pico queda mucho más claro.


Veamos ahora qué tal se ve con el UHD-Mesh de AlpilotX:

(https://s25.postimg.org/ftj6bqexr/AlpilotXmeshUHD.jpg)

Se ve poca diferencia, lo cual me hace pensar que es una interpolación a 1 segundo de la malla anterior (de 3 segundos)
Y lo pienso más por lo que veremos más adelante. Si que es cierto que los dos picos se ven mucho menos toscos que con la malla de 3 segundos.

Entonces, si Ortho4xp usa las mallas de de Ferranti... cómo quedará el Pedraforca?

Aquí tenemos una prueba con unas fotos a ZL14 para ir rápido.
He puesto el valor Curv_tol a 3, que es el valor por defecto. Es decir, se trata de una tolerancia de curva alta. Conseguimos con ello 3.000.000 de triángulos

(https://s25.postimg.org/qzi2qfehr/con_ortos_ZL14.jpg)

Pues no queda nada-nada mal... muchísimo mejor que con el mesh por defecto de X-plane. Claro, queda igualito que el de AlpilotX, al utilizar los mismos datos altimétricos (o sea, los de de Ferranti)


Pero... podríamos mejorarlo?

Y si bajamos el valor de Curv_tol a 1?
Con ello, al ser menos tolerante, utiliza más triángulos para renderizar la malla.
Vale, ponemos Curv_tol a 1, volvemos a renderizar, Ortho4xp nos dice ahora que ha usado 7.000.000 de triángulos !!

(https://s25.postimg.org/b3t8n4nxb/ortosZL14_y_curv_tol_1.jpg)


Pues qué queréis que os diga.... más del doble de triángulos y yo no veo gran diferencia, por no decir ninguna...

Entonces... y si lo que hacemos es usar la malla de de Ferranti de 1 segundo?

Ya vamos a por todas, y ponemos directamente un Curv_tol de 1, a ver todo lo que da....


(https://s25.postimg.org/njpygvh9b/ortos_ZL14_curv_tol_1_y_mesh_de_1_segundo.jpg)

Impresionante... la mejora sí que se ve claramente.
Eso me hace pensar que quizás los mesh de 1 segundo de de Ferranti sean \"auténticos\" (o sea, nada de interpolaciones)
Ortho4xp nos reporta 10.000.000 de triángulos. Queda por ver si con un Curv_tol de 3 no nos habría quedado igual de bien, pero con menos triángulos.

La pena es que las mallas de de Ferranti de 1 segundo son pocas (pirineos, Alpes, Escandinavia y poco más) pero la diferencia vale la pena en esas zonas. En zonas más planas, seguramente no vendrá de aquí. De hecho, el Pedraforca queda muy bien representado ya con la malla de 3 segundos, y eso que es una montaña exigente, como ya he dicho.

Visto lo visto, queda además claro que la malla de 3 segundos de de Ferranti NO es una interpolación de la malla por defecto de X-plane, sino que es \"auténtica\", igual de auténtica que la de 1 segundo, pues la diferencia entre ambas (la de 3 y la de 1 s) no creo que se consiga simplemente interpolando.

CONCLUSION: Con Ortho4xp se pueden hacer escenarios muy buenos, muy superiores a los escenarios por defecto de X-plane, por lo que se trata de un muy buen programa que encima es freeware, y ante el que me descubro cuando lo veo trabajar bajando mallas, descomprimiendolas, allanándolas, bajandose datos de OSM, fotos de Bing, creando 1000 archivos de trabajo intermedios que luego borra, informándote de todo lo que está haciendo en cada momento... Te quedas a cuadros cuando ves todo lo que hace.... en Phyton !!


Tenemos auténticos genios en el mundo de X-plane !!

...y ahora, ya sé que las comparaciones son odiosas, pero aquí tenemos el Pedraforca de SpainUHD:

(https://s25.postimg.org/kxafzxq1r/spainUHD.jpg)

Albert, das rabia y todo  :) !!

Vaya... 10.000.000 de triángulos (¿o vertices?)

Sea como sea se pone en entredicho la eficiencia de las mallas generadas en Ortho4XP, esto es una burrada de malla y poco aprovechada por lo que se ve en las capturas.

Ninguna celda de SpainUHD pasa de los 4.500.000 de vértices, de sobras para aprovechar los datos de 25 metros. Parece que Meshtool es mas eficiente calculando la tolerancia de curva incluso forzando la triangulización de perímetros (como aeropuertos) mediante shapefiles con densificación de nodos.

yo tengo tiles por zonas de los alpes con 10.000.000 de polígonos.
no he notado bajada de rendimiento en estos casos,pero si es cierto que acto seguido he rehecho la malla por prudencia

Es una exageración, las mallas UHD de AlpilotX llegan a los 5.000.000 de vértices y ya advierte de la posible inestabilidad. Claro que YMMV -> buscad en google  ;D
Antes de la llegada a los 64 bits, sobrepasar los 2000000 de vértices era muy arriesgado (y ahogaba la CPU por completo). A mi me explotó una fuente de alimentación por eso, literalmente.

el vuelo virtual también tiene sus peligros ???

el problema no son esos 10 milloncejos de nada,lo que me preocupa es cuantos suman si el simulador tiene que cargar varios tiles a la vez(no estoy seguro todavía de que carga exactamente el sim al inicio),asi que procuro mantenerme en 6-7 millones por tile.

no he tenido un CTD hasta ahora,pero no quiero tentar a la suerte,vayamos a salir ardiendo o algo :-av3

En XP11 (y XP10 con DSF extended) se cargan 4x3 celdas, en XP10 sin esa opción eran 3x2, la mitad.

pero no me salen las cuentas,pues cada celda(perdón por lo de tile,yo también caigo en el spanglish ::))pesa pongamos que 5gb,total 60 gb,y no paso de 10 g de ram y 4 vram.

es decir,hay cosas que entran a ram y otras que no,asi que no se muy bien cuando esos millones de polígonos empiezan a consumir recursos de verdad.

por cierto,en esas 12 celdas,como haya UNA de las ortofotos corruptas el sim peta,o sea que es como si revisara todos y cada uno de los dds

Lo cuentas en bruto y eso no es válido. Las texturas en formato DXT utilizan mipmaps que no son mas que versiones reducidas a una cuarta parte de la anterior hasta 12 niveles, y eso es lo que se carga en memoria gráfica de forma dinámica. A unos 200 metros a la redonda se cargan las texturas a una cuarta parte de su resolución, mas lejos a una octava parte, y así sucesivamente hasta 12 niveles (suponiendo que las texturas sean 2k, con texturas 4k se puede llegar a 13 niveles de mipmaps siempre que se codifiquen), aunque el ángulo de visionado también influye. Así que con 12 celdas a z17 no deberías pasar los 8GB de VRAM. Sin embargo los vértices están codificados en binario, que es mucho mas eficiente que en modo texto. No se el cálculo exacto pero cada vértice no ocupa demasiado en RAM, sólo tienes que mirar el peso de cada DSF descomprimido para hacerte una idea de lo que entra en memoria. Pero el problema de eso no reside en la capacidad de almacenamiento, si no en la potencia de proceso, cuantos más vértices mas ciclos de CPU se requieren, tu al igual no lo notes (no recuerdo exactamente tu equipo, pero me suena que era un pepino), pero puede que yo con mi viejuno i7 920 C1 a 3,8GHz (OC) si que lo note, puedo mover SpainUHD con sus cuatro millones de vértices multiplicado por 12 con todo menos sombras al máximo a 50fps estables sobre Barna o Madrid, con todo el autogen. Pero si hablamos de un número de vértices 3 veces superior en cada celda me salen unos 144.000.000 de vértices y me puedo hacer una idea de como lo movería (como la vez que se me ocurrió convertir una de las islas Culumbretes de Lidar a objeto (.obj) de X-Plane con propiedades hard y sólo tres millones de vértices... si llegaba a 10 fps ya era demasiado).

asi que ese es el truco....

gracias,aprecio mucho las molestias que te tomas para explicar las cosas.

cierto es que no aprecio mucha variación en la carga de trabajo con mallas complejas,pero viendo los resultados en las capturas,esta claro que a partir de un punto no merece la pena destinar recursos a las mallas,sean cuantos sean,nunca sobran.

también he visto zonas con resultados muy antinaturales,canta mucho o la interpolación o lo que sea porque hay resaltes y hendiduras muy abruptas que no casan con la ortofoto,en esos casos se evita suavizando la curvatura,asi que matas dos pajaros de un tiro

No existen datos perfectos, sea cual sea la fuente.

Acabo de hacer otra prueba, mientras arreglaba la cocina y fregaba los platos.... he dejado Ortho4xp renderizando bajo unos nuevos parámetros.

Concretamente, utilizando los datos de elevación de 1 segundo de arco de de Ferranti, combinado con un Curv_tol de 3, y no de 1. Ya había comentado en el anterior post que habria que ver cuántos triángulos (hablo de triángulos, no de vértices, eso es lo que reporta Ortho4xp. También los vértices, pero yo me he fijado en los triángulos) saldrían si, en vez de utilizar un Curv_tol de 1, usábamos un Curv_tol de 3... Se vería peor? Se vería igual con un número de triángulos mucho menor?

He aquí el resultado:
El Pedraforca con el mesh de 1 segundo y Curv_tol=3

(https://s25.postimg.org/aje7kfuov/curv_tol_3_y_mesh_1s.jpg)


He comparado las dos imágenes hechas con el mesh de 1 segundo, una con Curv_tol=1 (vedla en el anterior post) y ésta, con Curv_tol=3 y no veo diferencias.
¿Seguro que no hay diferencias? Pues SI que las hay, pero no en el aspecto: 10.000.000 de triángulos contra 4.700.000 si usas Curv_tol=3

Por lo tanto, la conclusión  es que Curv_tol debe ser igual a 3.
Un valor inferior crea más triángulos... pero irrelevantes en la práctica (excepto para ocupar memoria)

Seguimos avanzando....

impecable demostración empírica,como dios manda ;D

ahora vamos a dejar que los datos de elevación de 1 segundo proliferen...

puesto que es sencillísimo rehacer las mallas de las celdas que ya tenemos 8)

Aún despierto?
También friegas los platos de madrugada?

Insomne irredento.
Lo mío solo es vicio :D