sikorsky77 a écrit:Salut Jacques
j'ai vu que tu as fait un dessin style SID , comment calcules-tu le pixel de départ du second leg, puis du troisième, etc..
si on fixe la rosace du ND sur le cap de l'avion avec ta bibliothèque , le premier leg sur le cap de l'avion ne nécessite qu'un calcul de longueur en ratio distance/pixel , puis arrive le deuxième leg qui va disons virer sur la droite de 30 ° sur une certaine distance , au fur et a mesure que l'on s'approche de la fin du leg 1, on va avoir très certainement la nouvelle vision du Leg 3 qui vire à gauche de 130° , la ça devient compliqué de déplacer chaque segment, et je ne parle pas de l'actualisation de l'ensemble des legs pendant le virage qui plus est si on jour avec le range du ND
Je pensais à une autre idée en partant de ce que tu as déjà fait ce qui est déjà beaucoup
en partant de ta méthode , si on arrive à créer avec tes primitives, en lisant le PDV au départ du vol,
A) soit une image.png du PDV complet dans une taille 10 ou 20 fois supérieure à la fenêtre ND de l'Aspen qui permet de
1. pouvoir zoomer le PDV sur différents range
2. de déplacer l'image par rapport au deplacement de l'avion sur le PDV et faire une rotation de l'image en fonction du changement de cap de l'avion dans la fenêtre de l'Aspen
B) soit par exemple de créer 10 fichiers images qui correspondent à 10 range de l'Aspen pour éviter en simultanée les calculs de gestion de l'image et du zoom
restera un souci , le changement de PDV en cours de vol (exemple, un changement de piste à l'arrivée nécessitant une nouvelle STAR qui oblige à la re-fabrication d'une (ou de nouvelle(s) image(s)) en cours de vol
Toi le spécialiste du dessin et des fonctions associées , serait-ce une idée à creuser ?
Thierry
PS : suite à ma remarque sur un changement de PDV il me vient une idée, on peut imaginer trois images pour le PDV (ou 30 suivant la méthode) qui donneraient la possibilité de les recréer indépendamment
une image SID jusqu'au dernier point de la SID
Salut Thierry
Si j'ai bien compris, tu suggères de dessiner le plan de vol en entier comme une seule image qu'on ferait tourner/bouger ensuite suivant le cap de l'avion.
C'est une très bonne idée, mais malheureusement ce n'est pas le fonctionnement de la librairie.
Je ne crée pas de fichier png, c'est uniquement du pseudo-vectoriel.
Je dessine une ligne à l'exécution en "étirant" une image colorée d'un pixel seulement selon la longueur/épaisseur voulue, puis en faisant tourner cette image étirée selon l'angle nécessaire, enfin en translatant l'image à ses coordonnées définitives.
Les arcs, cercles sont ensuite entièrement construits à partir de lignes, avec des calculs trigo simples.
L'image d'un PDV que tu as vue est juste un assemblage statique de lignes, d'arcs et de cercles. Mais tu as raison l'idée à la base est bien d'afficher si c'est possible un PDV sur un ND.
Pour ce faire plusieurs étapes, à mon avis:
1- convertir des position GPS en Lat/Lon récupérées via Simconnect en coordonnées x,y en pixels pour pouvoir les afficher sur la Moving Map.
2- créer l'intégralité du PDV en mémoire en lisant l'ensemble du PDV jusqu'au segment final et en stockant toutes les coordonnées dans un grand tableau d'une centaines de points. On associe ensuite à chaque coordonnée GPS (couple Lat/Lon) un couple de coordonnées x,y
3- à partir de là, on pourra afficher le PDV en connectant les points entre eux par des lignes qu'on affichera sur le ND.
4- À chaque mouvement de l'avion, il faudra effacer toutes les lignes déjà dessinées, recalculer l'ensemble du tableau du PDV en mettant à jour les coordonnées x,y de chaque point GPS, puisque si Lat/Lon ne change pas, la position correspondante de chaque point sur la fenêtre de la jauge évolue. Cette mise à jour doit également tenir compte du nouveau cap, on fait tourner alors l'ensemble des points du PDV.
5- on peut ensuite réafficher le PDV dans son intégralité.
Pour un zoom, on recalcule là encore l'intégralité des coordonnées x,y de chaque point en multipliant celles ci d'un facteur de zoom, ce qui va avoir pour effet "d'éloigner" les coordonnées les unes des autres de manière proportionnelle, on redessine ensuite le PDV en connectant les points. Le zoom est automatique.
Je suis persuadé que c'est cette approche vectorielle qui est utilisée dans les vrais ND/GPS.
Si on jouait sur une image ( ce qui n'est pas possible en l'état d'Air Manager) les zooms augmenteraient en même temps la largeur des lignes, ce qui n'est pas souhaitable. L'approche vectorielle évite ce soucis.
Par contre il faut tout recalculer à chaque fois, et surtout dans notre cas c'est je pense le plus gros problème, comme on crée des ressources graphiques à chaque création de ligne, à un moment on va exploser la mémoire VRAM ou celle allouée à Java.
Je ne sais pas s'il existe un processus de récupération automatique des ressources graphiques inutilisées en Lua/C++, une sorte de "garbage collector" mais pour les images, j'en doute...
Tu vois, pas mal de boulot pour autant qu'on franchisse toutes les étapes, et j'en suis au point 1!
En réfléchissant à ton idée, il y aurait peut-être une autre possibilité: un programme externe à Air Manager qui créerait (selon les mêmes principes (vecteurs) une image en png (un peu selon le principe du Postcript, qui affiche une image à partir de vecteurs), image qui serait chargée comme ressource graphique par Air Manager. Mais cela implique un programme externe, une programmation en C/C++, et une librairie de fonctions Postcript ou équivalent adaptée.
Jacques