cherche moyen de calculer un POS à partir de coordonnées

[pilote334]

Ouais, en fait on la position mais pas la dimension du batiment, en gros c'est ça. Je me suis pas penché sur la question...

[MrSpock]

Pire ! Tu as la position de la Base , des PADS , mais rien sur les MESHS !
Et impossible ( pour moi à présent ) de transformer les positions du VESSEL dans l'espace de la BASE ....
Il faut donc traduire le système de représentation de la BASE en tenant compte d'un hypothétique facteur d'échelle .
Voilà où j'en suis arrivé par déduction et expérience .



Message modifié ( 11-08-2010 16:34 )

[MrSpock]

Le problème , c'est que l'utilisation de DIRECTX est masquée .
Comme je connais assez bien son utilisation dans la version7 , voici mon raisonnement .
MARTIN utilise une interface IDIRECT3DRM .
Cette interface crée les pilotes d'affichage etc .
Ensuite , vient l'utilisation des frames .
L'Univers est le Frame Parent .
Chaque planète ou étoile est un frame enfant , positionné à partir de l'axe du parent . (0,0,0)
Chaque frame enfant (Terre...) peut-être le parent d'un autre frame ( Lune...) , positionné par rapport à son parent direct , lui même dépendant de son parent .
Dans directX , il existe des frames , mais aussi des meshs , considérés et appellés des Visuals ...
Ceux-ci sont placés  dans la scene , et on peut se passer d'avoir une référence sur ces objets s'ils sont statiques et si l'on ne prévoit pas de détection de collision .
Ce sont les objets placés dans les fichiers base.cfg ( à part les pad visiblement ... ) .
Disposer d'un pointeur sur un frame parent , c'est avoir le controle sur tous les descendants et leurs visuals .
Mais Martin a choisi de "cacher" cette interface afin de ne pas risquer une mauvaise utilisation .
Il nous a fournit des méthodes publiques pour manipuler " à distance " ces interfaces " privées " .
Les positions que nous obtenons via les fonctions du SDK ne sont pas les données Cartésiennes des frames , mais leur représentation géographique , calculée par le moteur PHYSIQUE d'Orbiter . La difficulté pour moi est donc d'interpréter le résultat des calculs pour me représenter dans l'Espace Cartésien d'Origine .
Je crois que les bases sont définies dans cet espace , et que tous les autres procèdent de calculs géodésiques et astronomiques ...
Mais ( ya toujours un mais ...) je suis troublé par cette fonction :

Code: [Select]

oapiGlobalToLocal  ( OBJHANDLE  hObj,  
  const VECTOR3 *  glob,  
  VECTOR3 *  loc  
 )  
Maps a point from the global frame to a local object frame.
Je n'arrive toujours pas à l'utiliser dans le bon esprit ( celui de Martin ) .



Message modifié ( 11-08-2010 17:37 )

[tofitouf]

je ne sais pas si je vais réussir à clarifier tout cela.


Mais tentons tout de même.

le système de coordonnées d'orbiter est bien différent de celui de directX, il vaut mieux utiliser ce dernier pour garder la cohérence du moteur physique.

chaque objet peut donner grace à l'api ses coordonnées globales (oapiGetGlobalPos)

cette coordonées correspond à une position dans l'univers ou du moins dans le système actuel (système solaire par défaut). le point 0 0 O0 étant au centre du soleil et l'orientation suivant le plan ecliptique (plan de l'orbite terrestre)

Mais en gros on s'en fout la plupart du temps.

Il vaut mieux toujours travailler en coordonnées relative par rapports aux objets qui nous intéressent.  

La fonction ci dessus (oapiGlobalToLocal) qui n'existe que sous orbiter2010, oh joie. permet de faire toute les conversion possible.

chaque objet possède son propre système de coordonnées et il est possible de convertir chaque valeur d'un système à l'autre

une base par exemple est orientée de manière à ce que le Y soit perpendiculaire à la surface de la planète (à cet endroit). Quand Y est inférieur à Zero on est en dessous de la surface....

Pour les vaisseaux Z pointe vers le nez, Y le haut et X à tribord.
etc etc....

[MrSpock]

[Salut tofitouf !Merci pour ce temps de clarification .
Si j'ai éssayé de lever le voile à propos de DirectX , c'est pour m'expliquer le format d'écriture dans les fichiers .cfg définissant les bases .
As-tu déjà réussi à écrire PENDANT une session d'orbiter la position du Vessel qui a le focus ,
dans un fichier au format .cfg ? De telle sorte qu'en relançant Orbiter , tu puisses avoir un mesh à la place de ton ancienne
position de Vaisseau ? Théoriquement , c'est évident .
Pratiquement , c'est autre chose .

Mon but est d'arriver à rajouter dans un fichier .cfg des éléments de décor par le simple appui d'un bouton du MFD .
J'arrive à ouvrir et créer un fichier à partir du mfd .
Je sais afficher les données dans le mfd et les écrire dans le fichier .
MAIS JE NE SAIS PAS ENCORE ( AARRRGH) CONVERTIR LA POSITION DU VESSEL EXPRIMEE EN DEGRE , EN COORDONNEE
LOCALE DE LA BASE .

Je t'invite donc ( ) si tu as le temps , à te frotter à ce .... CHALLENGE !

Spoiler  :

Un petit pas pour l'Homme , un grand pas pour la communauté !

TCHUSSS !




Message modifié ( 12-08-2010 23:12 )

[cslevine]

pour le calcul des distances en tout cas,
cette page
http://www.abe.msstate.edu/~fto/calculator/converte.html
offre le bon algorythme !

A savoir qu'on obtient seulement une seule distance à vol d'oiseau, en mètres.
Mais... il suffit, si l'on veut séparer les coordonnées de distances en X et en Y (pour les POS y alt x )
d'utiliser 2 fois l'algorythme, avec successivement les valeurs de l'autre axe à "0".

j'ai testé avant hier la faisabilité, en essayant sur un mesh de femme de petite vie :
après plusieurs essais, j'avais finalement réussi à placer le mesh pas très loin de l'endroit où j'avais "garé" un DG3... mais sur le moment je n'étais pas très satisfait du manque de précision...

mais j'avais oublié que sur mon Paname, j'avais mis les décors à une échelle de 1.1 au lieu de 1 (cela parce que j'avais fait mes premiers essais en voulant me caler sur la tuile parisienne d'un addon sur "Velizy" d'un "François92". )

Ce qui veut dire que la faisabilité est sûrement la bonne !

[MrSpock]

Ce qui est génial , Claude Samuel , c'est que la pertinence de ta demande offre par la réponse qui lui revient ( effet boomerang !) une perpective aux applications multiples .
Je suis très enthousiasmé à l'idée que la communauté puisse travailler de CONCERT et réussir à faire reculer les limites du
possible ! Si tu arrives à fixer la bonne méthode , nous pourrions en faire un mini SDK en c++ .
Le fait de se balader dans l'Univers d'Orbiter , de se poser quelque part , d'appuyer sur un bouton ( Tiens , nous pourrions
inventer un nouveau Panel2D , genre BullDozer Terrasseur de L'espace ) et de créer Illico une base . Faire 100 m , et créer
un site de décollage . Quelques mètres plus loin , des panneaux solaire , etc ...
Ouais, je sais ... mais Panam , c'est ton quartier !

L'autre applicaton géniale c'est la possibilité de  détecter les batiments de la zone que nous survolons .
Et ton idée de balancer un son à proximité de l'étage de ton voisin ... devient soudain possible .
Que du bonheur , à portée de mains , rraaaah , je l'éffleure !
Cette page que tu cites N'OFFRES PAS l'algorithme , elle propose de calculer pour nous .
Nous voulons calculer nous mêmes dans notre code la position .
Je retiens ta méthode , et vais essayer de trouver la fonction ( en fait je la connais déjà mais je ne savais pas comment l'utiliser ) .

Spoiler  :

This function computes the great circle distance in Kilometers using the Haversine formula distance calculation.

If you want it in miles, change the average radius of Earth to miles in the function.


create function dbo.F_GREAT_CIRCLE_DISTANCE
   (
   @Latitude1  float,
   @Longitude1 float,
   @Latitude2  float,
   @Longitude2 float
   )
returns float
as
/*
fUNCTION: F_GREAT_CIRCLE_DISTANCE

   Computes the Great Circle distance in kilometers
   between two points on the Earth using the
   Haversine formula distance calculation.

Input Parameters:
   @Longitude1 - Longitude in degrees of point 1
   @Latitude1  - Latitude  in degrees of point 1
   @Longitude2 - Longitude in degrees of point 2
   @Latitude2  - Latitude  in degrees of point 2

*/
begin
declare @radius float

declare @lon1  float
declare @lon2  float
declare @lat1  float
declare @lat2  float

declare @a float
declare @distance float

-- Sets average radius of Earth in Kilometers
set @radius = 6371.0E

-- Convert degrees to radians
set @lon1 = radians( @Longitude1 )
set @lon2 = radians( @Longitude2 )
set @lat1 = radians( @Latitude1 )
set @lat2 = radians( @Latitude2 )

set @a = sqrt(square(sin((@lat2-@lat1)/2.0E)) +
   (cos(@lat1) * cos(@lat2) * square(sin((@lon2-@lon1)/2.0E))) )

set @distance =
   @radius * ( 2.0E *asin(case when 1.0E < @a then 1.0E else @a end ))

return @distance

end

To be continued ...




Message modifié ( 12-08-2010 23:25 )

[MrSpock]

Bon .... Si on parlait marge d'erreur ?
En fait , la formule que tu as vraisemblablement utilisé ( si c'est celle que je décris plus haut), comporte une marge d'erreur de 2km si ton arc mesure la moitié de la circonférence terrestre .

Je viens de trouver ( enfin , c'est sorti du cerveau d'un autre hein ! )une méthode dont la précision est éffarante :0.5mm, or 0.000015″ (!), on the ellipsoid being used

Code: [Select]

/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  */
/* Vincenty Inverse Solution of Geodesics on the Ellipsoid (c) Chris Veness 2002-2010             */
/*                                                                                                */
/* from: Vincenty inverse formula - T Vincenty, "Direct and Inverse Solutions of Geodesics on the */
/*       Ellipsoid with application of nested equations", Survey Review, vol XXII no 176, 1975    */
/*       http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf                                             */
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  */

/**
 * Calculates geodetic distance between two points specified by latitude/longitude using
 * Vincenty inverse formula for ellipsoids
 *
 * @param   {Number} lat1, lon1: first point in decimal degrees
 * @param   {Number} lat2, lon2: second point in decimal degrees
 * @returns (Number} distance in metres between points
 */
function distVincenty(lat1, lon1, lat2, lon2) {
  var a = 6378137, b = 6356752.314245,  f = 1/298.257223563;  // WGS-84 ellipsoid params
  var L = (lon2-lon1).toRad();
  var U1 = Math.atan((1-f) * Math.tan(lat1.toRad()));
  var U2 = Math.atan((1-f) * Math.tan(lat2.toRad()));
  var sinU1 = Math.sin(U1), cosU1 = Math.cos(U1);
  var sinU2 = Math.sin(U2), cosU2 = Math.cos(U2);
 
  var lambda = L, lambdaP, iterLimit = 100;
  do {
    var sinLambda = Math.sin(lambda), cosLambda = Math.cos(lambda);
    var sinSigma = Math.sqrt((cosU2*sinLambda) * (cosU2*sinLambda) +
      (cosU1*sinU2-sinU1*cosU2*cosLambda) * (cosU1*sinU2-sinU1*cosU2*cosLambda));
    if (sinSigma==0) return 0;  // co-incident points
    var cosSigma = sinU1*sinU2 + cosU1*cosU2*cosLambda;
    var sigma = Math.atan2(sinSigma, cosSigma);
    var sinAlpha = cosU1 * cosU2 * sinLambda / sinSigma;
    var cosSqAlpha = 1 - sinAlpha*sinAlpha;
    var cos2SigmaM = cosSigma - 2*sinU1*sinU2/cosSqAlpha;
    if (isNaN(cos2SigmaM)) cos2SigmaM = 0;  // equatorial line: cosSqAlpha=0 (§6)
    var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha));
    lambdaP = lambda;
    lambda = L + (1-C) * f * sinAlpha *
      (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)));
  } while (Math.abs(lambda-lambdaP) > 1e-12 && --iterLimit>0);

  if (iterLimit==0) return NaN  // formula failed to converge ** Oh OH ? J'espère que cela n'arrive pas souvent....**

  var uSq = cosSqAlpha * (a*a - b*b) / (b*b);
  var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)));
  var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)));
  var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)-
    B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM)));
  var s = b*A*(sigma-deltaSigma);
 
  s = s.toFixed(3); // round to 1mm precision ** Oh les menteurs ! Ils avaient dit 0.5mm :) **
  return s;
}
Vous comprendrez mieux maintenant la raison de mon ... piétinement !

Spoiler  :

C'est à peine plus chaud qu'un SUDOKU ...
J'espère n'avoir jamais à debugger ce code !
Le plus drôle c'est qu'il y a quinze jours je disais à BiBI Uncle de ne jamais coller un code sans le comprendre ...
DAMNED !

Voici un lien vers la source de ce code :
Source



Message modifié ( 13-08-2010 00:37 )

[MrSpock]

Mais... il suffit, si l'on veut séparer les coordonnées de distances en X et en Y (pour les POS y alt x )
d'utiliser 2 fois l'algorythme, avec successivement les valeurs de l'autre axe à "0".

"...Prendre un enfant , par la main ...  "
La programmation ne tolère pas d'erreur d'interprétation .
Avant de coder ce que tu me dis , j'ai besoin d'être sûr de l'avoir bien compris .

avec successivement les valeurs de l'autre axe à "0"

Parlons le même langage : Nous avons par exemple l'AXE de départ ( VESSEL) et l'axe d'arrivée ( BASE )

l'autre axe à "0"

Tu veux dire donner 0 en longitude , 0 en latitude , et 0 en rayon ?

avec successivement

Dans quel order s'il te plait ?

C'est là que nous constatons l'importance d'une communauté , les Talents étant divers et personnels , doivent être rassemblés et mis au service pour permettre au VESSEL " PROGRESS" de décoller ...

[cslevine]

TROP TARD

Cette page que tu cites N'OFFRES PAS l'algorithme

et tu es sûr qu'en visualisant le fichier HTML on ne trouve pas l'algorythme.

FIN TROP TARD
Trop tard parce que tu as apparament trouvé une routine c++.

et bien pour les axes j'ai fait comme ceci :

ma base
BASE-V2.0
Name = Paname
Location = 2.348201 48.858161

ensuite j'avais placé mon DG3 à quelques centaines de mètres de là, genre par exemple place de la Concorde, que je retrouve dans le Current State.scn

vaisseauA:DeltaGlider
  STATUS Landed Earth
  POS 2.3212010 48.8711610
  HEADING 0.00
  AFCMODE 7
  PRPLEVEL 0:0.380000 1:1.000000
  NAVFREQ 402 94 0 0
  XPDR 0
  GEAR 1 1.0000
  AAP 0:0 0:0 0:0
END


et bien dans la page des cases jaune et bleu (http://www.abe.msstate.edu/~fto/calculator/converte.html) qui ne donne QUE une seule distance à vol d'oiseau, j'ai procédé en 2 temps :
j'ai cherché sur l'axe des x en donnant d'abord les longitudes :

2.3212010 et 2.348201 avec des latitudes toutes les 2 à 0
ainsi j'ai obtenu ma première distance vol d'oiseau à noter dans X , genre par exemple 2020 m
puis j'ai fait la même démarche pour Y, en obtenant 1490 m et ainsi (j'aurais) pu placer mon mesh correctement ( si mon Paname n'avait pas un scale de 1.1 sur l'axe des X)


MESH
   FILE SimplifiedPaname/b_guillotine
   SCALE 1 1 1
   POS -1490 +2.7 -2020
   ROT 120
   OWNMATERIAL
   SHADOWS
   PRELOAD
END


en ce qui concene l'algorythme en C je propose la méthode suivante :
tu place d'abord un mesh précis genre un cube à +500 m et +800 m d'une base,
ensuite tu poses un DG3 exactement à l'endroit du cube.
Après, tu essayes d'utiliser le code c++ trouvé, avec par 2 fois, les coordonnées entre la base et le DG3 pour trouver les 2 axes.
et tu vois si cela te donne une valeur pas trop éloignée de +500 m et +800m.

Normalement tu devrais obtenir un genre 499 et 802, simplement parce qu'on ne pose jamais exactement le centre du DG3 pile poile précisment au milimètre près.

[MrSpock]

Ouuuais ! Super Sammy !
Merci pour ton aide , je sens que je vais bien m'éclater ce soir ...
Si j'ai une autre question ( mais j'en doute , tu es très clair ! ) je te MP .

et tu es sûr qu'en visualisant le fichier HTML on ne trouve pas l'algorythme ?

Ah oui , j'aurais pu en effet chercher dans le source !
Pour info , je vais utiliser la formule Haversine qui est Largement plus speed !
Pour la précision, on verra , mais quand même il ne devrait pas en résulter de pertes humaines ...

en ce qui concene l'algorythme en C je propose la méthode suivante :
tu place d'abord un mesh précis genre un cube à +500 m et +800 m d'une base,
ensuite tu poses un DG3 exactement à l'endroit du cube.
Après, tu essayes d'utiliser le code c++ trouvé, avec par 2 fois, les coordonnées entre la base et le DG3 pour trouver les 2 axes.
et tu vois si cela te donne une valeur pas trop éloignée de +500 m et +800m.

Oui patron ! En fait , j'admire ta logique sur ce coup ... Je vais essayer de comprendre pourquoi çà marche ... ( sous réserve que çà marche, mais j'le sens bien ! ) .En fait , je ferais tout pour éviter les matrices ( Tofitouf m'a suggéré une manière de procéder par MP, mais c'est encore trop abstrait ... ).




Message modifié ( 13-08-2010 21:03 )

[cslevine]

procéder par MP, mais c'est encore trop abstrait

ah oui, genre envoyer par MP les coordonnées à calculer à un autiste asperger de haut niveau (genre Daniel Tammet... ) et il donne en retrour les bons résultats... y'aura quand même le temps de la transmission des emails...  

[MrSpock]

Qui se ressemble s'assemble ...
Je suis entrain de coder la " chose " , hier soir j'ai été envahi par une multitude de têtes blondes ...
A+ , bonne journée sammy .

Spoiler  :

Daniel Tammet (31 janvier 1979 à Londres - ) est écrivain, poète et linguiste.
Il vit et travaille à Avignon (France) depuis 2008.
Il est l'auteur en 2007 de "Je suis né un jour bleu" (Edition Les Arènes): un best-seller autobiographique traduit en 19 langues (dépêche AFP du 06/02/09), témoignage rarissime d'un jeune homme atteint du syndrome d'Asperger (une forme légère d'autisme qui s'accompagne chez lui d'une mémoire hors du commun, de synesthésie - pour lui, mercredi est un jour bleu- et de quelques difficultés d'interaction sociale). Les scientifiques disent de lui qu'il est la pierre de Rosette de l'autisme (AFP du 06/02/09) car il est l'un des rares individus autistes à pouvoir mettre des mots sur ce qu'il vit, ressent et à en faire la synthèse.

Message modifié ( 14-08-2010 14:42 )

[cslevine]

je viens de modifier le titre du sujet. Car zut une fois de plus j'ai écrit exactement le ontraire de ma pensée dans le titre :

"cherche moyen de calculer des coordonnées à partir d'un POS"

alors que je voulais dire le titre actuel :

""cherche moyen de calculer un POS à partir de des coordonnées"


c'est mon inconscient qui peut être me joue des tours depuis la plus petite enfance, et me fait dire l'exact contraire de ma psnée. Comme une dyslexie mais qui n'est pas dans les mots ( écrire "niege" pour "naige" ) mais dans les formulations.
Fixed !

[MrSpock]

c'est mon inconscient qui peut être me joue des tours depuis la plus petite enfance

Toi , au moins , tu le sais !

[MrSpock]

Date    26-07-2010 20:59

Date de lancement de l'idée ... faudrait que je me bouge le c..    mes neuros-capteurs s'activent !
J'ai d'autres projets sur le grill , qui en dépendent ...




Message modifié ( 15-08-2010 14:58 )

[MrSpock]

j'ai procédé en 2 temps :
j'ai cherché sur l'axe des x en donnant d'abord les longitudes :

2.3212010 et 2.348201 avec des latitudes toutes les 2 à 0
ainsi j'ai obtenu ma première distance vol d'oiseau à noter dans X , genre par exemple 2020 m
puis j'ai fait la même démarche pour Y, en obtenant 1490 m et ainsi (j'aurais) pu placer mon mesh correctement ( si mon Paname n'avait pas un scale de 1.1 sur l'axe des X)

Aprés réflexion , cela ressemble à ce que me disait Tofitouf à propos des matrices , qui ont cette propriété de rendre
ce genre de calcul en 1 fois .

Je cherche à comprendre le COMMENT :  en plaçant 0 pour longitude  puis lattitude de départ , tu " poses un pied "
dans l'espace de destination puisque son centre est 0,0,0 . Une espèce de grand écart quoi ...
UNe matrice permettrait le saut à pied joint ...
Un ptit screen pour te dire où j'en suis ...

Code: [Select]

double rBase,rVessel;
double Latitude1,Longitude1,Latitude2,Longitude2,rayon;
double distanceLon,distanceLat ;
double x,y,z;

//rayon de la planete
rayon=oapiGetSize(stat.rbody) ;
//récupère la position equatoriale de la base résultat en radians
oapiGetBaseEquPos(HBase,&Longitude2,&Latitude2,&rBase);
//récupère la position equatoriale du vaisseau résultat en radians
MeshBuilder->GetEquPos(Longitude1,Latitude1,rVessel);
// distance entre les deux points
double distance = rayon * 3.1415926 *sqrt((Latitude1-Latitude2)*(Latitude1-Latitude2)
+cos(Latitude1/57.29578 )*cos(Latitude2/57.29578 )*(Longitude1-Longitude2)*(Longitude1-Longitude2))/ 180;
Là, j'en suis à vérifier que c'est la bonne formule pour le calcul des distances .
Ensuite je remplacerai lat par 0 etc ...



Message modifié ( 15-08-2010 15:46 )

[MrSpock]

YEAH !!
Bon , c'est le même foutoir dans mon code que dans mon "atelier" , mais :
Résultat du fichier MeshPoser.cfg , créé à partir du mfd MeshPoser , en appliquant le code précédent , en chargeant
le scenario DELTAGLIDER->Cape canaveral , et en mettant cape canaveral comme base de référence .
Donc , le DG sur le Pad par défaut .

Code: [Select]

BEGIN_OBJECTLIST
MESH
FILE
SCALE
POS
OWNMATERIAL
SHADOWS
PRELOAD
END
  Distance en metres 0.0265458
  Distance en metres 0.0265458
  Distance en metres 0.0265458
Plûtot pas mal ...
Je vais essayer de faire un petit tour au sol et je reviens ..

[MrSpock]

En mouvement , a l'interieur du bloc NASA ...
C'est toujours le foutoir mais c'est pas grave pour l'instant ..

Code: [Select]

BEGIN_OBJECTLIST
MESH
FILE
SCALE
POS
OWNMATERIAL
SHADOWS
PRELOAD
END
  Distance en metres 135.686
  Distance en metres 135.523
  Distance en metres 135.375
  Distance en metres 135.242
BEGIN_OBJECTLIST
MESH
FILE
SCALE
POS
OWNMATERIAL
SHADOWS
PRELOAD
END
  Distance en metres 135.124
  Distance en metres 135.022
  Distance en metres 134.936
  Distance en metres 134.865
Donc :
Les premieres mesures , posé sur le pad 1 , donnaient 0.02... .
Les secondes , le gros Bloc NASA , donnent 135.686 .
C'est pas un peu court ?
Curieux .



Message modifié ( 15-08-2010 16:57 )

[cslevine]

oh je vois que ça avance...

[MrSpock]

Genre de questions à laquelle je dois répondre :
Dans

Code: [Select]

double distance = rayon * 3.1415926 *sqrt((Latitude1-Latitude2)*(Latitude1-Latitude2)
+cos(Latitude1/57.29578 )*cos(Latitude2/57.29578 )*(Longitude1-Longitude2)*(Longitude1-Longitude2))/ 180;
EN rouge , les longitudes , lattitudes de la base et du vessel .
J'ai défini (Longitude1,Latitude1) comme attributs du VESSEL .
Ce qui s'ensuit , c'est l'opération VESSEL-BASE dans le calcul .
Ne devrais-je pas faire BASE-VESSEL ?
Bienvenue dans mon tourment !

[MrSpock]

Quelques images , aprés tout ce code ...
Image 1 : Remarquez les deux options en bas à droites du mfd ...
Les deux modules cohabitent . (teamMFD de Pilote334)


Image2 : Page d'ouverture du module



Image3 : Page MNU de MeshPoser



Image4 : Aprés appuyage de OPN ( les caractères en trop disparaitront ...)



Voilà , en l'état , le résumé de la situation .
A+



Message modifié ( 15-08-2010 19:16 )

[MrSpock]

Retour dans le code ...
N'étant malheureusement pas doté d'un QI hors-norme , je dois procéder par tatonnement ( en clair tout éssayer jusqu'à
ce que je trouve ... ) .

Pour répondre au tourment Vessel-base ou base-vessel :

Code: [Select]

//methode d'origine
/*double distance = rayon * 3.1415926 *sqrt((Latitude1-Latitude2)*(Latitude1-Latitude2)
+cos(Latitude1/57.29578 )*cos(Latitude2/57.29578 )*(Longitude1-Longitude2)*(Longitude1-Longitude2))/ 180;
*/
//methode d'essai
double distance = rayon * 3.1415926 *sqrt((Latitude2-Latitude1)*(Latitude2-Latitude1)
+cos(Latitude2/57.29578 )*cos(Latitude1/57.29578 )*(Longitude2-Longitude1)*(Longitude2-Longitude1))/ 180;

oapiWriteScenario_float (fichierConf,"Distance en metres",distance);
Le résultat donne

Code: [Select]

BEGIN_OBJECTLIST
MESH
FILE
SCALE
POS
OWNMATERIAL
SHADOWS
PRELOAD
END
  Distance en metres 134.726
  Distance en metres 134.726
  Distance en metres 134.726
  Distance en metres 134.726

Conclusion :
Ben ouais , la distance reste la même . Pour ma défense , je dirais que l'ordre sera important quand je vais demander
au programme de me donner la position de A dans le système de B ...
A mon avis , faudra décaler la virgule vers la droite .



Message modifié ( 15-08-2010 18:38 )

[cslevine]

hé bien... ça continue d'avancer.

[MrSpock]

Salut sammy !
A pas de gé... ... hum ..