Ortho4XP

[Glah_Salamanthe]

Nvidia-texture-tool (nvtt) fonctionne indépendamment de la carte graphique,

Un très grand merci, me voilà rassuré .

[Mclnight]

une petite carte postale Ortho4XP =)

http://postimg.org/image/6jv3ibnj1/full/

[Glah_Salamanthe]

une petite carte postale Ortho4XP =)
http://postimg.org/image/6jv3ibnj1/full/

Joli ! … et … c'est où ? (pour les non-litoraliens)

[jet007]

Salut à tous,

Le meilleurs des souhaits que je puisse vous formuler est que tout vos vœux se réalisent.

Bonne continuation à Ortho4XP.

Vivement une application simplifiée pour les "windosiens"

Maurice

[Mclnight]

Joli ! … et … c'est où ? (pour les non-litoraliens)

Merci, c'est entre la grande-motte et l’étang de l'or, près de l’aéroport de Montpellier

[Oscar Pilote]

@jasum

Dans le code source d'imagemagick on trouve la partie ci-dessous, je suis à peu près certain que la différence
de codage entre convert et nvcompress se trouve là.
Pourrais tu essayer de recompiler imagemagick en faisant en sorte que ce soit toujours
la 1ère alternative qui soit prise en compte (e.g. en remplaçant "ignoreAlpha... c0>c1" par "1==1") ? (ou peut-être la deuxième...)
Je testerai sinon à mon retour le 3 janvier.

http://git.imagemagick.org/repos/ImageMagick/blob/master/coders/dds.c

 if (ignoreAlpha != MagickFalse || c0 > c1)
    {
      c->r[2] = (unsigned char) ((2 * c->r[0] + c->r[1]) / 3);
      c->g[2] = (unsigned char) ((2 * c->g[0] + c->g[1]) / 3);
      c->b[2] = (unsigned char) ((2 * c->b[0] + c->b[1]) / 3);

      c->r[3] = (unsigned char) ((c->r[0] + 2 * c->r[1]) / 3);
      c->g[3] = (unsigned char) ((c->g[0] + 2 * c->g[1]) / 3);
      c->b[3] = (unsigned char) ((c->b[0] + 2 * c->b[1]) / 3);
    }
  else
    {
      c->r[2] = (unsigned char) ((c->r[0] + c->r[1]) / 2);
      c->g[2] = (unsigned char) ((c->g[0] + c->g[1]) / 2);
      c->b[2] = (unsigned char) ((c->b[0] + c->b[1]) / 2);

      c->r[3] = c->g[3] = c->b[3] = 0;
      c->a[3] = 255;
    }

[jasum]

OK Je vais essayer cela.

[Glah_Salamanthe]

Vivement une application simplifiée pour les "windosiens"

ça ne doit pas être beaucoup plus compliqué que pour les "Mac-eux" !
En suivant correctement le mode d'emploi, c'est (il me semble) à la portée du premier venu !

[LEBUITRE]

Bonjour Oscar.
Je viens d’essayer d’utiliser ta dernière fonction Build Overlay.
Cela marche parfaitement sur mon Mac, et j’ai fabriqué 25 Overlays en un temps record.
Toutes les fonctions de ton superbe programme marchent parfaitement sur Mac et je félicite encore pour ce travail exceptionnel.


Après avoir tout compris quant à l’utilisation de ton programme, j’ai fait un bilan pour mon utilisation personnelle .
J’ai réalisé des tuiles 16-18 et quelques tuiles 16-19 avec utilisation des Masques pour les bordures d’océan.


J’ai constaté que l’utilisation des zones de zoom 18 ou 19 étaient inutiles si l’on utilise une résolution extrême.
En voici un exemple (voir images jointes), sur une zone tampon d’une tuile réalisée en zoom 16 avec une zone en zoom 19 autour de l’aéroport de Toulouse.
La netteté de l’image en zoom 16 très floue en résolution minimale, s’améliore au fur et à mesure que l’on augmente la résolution, pour aboutir à une image identique entre les zones 16 et 19 en résolution extrême.


Remarque : J’ai constaté que dans X-Plane 10, la prise en compte de la résolution est immédiate sans relancer Plane, et le message « changes take effect on re-start » est obsolète.


Donc dorénavant, je ne construis plus que des tuiles en Zoom 16 (très rapides à construire), et je choisis un réglage « extreme res! »
Par ailleurs en bordure de mer, j’ai constaté que l’utilisation des masques n’est pas toujours souhaitable. C’est le cas de la tuile +43+007 autour de LFMN qui est meilleure chez moi sans les masques.


Enfin après avoir testé les overlays avec utilisation de « number of roads »et de « number of cars », j’ai constaté que cela ralentissait énormément X-Plane, et je préfère voir la véritable image des routes plutôt que le tracé superposé d’Xplane avec des voitures en mouvement et des trains.
Pour moi,je considère ces fonctions d’Xplane ainsi que l’apparition de biches comme des gadgets sans intérêt.


Cependant je conçois que toutes ces fonctions prévue par Austin plaisent à certain et je trouve que tu as là encore parfaitement réalisé la programmation de Build Overlay.


Voici donc mes réflexions personnelles qui n’engagent que moi qui pratique essentiellement avec bonheur des vols IFR sous IVAO avec le fabuleux B777 de Rammzess, mais qui utilise aussi avec bonheur tes tuiles pour faire des vols en hélicoptère notamment dans les Alpes Suisses où se situera le futur Raid Cavok de Milan.


Encore un très grand merci pour tout, mon cher Oscar et très bonnes fêtes de fin d’année pour toi et les tiens.
Lebuitre.

http://img15.hostingpics.net/pics/801728Ortho4XP01.jpg

http://img15.hostingpics.net/pics/196534Ortho4XP02.jpg

http://img15.hostingpics.net/pics/506642Ortho4XP03.jpg

http://img15.hostingpics.net/pics/949566Ortho4XP04.jpg

http://img15.hostingpics.net/pics/515217Ortho4XP05.jpg

http://img15.hostingpics.net/pics/493809Ortho4XP06.jpg

[milan]

Merci Lebuitre pour cette démonstration très parlante

En revanche je préfère utiliser les overlay entre autres pour les lignes électriques ; mais je recommande, dans les options graphique Nb de routes :default et Nb de voitures : Banlieue de Chicago afin, justement, de ne pas trop "salir" les orthos



Hum j'en profite pour signaler une version V4 du mode d'emploi au format pdf (y compris les overlay)
voir ma signature

Un entrelacs dans les Alpes suisses

[Oscar Pilote]

Merci Lebuitre, le biais des fils de forums est de rassembler avant tout les messages
de personnes rencontrant des difficultés, et c'est bien normal, alors je ne boude pas mon plaisir à te lire !

Je prolonge la réflexion à certaines de tes remarques :

J’ai constaté que l’utilisation des zones de zoom 18 ou 19 étaient inutiles si l’on utilise une résolution extrême.

En vol très rapproché cela fait une différence, mais bien sûr celle-ci n'a plus lieu d'être dès qu'on s'éloigne un
peu du point visé. J'ai lu beaucoup de choses fausses concernant les différences de ZL et des "texture resolution"
(notamment que ZL17 + très haut = ZL16 + extreme) alors voici un petit exemple qui
j'espère sera éclairant :

Imaginons un triangle dont l'affichage sans besoin de zoom (étant donné la résolution de l'écran) nécessite au minimum
du ZL16 lorsque la distance avion-triangle est de 1 unité.

Si on dispose d'une tuile ZL16 avec le choix texture res=extreme voici le choix de vignettes que X-Plane fera
lorsque la distance avion-triangle variera :

d=1 -> ZL16
d=2 -> ZL15
d=4 -> ZL14
etc
d=1/2 -> ZL16 zoomé 2x
d=1/4 -> ZL16 zoomé 4x
etc

Voici avec une tuile ZL17 et texture res = extreme

d=1 -> ZL16
d=2 -> ZL15
d=4 -> ZL14
etc
d=1/2 -> ZL17
d=1/4 -> ZL17 zoomé 2x
etc

Maitenant une tuile ZL17 et texture res = très haut

d=1 -> ZL15 zoomé 2x (= 1 cran de moins que l'optimal, comparer avec la tuile ZL16 à extreme!)
d=2 -> ZL14 zoomé 2x
d=4 -> ZL13 zoomé 2x
etc
d=1/2 -> ZL16 zoomé 2x
d=1/4 -> ZL17 zoomé 2x

De manière générale la règle est : pour chaque triangle on calcule la résolution la moins haute permettant
l'affichage "sans perte" de la texture. On ôte ensuite à ce niveau de résolution autant d'unités que ce qui
est indiqué par "texture res" (avec extreme = on n'ôte rien, et ensuite 1 niveau de ZL par cran de moins).
Finalement, si la résolution obtenue est disponible dans le dds on l'affiche ainsi, si non on zoome la résolution
la plus haute du dds autant de fois que nécessaire.

Pour revenir à la comparaison ZL17/très haut vs ZL16/extreme, il suit de ce qui précède que la seconde solution
(ZL16 + extreme) donne toujours un rendu visuel au moins égal (pour le champ proche c'est kifkik, mais pour le champ loin
c'est mieux), mais entraine aussi une consommation de VRAM supérieure (chacun peut le constater facilement!)

Remarque : J’ai constaté que dans X-Plane 10, la prise en compte de la résolution est immédiate sans relancer Plane, et le message « changes take effect on re-start » est obsolète.

C'est à moitié vrai. En fait elle va être prise en compte petit à petit au fur et à mesure où il devra recharger des versions différentes
des vignettes lorsqu'on s'approche ou s'éloigne de celles-ci (ce que j'explique juste ici au dessus). Au passage cela explique
aussi une remarque de Mclnight il y a un certain temps disant que commencer en texture res=très haut puis passer en extreme aurait
permis d'avoir droit à de l'extreme sans la VRAM nécessaire... oui mais pour un petit moment seulement, si tu navigues sur toute ta
tuile tu verras la VRAM augmenter jusqu'à un niveau normal de res=extreme.
Un petit test facile pour zieuter la manière dont X-Plane recharge les textures au fur et à mesure est de changer le gamma en cours
de vol dans les options graphiques : en volant ensuite on voit les carrés changer su****ment de luminosité alors qu'on s'en approche ou s'en éloigne.

Donc dorénavant, je ne construis plus que des tuiles en Zoom 16 (très rapides à construire), et je choisis un réglage « extreme res! »

J'avais espéré et peut-être même parié que pour 2016 la majorité d'entre vous reviendrait à cette formule, je suis heureux de lire
que tu as pris de l'avance. A cette résolution, les textures sont suffisamment floues à basse altitude pour que les objets s'y intègrent
sans que cela fasse trop disparate. Et c'est Pascal qui va être content aussi ;-)

Enfin après avoir testé les overlays avec utilisation de « number of roads »et de « number of cars », j’ai constaté que cela ralentissait énormément X-Plane, et je préfère voir la véritable image des routes plutôt que le tracé superposé d’Xplane avec des voitures en mouvement et des trains.
Pour moi,je considère ces fonctions d’Xplane ainsi que l’apparition de biches comme des gadgets sans intérêt.

Je trouve aussi que les routes sont difficiles à intégrer. Le seul intérêt que j'y vois ce sont les lumières qui les suivent lorsque la luminosité
baisse. J'ai dans la tête de les introduire moi-même, sans passer par les routes à sniffer, histoire d'avoir les lampadaires et rien d'autre (cela
ne devrait pas être plus lourd que les arbres, soit très peu lourd). Les voitures en plus cela est apprécié par beaucoup mais je ne peux les intégrer comme des objets et aussi c'est très nuisible aux fps. Les biches on est tous d'accord je crois... Par contre les montgolfières
je dois dire que j'ai un petit faible...

dans les Alpes Suisses où se situera le futur Raid Cavok de Milan.

J'espère pouvoir y participer (et y partager mes tuiles), mais même si je me suis mis à voler j'ai encore
du mal à me poser en hélico !

Très bonne fin d'année à toi aussi

[Mclnight]

Salut Oscar
Je viens de lire avec intérêt ton explication du fonctionnement résolution de textures et orthophoto. Toujours aussi technique 😊
En ce qui concerne l'astuce que j'avais proposé, je démarre x-plane en textures très haute, puis je vais dans option pour passer à extrême le changement est instantané pour les Orthophoto sans que j'aie à me déplacer, je peux même constater l'augmentation de la vram de + 100 à +200 Mo, après je garde la même utilisation vram, même en parcourant la tuile vu que les textures de l'avion, des autogen, nuage... Restent en textures très hautes (changement effectif seulement après redémarrerage de x-plane) , c'est ça en fait l'intérêt de mon astuce et je peux dire qu'avec un gtx570 1giga j'arrive à avoir un très bon rendu.

[wyperion]

En ce qui concerne les z18 ou z17, je les "pose" uniquement autour des aéroports. C'est vrai que quand on est en haute altitude, cela a beaucoup,moins d'intérêt. Une exception cependant: en hélicoptère, c'est un régal de voler à 50 m du sol en z18. Surtout dans une zone qu'on connaît bien

[Odevillée]

@ Oscar,
Pourrais-tu me faire un patch pour LFBD, +44-001, c'est un vrai champ de patates (frites évidemment ), j'ai essayé mais n'y suis pas arrivé, ortho4xp bloque à l'étape1 quand il rencontre le patch.
Merci et mes meilleurs voeux.

[Daniel_L]

Plutot que d'utiliser une limite d'aérodrome qui vient d'OpenStreetMap, ce serait pas bien d'utiliser le Boundary du fichier apt.dat (130 Airport boundary header) s'il existe ?
Et puis une modification par WED est plus accessible qu'une dans les données OSM.

Daniel