Source: http://www.x-plane.es/foro/index.php?topic=7534.75
Timestamp: 2020-01-17 18:24:43+00:00

Document:
Autor Tema: Tenerife VFR 1.36 (disponible) (Leído 74087 veces)
24 Febrero, 2015, 11:58:28 #75
Re: Tenerife VFR 1.1 y Tenerife VFR simple 1.0 (disponibles)
Tú lo has dicho, "en teoría"
Lo averigüé cuando empecé a hacer capturas de Canarias SHD Photo z17 y me alejaba del avión (vista MAYÚSC+4)... se veía muuuy suavizado y a baja resolución (a parte de que no aparecían los objetos). Para solucionarlo, me tenía que traer el avión (en la vista mapa) cerca de donde ponía la cámara para que se definieran las texturas y poder hacer la captura.
« Última modificación: 26 Febrero, 2015, 21:40:09 por Cestomano »
24 Febrero, 2015, 13:37:44 #76
Pues esto me suena a fallo del motor gráfico, ya sea intencionado o no...
¿Que sentido tiene que los DDS de los pol almacenen los mipmaps? Si en este caso (.pol) siempre se renderiza a su máxima resolución, aunque el único beneficio que veo yo en quitarle los mips sería en una reducción del peso de las texturas en un 30% aprox, pero no el uso de VRAM puesto que parece ser que siempre carga el primer nivel.
24 Febrero, 2015, 14:42:52 #77
Es posible que la v1.1 haga bajar lls frames, más que la v1?, hoy hice unos circuitos en GCXO y me bajó los frames, comparado a la versión anterior. Hablo de ir a 30 fijos a bajones de 22.
24 Febrero, 2015, 15:25:03 #78
Cita de: grrr05 en 24 Febrero, 2015, 13:37:44
Raro desde luego que es... y sin sentido. Se podría poner un Bug en x-plane.com.
Pasa lo mismo con las playas. Te pongas a la distancia que te pongas siempre se verán a la máxima resolución.
Cita de: evaristo2005 en 24 Febrero, 2015, 14:42:52
Lo veo muuuy poco probable. Los cambios son mínimos; yo no he notado ningún bajón.
¿No será por tener debajo Canarias SHD Photo? Prueba a eliminar (renombrar o mover a otra carpeta) los archivos +28-027.dsf y +27-027.dsf de Canarias SHD Photo pues no los necesitas a ver qué tal.
(eso sí, teniendo instalado tb. Canarias SuperHD 3.0 para que pille la malla buena).
24 Febrero, 2015, 16:15:36 #79
Me corrijo a mi mismo, eliminar los mipmaps significa ahorrar en VRAM puesto que se cargan todos los niveles siempre.
De todas maneras supongo que tendría un impacto directo en los FPS, pues el uso de mipmaps permite un renderizado mas rápido además de evitar "artefactos" en las texturas lejanas con lo cual su uso es positivo por esas dos razones.
Cuando llegue del curro lo voy a enviar como bug que ya tengo unas capturas preparadas.
Enviado el bug.
También he podido comprobar que no sólo pasa en los .pol y .bch, si no en todos los recursos que no sean TER.
« Última modificación: 24 Febrero, 2015, 20:17:52 por grrr05 »
26 Febrero, 2015, 16:19:25 #80
Cestomano, has sido elegido para ser nombrado y poner una foto de tu Tenerife v1.1, en la zona del auditorio con una c207 de alabeo en la revista. Ya te avisaré.
26 Febrero, 2015, 21:39:51 #81
Cita de: evaristo2005 en 26 Febrero, 2015, 16:19:25
Peeero... no tengo dicho avión...
Cita de: grrr05 en 24 Febrero, 2015, 16:15:36
Mucho me temo que te responderán que no es un bug (como mucho, una falta de optimización).
Pensando yo, los TER definen celdas enteras 1x1, las cuales excluyen cualquier otro escenario de la misma celda que esté en la misma región. Calcular en ese caso qué texturas cargar a máxima resolución y cuáles a menos (mipmaps menores) es "relativamente" sencillo.
Ahora bien, el resto de cosas (pols, beaches, etc.) puede ser un batiburrillo insufrible. Pols grande, pequeños, unos encima de otros, unos excluyendo a otros y otros que se mezclan... quizá, calcular de estos (los cuales pueden estar en mil archivos DSF de nuestro custom scenery) la resolución (mipmap) a utilizar en función de la posición del avión sea bastante más complicado.
(o quizá no)
27 Febrero, 2015, 13:23:42 #82
Cita de: Cestomano en 26 Febrero, 2015, 21:39:51
De momento no me han contestado (en realidad planteé mas el bug como una pregunta).
Yo no creo que el cálculo debería ser tan complicado, pues los niveles de mipmaps en cualquier textura se deben cargar en función de la ubicación de la camara (al igual que el filtrado anisotrópico se va calculando según el ángulo de visionado de la textura, y éste SI que funciona en todo el renderizado en general, sea cual sea el recurso).
De todas maneras si nadie me responde al igual se lo envio directamente a Ben, pues parece ser (por ahora) que es mejor tratar nuestras texturas dds sin mipmaps para cualquier tipo de escenario que no sea tipo g2xpl, pues algo de VRAM deberemos ahorrar (alrededor de un 30% según mis cálculos). Por desgracia el X-Grinder no tiene la posibilidad de NO CREAR mipmaps, así que es necesario otro software como Gimp o PS y sus correspondientes plugins.
Hasta me atrevería a probar eliminando los mipmaps de los pol de Tenerife VFR a ver cuanto mejora el uso de VRAM (si es que soy capaz de automatizarlo jeje...) y si realmente sale a cuenta en términos de rendimiento.
27 Febrero, 2015, 13:44:36 #83
Ese es el problema. Reconvertir a DDS sin los mipmaps, en modo batch... no sé cómo. Los plugins batch que he probado para Gimp escriben a otro formatos pero no a DDS (para eso es necesario otro plugin independiente).
Encima, algunas texturas llevan canal alfa suavizado y otras de 1 bit (o sin alfa). Un jaleo...
Por cierto, según mis cálculos, en texturas DDS nos ahorraríamos un 25% si elimináramos los mipmaps.
(y un 25% es un 25%)
27 Febrero, 2015, 13:54:50 #84
Cita de: Cestomano en 27 Febrero, 2015, 13:44:36
25% suponiendo que sólo tuviera dos niveles (la textura original y el segundo nivel), ¡quedan 6 mas! cada uno reducido a un 25% del anterior, casi un 34% digo yo aunque ahora no estoy tan seguro ya que probé quitándole los 7 niveles de mipmaps a una textura DXT1 de 1024^2 y el tamaño del archivo pasó de 1.33mb a 1mb pelao, lo que indica una reducción del 25% sastamente... No se, al igual me estoy haciendo un lío
« Última modificación: 27 Febrero, 2015, 14:03:15 por grrr05 »
27 Febrero, 2015, 14:12:38 #85
Ah, yo hice la fórmula considerando varios niveles... Así: [modo matemático On]
Tamaño de una textura DDS de 8 niveles (T) = X + X/4 + X/16 + X/64 + X/256 + X/1024 + X/4096 + X/16384
(donde X es el tamaño del primer nivel. Considerándola cuadrada, cada subnivel será 1/4 del anterior)
T = (1 + 0,25 + 0,0625 + 0,015625 + 0,00390625 + 0,0009765625 + 0,000244140625 + 0,00006103515625) * X = 1,3333129883 * X
Regla de tres: Si de T (tamaño total) X es el tamaño del primer nivel, entonces de 100 ¿cuál será el tamaño del primer nivel en porcentaje (%X)?
%X = 100*X / T = 100*X / (1,3333129883*X) = 100 / 1,3333129883 = 75,001144425587532544401900206105
Redondeando, %X = 75%; luego, la ocupación del resto de mipmaps debería ser el 25% del tamaño total.
En tu ejemplo, lo dejas claro, de 1,3 Mb queda 1 Mb (que es el 75% del total)
[modo matemático Off]
mmmm, creo que ambos estábamos hablando de lo mismo pero desde puntos de vista diferentes,
27 Febrero, 2015, 16:19:25 #86
Vale yo hacia la suma de los 7 subniveles y este me daba el porcentaje de X
(X/4 + X/16 + X/64 + X/256 + X/1024 + X/4096 + X/16384) * 100 = 33,33129883% de X
Ida de olla por hacer el cálculo sobre X y no sobre T, pues el 33% de reducción es en base al primer nivel de la textura y no a la suma de todos, he aquí mi fallo. 33%X = 25%T
Mal planteamiento... me recuerda a http://elmonomudo.com/2009/04/27/fallan-las-matematicas/
« Última modificación: 27 Febrero, 2015, 16:45:20 por grrr05 »
27 Febrero, 2015, 19:45:27 #87
Ok respuesta de Ben:
the GPU will use the highest mipmap again because you are zoomed (refiriéndose a las capturas que le adjunté) - the selected mipmap changes based on the zoom
Es decir que funcionan y se basan en el zoom, no en la distancia real de las texturas. Nada, mejor dejarlo todo como estaba
27 Febrero, 2015, 21:20:24 #88
Jaja, sí, me acuerdo del problema y como tuve q explicar su resolución
Pues no entiendo lo del zoom. Por q no tratan las texturas x igual?
28 Febrero, 2015, 10:33:42 #89
Cita de: Cestomano en 27 Febrero, 2015, 21:20:24
Únicamente las que cuentan con el atributo LOAD_CENTER, que son los escenarios fotorrealistas de g2xpl. Fíjate que en las mallas por defecto (o las de Alpilotx) las texturas se renderizan igual que cualquier otro recurso.
This command estabishes that this texture will be used at a certain location, specified by the lat/lon taken to be the texture's center. By also specifying the textures size (in pixels) and approximate terrain size when placed (in meters), X-Plane will load the texture with variable resolution based on the general distance from the user to the texture. As the user flies, X-plane will periodically reload the texture.
Quizás sea una de las razones por la que en muchos casos los fotorrealísticos sueltan mas FPS que los escenarios por defecto a pesar de usar mas VRAM...
Se pueden cambiar las propiedades de los .pol mediante dicho atributo
El .pol de la izquierda contiene el atributo LOAD_CENTER y el de la derecha está tal cual, en la izquierda como es obvio está la textura cargada con poca resolución y la de la derecha con el primer nivel de mipmap debido al zoom. La captura está tomada a unos 50km de distancia.
Este atributo sólo debe usarse para recursos únicos (cómo ortofotos), pues la textura se carga una única vez y sobre la marcha, según la distancia del avión. Por esto es necesario especificar las coordenadas del centro de la textura, la anchura en metros y el número de pixels de lado. No hace falta que sean exactos del todo aunque son necesarios para que X-Plane calcule la resolución a la que se debe renderizar según la distancia del avión (no de la cámara).
Por desgracia los cálculos de los parámetros se deben hacer previamente porque modificar todos los .pol existentes de un escenario puede ser una autentica pesadilla, aunque ya digo que no tienen porqué ser exactos del todo (en el .pol de la captura los he puesto a ojímetro y funciona perfecto estando justo encima del polígono como a 50km, los niveles de resolución me parecen correctos).
« Última modificación: 28 Febrero, 2015, 11:30:56 por grrr05 »

References: resolución 
 resolución 
 resolución 
 resolución

 resolución 
 resolución 
 resolución