osm2xp - Génération batiments via open street maps

[david42fr]

il suffit de remplacer le répertoire facades de ressources de osm2xp et de régénérer la scène? enfantin en plus!

[bennyBoy]

Logiquement pas besoin de régénérer la scène, uniquement remplacer les fichiers façades par défaut par ceux de leBelge.

[david42fr]

Et on les trouve où ces fichiers par défaut?


PS: inscrit sur ton forum ;)

[bennyBoy]

Et bien au choix:


-Tu génères une scène avec osm2xp, tu vas dans le dossier généré et tu remplaces le contenu du dossier facades par les fichiers de leBelge.
-Ou bien tu vas dans le dossier de l'application osm2xp, puis dossier ressources/facades, et tu remplaces ces fichiers la par ceux de leBelge pour qu'osm2xp génère les scènes avec les fichiers de leBelge.

[PhM]

...Pour ce qui est du gain en FPS, tout dépend de la puissance de la machine et du nombres de façades à afficher mais sur de petites config, j'ai déjà remarqué que l'utilisation d'une seule texture pour plusieurs objets permettait de soulager la mémoire et indirectement, augmenter le FPS.

X-plane ne nous laisse pas beaucoup d'opportunités pour agir sur le tracé de nos scènes, mais effectivement les textures sont un point à ne pas négliger.

En gardant en tête le fonctionnement moteur graphique on en vient à utiliser les solutions qui lui faciliteront le travail, il sera donc possible d'en faire plus dans un temps donné. Au final plus sera dessiné pour le même taux de FPS, ou la même chose avec un taux de FPS supérieur ce qui revient au même.

Les textures doivent être résidentes en mémoire vidéo pendant le tracé des objets les utilisant, puisque le GPU doit pouvoir y accéder. Si la mémoire vidéo n'est pas assez large (petites configurations) il faut alors transporter les textures depuis la mémoire centrale vers la mémoire vidéo à chaque fois qu'elles sont nécessaires.

Ce transfert se fait à la vitesse du bus PCI (ou AGP si il y en a encore). De mémoire un PCI 2.0 x16 fait des transferts à 8GB / s maximum (théorique). Une texture 1024 x 1024 en 32 bits prend 4MB au total, et donc (4 x 1024 x 1024) / (8 x 1024 x 1024 x 1024) soit 1 / 2048 secondes pour être transférée. Pour donner une idée il est possible d'en transférer 34 pendant le temps d'un écran à 60Hz.

On a donc tout intérêt à transférer les textures une fois et les utiliser de multiples fois, donc pour de plusieurs objets. On a également intérêt à choisir la résolution la plus petite qui donne le résultat visuel escompté. Ce sont deux points sur lequels il nous est facile d'agir.

Un autre aspect très important est de faire en sorte que le moteur graphique ne passe pas son temps à envoyer des commandes vers l'API graphique, openGL dans notre cas. Il vaut mieux lui demander de tracer des milliers de triangles en une commande qu'en une centaine. Il faut donc, au niveau X-Plane, grouper tous les tracés dans le nombre minimum d'objets. Un .obj définissant la, ou les, texture(s) ainsi que tous les vertices (VT), les index (IDX et IDX10) et les triangles (TRIS) nécessaires au tracé de plusieurs objets demandera moins de temps pour un résultat visuel identique qu'un fichier .obj par objet.

Un autre point ayant son importance est de ne pas faire deux fois le même travail. C'est le point faible des fichiers .pol puisque X-Plane va les re-tracer par dessus le sol standard. Dans le cas de petites surfaces cela ne sera pas un problème, mais dans le cas contraire un DSF à la sauce g2xpl sera gagnant.

PhM

[bennyBoy]

la béta 4 est dispo sur le forum osm2xp (http://forum.osm2xp.com), j'espère que cela sera la dernière béta avant la finale.
Il reste quelques points à corriger mais rien de compliqué, la grosse partie qui était la modification du traitement des fichiers osm en utilisant une base de donnée embarquée tourne bien.

Par contre je n'ai pas modifié le point du dernier vecteur qui doit retourner sur le premier pour les facades illuminées de l'ami leBelge , j'attends d'avoir plus de billes la dessus pour voir si je met toujours le dernier point, si je met une option pour choisir etc...

J'ai lancé un test sur le fichier ile de france hier, et Paris a bien été généré, enfin pas sur que ce soit Paris vu que je n'ai pas lancé xplane , mais j'ai vu passer une tuile qui a pris 20 minutes environ à être générée, avec un fichier txt de 300 mo (les anciennes versions beta auraient crashées pour une tuile aussi grosse).

En toute logique il est possible de donner à la beta 4 un fichier France.osm, et d'avoir au bout de X heures l'autogen pour la France Entiere, voir même donner un fichier Planet.osm et attendre quelques jours :D

Je vais essayer de rapidement corriger les petits points gênants pour pouvoir sortir une version 1.0 le plus tôt possible.
Encore merci à tout le monde pour les retours , les idées et les encouragements ;)

Ben

[lebelge]

la béta 4 est dispo sur le forum osm2xp (http://forum.osm2xp.com), j'espère que cela sera la dernière béta avant la finale.../...
Encore merci à tout le monde pour les retours , les idées et les encouragements ;)

Ben

C'est nous qui te remercions !!!

Pour ce qui est de la beta 4, quelques petites remarques (faut les prendre positivement stp hein)

Petit print-screen, ce sera plus simple a expliquer ensuite...



1. Dans la fenêtre Osm2XP, c'est encore le titre Beta3.1 (OK, on s'en fou, juste une remarque)

2. J'ai lancer le fichier Belgium.osm (1.904.536 Ko). Il m'a trouvé 13 tuiles ?!!! ... pour un aussi petit pays, j'suis très fier sauf qu'il m'a pris plus de 20 minutes pour créer la première tuile (51,2) qui fait 40 Ko (voir +51+002.dsf) ... bref, il m'en reste encore 12 à laisser faire, et je risque bien d'y passer la semaine. En tout cas, pour le moment, la LED de mon disque dur est allumé en permance, il bosse comme un con avec mes 4 CPUs en cascade (quad core).

Je vais le laisser aller jusqu'au bout mais, honnêtement, je préférais la version précédente où l'on pouvait choisir la tuile que l'on souhaitait traiter (quitte à relancer plusieurs fois ton application.)

Maintenant, BennyBoy, ne le prend pas mal, c'est encore en cours de traitement chez moi, c'est juste une première remarque (peut-être déplacé) mais je voulais te donner mes premières impressions "à chaud" sur cette nouvelle beta.

En tout cas, cela ne plante pas... pour le moment :yaeh am not durnk:

lebelge (qui en dira plus une fois que ce sera terminé)

[bennyBoy]

Hello LeBelge,

Pour le titre bien vu, je suis passé à coté :grin:

Pour tes 13 tuiles, et bien le fichier osm doit avoir les coordonnées de 13 tuiles en effet, tout dépend de la structure du fichier osm, dans mon cas pour le languedoc les zones d'eau sont aussi présentes...

Ne t'inquiète pas je ne vais pas vous laisser ce système ou il faut tout générer obligatoirement, mais je réfléchis encore de quelle façon présenter ça dans l'interface.

En tout cas le principe sera de donner à l'utilisateur le choix de générer toutes les tuiles détectées ou uniquement certaines, je veux juste éviter le système de coordonnées à saisir qui peut prêter à confusion.

[david42fr]

Je viens de lancer la génération sur rhone alpes pour voir mais c'est long. La durée est fonction des tuiles, certaines étant générées en 11 minutes, et là sur 45 4 ça fait 1H30 qu'il mouline. Je verrais demain matin ce que ça a donné

[juliet_romeo]

Bonjour,
j'ai ce contenu avec le fichier "Ile-de-france.osm"
avec java V6 update 23 installé.
que manque t-il ???

23:22:34 Analyse du fichier osm pour lister les tuiles
java.net.MalformedURLException: unknown protocol: g
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.setupCurre ntEntity(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determin eDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse (Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse (Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse( Unknown Source)
at fr.benny.osm2xp.parser.XmlParser.ParseDocument(Xml Parser.java:43)
at fr.benny.osm2xp.utils.Osm2xpLauncher.doInBackgroun d(Osm2xpLauncher.java:34)
at fr.benny.osm2xp.utils.Osm2xpLauncher.doInBackgroun d(Osm2xpLauncher.java:1)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unkn own Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source)
at java.lang.Thread.run(Unknown Source)
23:22:34 le document osm contient les tuiles suivantes:
[]

[bennyBoy]

@David 1h30 c'est quand même un peu long

@Juliet_romeo , on dirait qu'il y a un problème sur ton fichier osm, tu peux essayer avec un autre fichier? (par exemple un fichier du site http://cadastre.osm.cleo-carto.org/)

Merci pour vos retours, j'ai du boulot pour corriger tout ça , mais je pense savoir comment régler ce problème de lenteur.

[juliet_romeo]

@bennyBoy
Merci de m'aider..!
j'ai donné a manger le fichier "TE139-COURTRY-housses.osm" de 2937 Ko
et osm2xp le recrache très rapidement sans bosser et texte identique.

[bennyBoy]

Je t'ai envoyé le lien de la béta 3.1, merci de me dire ce que ça donne chez toi avec cette version.

[david42fr]

En plus, le PC a redémarré cette nuit à cause des maj windows. Du coup pas de log pour voir ce qui s'est passé.Mais c'est le fichier qui coinçait avec la beta 3.

Ce serait bien d'ailleurs si il y avait une sauvegarde fichier du log

[bennyBoy]

Oui je vais écrire le log dans le dossier osm2xp pour la finale.
Le système de traitement des tuiles était trop lent de toutes façons, je suis en train de tester une nouvelle approche plus rapide.