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

[bennyBoy]

J'ai créé la même arborescence chez moi mais sur le disque D: , et ça marche : http://front1.monsterup.com/upload/129499674825.jpg
Qu'affiche la console?

[Al-YOUX]

suite du post précédent (#286)

Après de nouveaux tests, le problème ne semble pas provenir de ton application mais du dossier .osm utilisé.
La manip: Auvergne.osm sélection tuile +45+003, avec ou sans db:
- accepté sous Windows 7 mais qui me donne un dsf non utilisable -> too many pts in roof polygon
- sous Mac un temp.txt bloqué à 4Ko

Avec un autre .osm moins volumineux, ton programme tourne normalement sous Mac mais la conversion .txt ne se fait pas en .dsf
Problème du DSTool évoqué ci-dessus (je le fais avec XGrinder)

alain

[bennyBoy]

Merci pour tes retours, je vais fouiller tout ça.
Pour le too many pts in roof c'etait bien cette histoire de 512 noeuds maximum non?

[lebelge]

Merci pour cette nouvelle beta 4.1

Je viens de faire un test (toujours avec le même fichier Belgium.osm de 1.904.536 Ko) en laissant tout par défaut. C'est pas franchement plus rapide que la V4.0 mais bon, c'est pas le plus important. Y qu'a faire tourner la nuit.

Mais je reviens toujours avec ce problème de reflet du soleil sur les surfaces (je sais, j'suis chiant). Je viens de refaire un test avec la beta 2 en mettant TWO_SIDED 0 dans les fichiers .FAC et là, çà fonctionne nickel.

La preuve en image :



C'est quand même bizarre cette histoire de la commande TWO_SIDED qui doit être à 1 pour les objets non fermés (2D) et à 0 pour les objets fermés (3D).

BennyBoy, tu pourrais me faire une petite version (perso) pour voir si en "refermant la facade" (comme dans la beta V1 ou 2) on pourrait solutionner ce problème ?

lebelge

[bennyBoy]

Je t'envoie ça dans l'aprem leBelge.
Par contre c'est étrange que tu ne vois pas de différence de vitesse entre la beta 4 (uniquement base de donnée) et la 4.1 (qui permet d'utiliser la mémoire comme les anciennes bétas)
Et puis surtout tu peux spécifier la tuile que tu veux générer et pas te taper toute la Belgique.

[Al-YOUX]

Merci pour tes retours, je vais fouiller tout ça.
Pour le too many pts in roof c'etait bien cette histoire de 512 noeuds maximum non?

Si j'ai le temps je regarderai ce +45+003 mais le nombre de polygones est énorme.
J'ai déjà eu du mal trouver celui qui posait problème dans le +45+004 St Etienne.

alain

[Daniel_L]

C'est quand même bizarre cette histoire de la commande TWO_SIDED qui doit être à 1 pour les objets non fermés (2D) et à 0 pour les objets fermés (3D).

C'est pas bizarre, c'est logique.

Facades fermées comme une maison, un hangar. Si les points sont placés en tournant dans le bon sens, il n'y a pas besoin de voir l'intérieur (l'autre face) car il y a un mur autour et un toit au dessus.
Facades ouvertes comme une barrière. Là par contre, il n'y a pas de toit alors on peut voir l'autre coté dans le simu et il faut que la face soit déssinée d'où le TWO_SIDED à 1.

Le mieux pour faire des tests serait de placer des facades comme on veut avec WED 1.1 pour faire les différents cas et voir ce que ça donne dans X-Plane.

Daniel

[lebelge]

On est pas sorti de l'auberge ... mais il doit sûrement y avoir une solution.

Oui, je parle évidemment (encore et toujours) des reflets sur les surfaces des bâtiments générés par OSM2XP.

BennyBoy, super-réactif, m'a permis de tester une version 4.1 (édition limité) reprenant un peu le principe de la beta 2 (à savoir, en refermant la façade). Et bien ,voici le résultat :



Je rappelle que dans mes fichiers .FAC, TWO_SIDE est remis 0 (zéro). C'est normalement ainsi que cela devrait être (n'est-ce pas Daniel_L ?) De toute façon, c'est la seule façon d'avoir un reflet du soleil.

Et pourtant, une fois, c'est bon (flèche rouge 1)
Une fois c'est pas bon (flèche rouge 2)

C'est le même fichiers .FAC

DONC... je crois que PhM détient la vérité (ou une partie) quand il dit :

Tes problèmes de lumière et d'objets incomplets sont effectivement très probablement dû à des orientations de polygones inversées (winding order pour ce qui concerne X-Plane).

Un moteur graphique détermine les faces à afficher, entre autres, grâce à l'ordre des points qui la compose, soit dans le sens horaire, soit anti-horaire. Si la face est à l'envers il la considère comme cachée puisque tournant le dos à la caméra et donc ne va pas la tracer, d'où les morceaux manquants. Faire des faces à deux côtés semble résoudre le problème mais ne fait que le masquer, la seule solution viable est d'orienter correctement toutes les faces.

Pour l'éclairage, le moteur utilise des normales, pour chaque point si c'est un moteur haut de gamme, une seule centrée sur la face si c'est un moteur moins performant ou si l'on a pas le choix parce que la machine peut pas faire plus. Ces normales doivent être orientées vers l'extérieur de l'objet pour que la lumière soit correcte.

Il peut donc potentiellement y avoir deux sources de problèmes dans vos modèles :

1 - Les faces sont à l'envers.
2 - Les normales sont à l'envers.

Ce qui nous donne quatre cas de figure, dont seul un nous intéresse, à savoir tout est à l'endroit.

PhM

Mais bon, ça, c'est la théorie.
En pratique, comment faire ?!!!!

lebelge

[bennyBoy]

Tu as le même resultat avec la béta2 leBelge?

[lebelge]

Tu as le même resultat avec la béta2 leBelge?

Heuuu ...Non ?!!!

Voir ici avec la beta 2 -> http://www.x-plane.fr/attachment.php...9&d=1295006544

lebelge

[ChD]

DONC... je crois que PhM détient la vérité (ou une partie) quand il dit :

Tes problèmes de lumière et d'objets incomplets sont effectivement très probablement dû à des orientations de polygones inversées (winding order pour ce qui concerne X-Plane).

En pratique, comment faire ?!!!!

Il n'y a pas 50 solutions : si les points saisis par les contributeurs d'OSM sont un coup dans le sens horaire, un coup dans l'autre sens, il va falloir faire un peu de trigo pour déterminer le sens de rotation et inverser ceux qui ne vont pas avant génération des fichiers DSF.
Pour les bâtiments composés de nombreux points, ça risque de faire pas mal de calculs en plus...

[bennyBoy]

Bon et bien c'est de ma faute alors.
Je vais faire des tests avec tes fichiers façades jusqu'à arriver au bon résultat.

Je ne pense pas que cette histoire de sens des points soit le problème, si le Belge arrive à avoir un bon résultat avec la béta 2 sur la même zone et qu'avec la béta >3 ça plante, c'est bien mon code le responsable.

[Daniel_L]

Je ne pense pas que cette histoire de sens des points soit le problème, si le Belge arrive à avoir un bon résultat avec la béta 2 sur la même zone et qu'avec la béta >3 ça plante, c'est bien mon code le responsable.

Le sens des points ne joue que sur le visuel si on utilise TWO_SIDED à 0. Si les points ne sont pas dans le bon sens on obtient l'image de ce message http://www.x-plane.fr/showthread.php...l=1#post382059 de LeBelge. On voit "l'intérieur" des bâtiments car la face qui devrait être à l'extérieur se trouve en fait à l'intérieur et on ne voit que celle-là.
Ce n'est peut-être pas ça qui fait planter mais ça doit jouer sur les toîts. Là en TWO_SIDED=0 on voit qu'ils n'apparaissent pas du tout. Avec TWO_SIDED=1, le fait d'afficher les deux cotés des murs cache le problème et c'est peut-être ça qui gène pour les toits en pente. Je pense que ça joue aussi sur l'éclairage des faces.

Daniel

[PhM]

C'est quand même bizarre cette histoire de la commande TWO_SIDED qui doit être à 1 pour les objets non fermés (2D) et à 0 pour les objets fermés (3D).

C'est en rapport avec l'orientation des polygones dont j'ai parlé plus haut.

Un objet 2D sera visible tant que ses polygones font face à la caméra, mais disparaitra si il tourne le dos à la caméra (back-face culling). Pour éviter cela il faut préciser au moteur graphique que ces polygones doivent être tracés quelle que soit leur orientation relativement à la caméra.

Un objet 3D ne présenta pas ce comportement puisqu'il y a toujours des polygones qui font face à la caméra, et donc l'objet sera visible quelle que soit sont orientation.

PhM

[juliet_romeo]

Bonsoir,
j'ai chargé mon aéroclub LFPH et la ville de chelles, en région parisienne
mais tous les bâtiments n'apparaissent pas ???

Ici le centre commercial "carrefour" pas pris en compte :


Ici les hangars de LFPH manquent :


Là un bâtiment industriel manque :