Ortho4XP

[Oscar Pilote]

@aquitain

Merci pour ton retour et tes propos exagérés. Plutôt qu'une utilisation massive je préférerais que les utilisateurs qui ont acquis de l'expérience dans
l'utilisation du programme fassent bénéficier de leurs tuiles en les uploadant sur zonephoto (cela demande bien sûr de la coordination et l'accord de Pascal),
j'ai tenté de lancer le mouvement l'an dernier mais je n'ai pas été très suivi).

en utilisant le mesh HD alpilotx et en modifiant l'autogen US pour le look des bâtiments le résultat est parfait.

En fait Ortho4XP crée son propre mesh (ce qui ennuie Ypsos pour ses vols réseaux mais plait à Jojo pour ses scènes ciselées). Dans le
HD mesh d'alpilotx (qui serait mieux nommé un HD scenery puisqu'il contient un mesh + des overlays et que son mesh est créé en réallité
par Meshtool de Laminar ) vous prenez les overlays (fôrets, routes, autogen) mais rien du mesh.
Cela peut paraitre de la coquetterie, mais en réallité 90% du code du programme (et 100% de mes cheveux blancs) concernent la création du
mesh. Il me semble que le minimum que l'on puisse attendre d'un simulateur de vol c'est un bon avion et une bonne piste, et parfois
j'avais l'impression que la piste gâchais tout le plaisir, en montagne surtout mais pas uniquement. Il reste beaucoup de bizareries par défaut,
mais avec des "patchs" j'ai l'impression qu'on peut vraiment s'approcher de la réallité.

[Oscar Pilote]

Bonjour Oscar
sur la version .exe, il n' ya donc pas de manip a faire pour que nvidiacompress et CUDA soit utilisé. Correct ?

Correct. Quel temps de construction te paraitrait "rapide" et qu'elle est ta config ?

[Oscar Pilote]

ps : j'ai quand même une suggestion ; ne pourrait-on pas avoir la possibilité de ne travailler que sur une partie de la tuile ?

Peut-être que si tu as autant de patience que Goda... (cfr quelques centaines de pages plus haut)..., mais je n'ai pas
de solution qui me plaise pour l'instant (on le pouvaint dans une première version où justement on ne faisait que recopier et
découper le mesh, mais cela ne permettait pas de faire les patchs, les masques, etc). Le terrain est tjs en jachère.

[Oscar Pilote]

Ce qui pourrais être bien c'est d'avoir un standard compatible avec simhaven, zonephoto, spain_uhd, x-italy, Ortho4XP afin que tous les utilisateurs de ces tuiles aye le même résultat en vol.

C'est sûr cela pourrait être bien. Mais je te laisse songer à ce que tu mettrais exactement dans le "standard", et si tu ne te cognes pas rapidement à la dure réallité je serai très intéressé par ton retour.

[nicowork]

@aquitain

Merci pour ton retour et tes propos exagérés. Plutôt qu'une utilisation massive je préférerais que les utilisateurs qui ont acquis de l'expérience dans
l'utilisation du programme fassent bénéficier de leurs tuiles en les uploadant sur zonephoto (cela demande bien sûr de la coordination et l'accord de Pascal),
j'ai tenté de lancer le mouvement l'an dernier mais je n'ai pas été très suivi).

Les tuiles ZL17 sont difficilement échangeable sur Internet en raison de leur poids. Plutôt que échanger des tuiles complètes, pourquoi ne pas échanger des profils de tuiles ? Un profil de tuile comprendrais la configuration de Ortho4XP, les patchs OSM, les overlays,...

[cfukpixie]

10 mn me senble raisonable pour une construction de tuile. En zoom 16 c'est possible, en 17 moins
Ma config est un i7-6700K 16GB de RAM et une GTX970 avec un M2 et un SSD Dedie.

[cfukpixie]

Bonjour


Je suis un utilisateur "neuf" de xplane avec peu d experience. J'étais auparavant sur P3D. Ortho4XP est vraiment super, mais j 'ai un doute.
Je reussis a generer des tuiles juste en lancant le programme et en les seleccionant sur la carte. Cela marche tres bien.
Je suis un peu confus quand a l'overlay. Est'il possible pour quelqu un de le resumer pour un beotien.
On dit que Ortho4XP genere son mesh mais il faut utiliser le mesh HDv3 pour l'overlay. Moi pas comprendre
Et comment utilisent t¡on les OSM World et Mixed Europe de Simheaven.
Merci pour votre aide.

[nicowork]

Bonjour Oscar,

Lors du Build vector data de la tuile +49+5, j'ai le message d'erreur:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "./Ortho4XP_v117.py", line 369, in build_poly_file
print(" * "+idcosmr_icao[relid])
NameError: name 'idcosmr_icao' is not defined

Je n'ai pas de problème avec les autres tuiles. Est-ce que le problème vient des données OSM ?

Merci

[Ypsos]

Otho4XP réalise du bon travail. La conception du logiciel est remarquable est remarquée.

Et sur les 100 pages de lecture on peut bien relever la complexité d'utilisation qui reste du domaine des initiés malgré les très bons tutoriaux.

@aquitain

...

En fait Ortho4XP crée son propre mesh(ce qui ennuie Ypsos pour ses vols réseaux ...).

Si déjà Ortho4XP génére ses propres mesh, je pense qu'il y a possibilité d'étudier la moyenne de différence des niveaux entre un xPlane par défaut, un xplane équipé de zonephotos 16et17 et les tuiles réalisées avec Ortho4XP.

Puis appliquer automatiquement lors de la conversion un chiffre correctif de niveau pour ne plus avoir ce problème qui est perturbant. ( pas ennuyeux vraiment perturbant d'avoir un avion qui décolle en mode sous marin faisant surface devant soit en sortant de la piste.)

mais avec des "patchs" j'ai l'impression qu'on peut vraiment s'approcher de la réallité.

On est d'accord, un avion dans la réalité n'est pas enterré ni suspendu en l'air et voler en réseau et pas seul est aussi plus proche de la réalité. Conclusion : à quand le patch dans Ortho4XP de régulateur de niveau?

[Oscar Pilote]

Puis appliquer automatiquement lors de la conversion un chiffre correctif de niveau pour ne plus avoir ce problème qui est perturbant.

On en a déjà discuté au téléphone il y a un an, si vraiment il y avait une solution aussi simpliste elle
aurait déjà vu le jour. La différence de niveau entre deux mesh n'est bien sûr pas la même sur toute la tuile,
et si tu ajustes à un endroit tu décales à un autre, c'est inextricable.

Une vraie solution il me semble (mais ce n'est pas de notre ressort) serait que le simulateur transmette
par le réseau l'altitude AGL et non pas l'altitude AMSL. Ainsi quand il transmettrait 0 chaque X-Plane distant placerait
l'avion à 0 au-dessus de son propre mesh, indépendamment des autres.
Je crois savoir que tu es assez efficace à contacter le support Laminar, voici donc une suggestion...

[Ypsos]

On en a déjà discuté au téléphone il y a un an, si vraiment il y avait une solution aussi simpliste elle
aurait déjà vu le jour.

Nous en avons parlé effectivement au téléphone il y a un an de cette question.
La solution simpliste que j'avance est une image bien entendu pas une solution technique qui reste du domaine de ceux qui savent.

La différence de niveau entre deux mesh n'est bien sûr pas la même sur toute la tuile,
et si tu ajustes à un endroit tu décales à un autre,

Dans mon esprit suite à notre conversation, je suis encore en attente de réaliser des tests avec toi pour savoir et identifier si mondialement, sans considération de zone,
-la différence de niveau reste la même ?
-cette différence est variable ce qui va tout compliquer?
-si on arrive à isoler une moyenne globale pour limiter le phénomène?

c'est inextricable

.
L'homme est allé sur la Lune, je suis convaincu que les spécialistes vont trouver une solution (désolé c'est mon coté professionnel. En effet je n'ai jamais eu le droit en 46 ans de métier de ne pas trouver une solution à un problème. Il fallait toujours le pallier ou au moins trouver une solution à la problématique : ne pas régler la question de fond mais trouver une solution pour que cela fonctionne et ne bloque pas la boite) .

[QUOTE]Une vraie solution il me semble (mais ce n'est pas de notre ressort) serait que le simulateur transmette
par le réseau l'altitude AGL et non pas l'altitude AMSL. Ainsi quand il transmettrait 0 chaque X-Plane distant placerait
l'avion à 0 au-dessus de son propre mesh, indépendamment des autres.La solution simpliste que j'avance est une image bien entendu pas une solution technique qui reste du domaine de ceux qui savent.

Une autre image technique serait-elle dans cette réponse? un patch dans la tuile ORTHO4XP qui envoi l'altitude AGL à la place de AMSL.

Je crois savoir que tu es assez efficace à contacter le support Laminar, voici donc une suggestion...

Uniquement pour le tout petit domaine que je maitrise : le réseau multijoueur. Aussi il vaudrait mieux que contacte directement Laminar car si leur support me pose des questions sur ORTRHO4XP, je ne saurai y répondre.( Et peut être ils peuvent donner d'autres pistes pour ORTHO4XP).

Pour revenir à la différence de niveau.

Ceux qui utilisent xPlane avec les mesh par défaut comme ceux qui ont installé zonephotos 16 ou 17, les avions des autres, comme le leur, sont au même niveau : sauf l'avion de ceux qui utilisent ORTHO4XP . N'étant pas "technicien de la chose" : comment sont faites autres tuiles pour que cela fonctionne?


On a un super outil avec un bon résultat pour ceux qui l'utilisent.

Je ne peux que témoigner d'un problème et réaliser des tests pour permettre de trouver une solution. Solution qu'il faudrait trouver car ce ne serait pas logique de devoir réaliser des réseaux pour ceux qui utilisent ORTH4XP et des réseaux avec ceux qui utilisent toute les autres tuiles qui ne posent pas ce problème.



Courage et @+

[nicowork]

Ceux qui utilisent xPlane avec les mesh par défaut comme ceux qui ont installé zonephotos 16 ou 17, les avions des autres, comme le leur, sont au même niveau : sauf l'avion de ceux qui utilisent ORTHO4XP . N'étant pas "technicien de la chose" : comment sont faites autres tuiles pour que cela fonctionne?

Les tuiles SpainUHD et x-italy ont le niveau de zonephotos(2012)/simheaven ou le niveau de Ortho4XP ?

[Oscar Pilote]

Uniquement pour le tout petit domaine que je maitrise : le réseau multijoueur.

Mais c'est exactement de ce dont il s'agit non ? Tu as bien identifié la cause, l'utilisation de mesh différents par les utilisateurs (nulle
n'importe la manière dont chacun a été créé, la seule chose qui compte c'est leur différence de hauteur en chaque point), mais je
pense que tu regardes dans la mauvaise direction pour ce qui est de la solution.

Puisque X-Plane n'impose pas de mesh, c'est à lui de pouvoir gérer des mesh différents dans le réseau multi-joueurs.
C'est le simulateur qui transmet l'altitude de l'avion, que ce soit au dessus du sol ou au dessus du niveau moyen
des mers, pas la tuile. L'idée que j'ai proposée plus haut me paraît raisonnable (et indépendante de quelque programme que ce soit),
mais elle ne concerne que le simulateur et seul Laminar a la main dessus (à moins même que ce soit déjà une option à cocher
dans les paramètres réseaux (?)).

Si tu veux ouvrir un post séparé sur le sujet libre à toi, mais là ça commence à ressembler à l'histoire tu type qui a peint sa maison
en jaune et à qui le voisin lui demande de la repeindre en rouge parce que ça lui conviendrait mieux. Si cela n'avait pas d'autres
conséquences dommageables je le ferais volontiers mais ce n'est pas le cas.

[Oscar Pilote]

Les tuiles SpainUHD et x-italy ont le niveau de zonephotos(2012)/simheaven ou le niveau de Ortho4XP ?

Toutes les tuiles que tu cites qui ont été réalisées par g2xpl reprennent le mesh du hd mesh (v2 ou v3 ne sais pas) [x-italy, zonephoto2012 et les anciennes simheaven].
Je sais que simheaven a tout refait en ortho4xp, spainuhd je ne les connais pas.
Mais encore une fois ça ne veut rien dire "le niveau de machin", mêle le hd v2 et le hd v3 d'alpilotx sont a des niveaux un peu différents par endroits. Ce qui importe
c'est qu'X-Plane soit a même de faire fi de cette différence (ou alors qu'il impose le mesh).

[Ypsos]

Mais c'est exactement de ce dont il s'agit non ? Tu as bien identifié la cause, l'utilisation de mesh différents par les utilisateurs (nulle
n'importe la manière dont chacun a été créé, la seule chose qui compte c'est leur différence de hauteur en chaque point),

Je ne suis qu'un utilisateur de xPlane dans un contexte de réseau et la différence de niveau vient de OrthoX4P c'est tout ce que j'ai identifié. Je témoigne de ce fait pour faire remonter des informations et permettre au développer s'il le souhaite de pallier le problème technique qui en est bien un.

Pour mémoire depuis plus de 5 ans, lorsque cette situation se présente, je relève le problème, je contacte le développeur du logiciel ou du PlugIn et nous avons toujours très bien collaboré le temps qu'il faut pour que son produit fonctionne correctement autant en usage individuel qu'en réseau. Si le développeur relève une incompatibilité avec xPlane, c'est en sa qualité de développeur qu'il contacte le cas échéant Laminar car lui seul possède les réponses à son produit, l'utilisateur ne saura le faire par manque de connaissance et de compétence.

Puisque X-Plane n'impose pas de mesh, c'est à lui de pouvoir gérer des mesh différents dans le réseau multi-joueurs.
C'est le simulateur qui transmet l'altitude de l'avion, que ce soit au dessus du sol ou au dessus du niveau moyen
des mers, pas la tuile. L'idée que j'ai proposée plus haut me paraît raisonnable (et indépendante de quelque programme que ce soit),
mais elle ne concerne que le simulateur et seul Laminar a la main dessus

C'est donc bien des questions techniques que ne maitrise pas l'utilisateur. Il est donc logique que ces question étant du domaine des développeurs (Laminar + logiciel tiers) c'est au développeur de contacter Laminar et voir avec eux s'il peut faire évoluer la chose, leur faire changer d'avis. L'utilisateur ne saura trouver les arguments technique ni les éléments pour motiver les modifications.

(à moins même que ce soit déjà une option à cocher
dans les paramètres réseaux (?)).

Cette option n'existe pas

mais là ça commence à ressembler à l'histoire tu type qui a peint sa maison
en jaune et à qui le voisin lui demande de la repeindre en rouge parce que ça lui conviendrait mieux.

J'ai vraiment l'impression que nous n'arrivons pas à parler de la même chose.

Ce dont il est question en utilisant cette métaphore, ce ne n'est pas de demander au voisin de changer de couleur.

Mais comme la maison en face est devenue rouge depuis qu'il a utilisé cette peinture jaune, qu'il regarde avec le fabricant de sa peinture jaune pour pallier ce problème. Ce n'est pas le voisin ui avait suc-bit ce changement de couleur de sa maison qui va contacter le fabricant de la peinture jaune.

Si cela n'avait pas d'autres
conséquences dommageables je le ferais volontiers mais ce n'est pas le cas.

En lecture de cette réponse nous serions (conditionnel) obligé de comprendre que c'est bien un problème technique, mais que le développeur (fabricant) considérerait (conditionnel) que c'est un aspect mineur ce qui ne le motive pas à entreprendre les recherches et les travaux palliatifs à son produit.

Si cette lecture que je souhaite erronée, devrait s'avérer correcte, comme à mon habitude il n'y aura aucune critique ni aucun jugement de ma part et ue respecte ce choix. Par contre n'ayant pas les connaissances et surtout pas les compétences de développeur, je ne suis pas en mesure de faire l'intermédiaire entre le développeur et Laminar.