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

[PhM]

...Il est aussi déconseillé de mettre TWO_SIDED à 1. Il devrait normalement être à 0 (zéro). Le mettre à 1 cache le problème.

Tout à fait, cf ici et ici. TWO_SIDED à 1 va supprimer le back-face culling et donc afficher les faces quelle que soit leur orientation.

Il n'y a plus qu'a voir si en modifiant le sens dans lequel les facades sont construites peut résoudre le problème. (A priori, ce serait dans le sens inverse des aiguilles d'une montre).

C'est évident sur tes captures d'écran que le sens n'est pas bon. Les faces visibles sont celles "intérieures" de tes bâtiments, cf ici et ici.

PhM

[PhM]

Moi pas tout comprendre... Moi naître en Afrique.:patapon:

3x... 4x... PLUS ?!!!!
Meuuhh non, 3x... 4x... MOINS d'espace mémoire :yuush::yuush:
Si on réduit une texture de 1024x1024 à 512x512 ... on diminue l'espace RAM de 3x (ou 4x, je m'en fou) peut importe mais on améliore le FPS SANS faire de (grosse) concession du côté visuel.

Mais bon, comme l'a dit un de vos présidents,.... je vous ai compris :grin:

lebelge

On parle de la même chose, je disais que 1024 x 1024 prend quatre fois plus de place mémoire, à la condition que le format des pixels soit identique et qu'il n'y ai pas de compression.

Je t'ai compris également.

PhM

[PhM]

Au départ on a 1x512, à l'arrivée on en a 4 (on en a donc 3 de plus, le premier on l'avait déjà)

De plus mais pas trois fois plus, maintenant je t'ai compris toi aussi :grin:.

PhM

[joloize]

Et voilà que nous assistons en direct à la réconciliation entre un Québecois d'origine Normande (si j'en crois le blason qu'il arbore !) et un Belge d'origine Africaine...

Elle est pas belle la vie ?:grin:

[lebelge]

Et voilà que nous assistons en direct à la réconciliation entre un Québecois d'origine Normande (si j'en crois le blason qu'il arbore !) et un Belge d'origine Africaine...

Elle est pas belle la vie ?:grin:

Bof.... tout cela ne va pas faire plaisir à Sarkozy :blah:

Oops... je sort -> (vite fait... et sans signer, j'ai trop honte)

[Daniel_L]

La version 4.1 tourne bien sous Windows. Je ne l'ai plantée que sur la génération de Paris (tuile +48+002). Ce qui est un peu génant pour moi c'est d'avoir le répertoire de la scène qui se génère dans celui où se trouve le fichier .osm utilisé.

Daniel

[david42fr]

Apparence OK chez moi.

Sinon, je suis arrivé à générer rhone alpes en entier mais une tuile prend particulièrement du temps, la 45 4. Pour les suivantes je ne sais pas je suis allé me coucher et la génération était terminée ce matin en me levant.

SI quelqu'un veut tester, il s'agit de la beta 4, pas la dernière puisque non sortie quand j'ai lancé. le fichier osm est celui de geofabrik d'hier.

Plus qu'à tester le lancement de xplane à mon retour voir si la scène ne provoque pas d'erreurs too many poly.....


David

Déception.... j'ai enfin pu lancé x plane ce matin et ...... rien aucun bâtiment présent.

Du coup je suis en train de relancer la génération de la tuile +45 +4 avec la dernière version mais je sens que ça va faire comme les dernières fois. Faut vraiment que je trouve comment récupérer un fichier house de la loire.

[bennyBoy]

J'ai testé cette tuile en question, c'est assez bizare ...
Deja en terme de perfs :

10:59:00 Debut traitement tuile 45 4
11:00:02 Fin traitement tuile 45 4
info : 404735 buildings  

11:00:02 Fin du traitement du fichier osm

ça me parait quand même super rapide ?
J'ai fait quelques modifs pour améliorer la vitesse mais la c'est un peu trop beau pour être vrai ^^
Pourtant le fichier txt à l'air bon, il pèse 121 mo et les bâtiments à l'intérieur ont l'air bien déclarés.
Par contre une fois xplane lancé rien sur St Étienne, rien sur Lyon...

[david42fr]

Alors là il y a vraiment un truc que je ne comprends pas. tu utilises bien le fichier geofabrik http://download.geofabrik.de/osm/eur...-alpes.osm.bz2 ? le mien fait 2 330 448 Ko .... et là j'ai :

10:37:05 Debut traitement tuile 45 4 et il est 11:31 et rien ne se passe. J'ai des accès disque mais le processus javaw.exe ne prend pratiquement pas de CPU.

Après depuis le début on a des soucis sur cette tuile.

[david42fr]

Il serait peut être mieux de créer un fil de discussion sur ton forum pour ne pas polluer ici?

[bennyBoy]

Oui n'hésite pas à créer un sujet spécifique pour qu'on puisse creuser ce point la.

[PhM]

J'ai investigué le problème de faces "à l'envers" et trouvé la solution. Il faut que les points au sol, extraits du fichier osm et servant à définir le bâtiment, forment un contour dans le sens anti-horaire lorsque vus du dessus, comme spécifié par Ben dans la documentation.

J'ai fait un exemple sur LFRK avec un bâtiment unique tout jaune, on ne peut pas le manquer, l'ordre des points entre BEGIN_WINDING et END_WINDING défini le contour dans le sens anti-horaire.

Comme on le voit sur cette image les faces sont ok ainsi que l'éclairage.

L'exemple est dans ce fichier 7z.

PhM

[Daniel_L]

La version 4.1 tourne bien sous Windows. Je ne l'ai plantée que sur la génération de Paris (tuile +48+002).

J'ai reproduit l'erreur de la tuile Paris sous Linux. Voir image jointe. C'est fait avec base de données.
J'ai sauvegardé le contenu du répertoire db mais même zippé ça fait 55 Mo...

Daniel

[bennyBoy]

@PHM oui, on en parle sur ce sujet : http://forum.osm2xp.com/index.php/topic,8.msg36.html

@Daniel étrange ce crash mémoire alors qu'il travaille sur le fichier db, sur ce mode la seule chose montée en mémoire est le bâtiment courant avant d'être écrit... je vais fouiller.

[PhM]

Pour trouver le sens de parcours des points vous pouvez calculer le barycentre, puis le produit vectoriel des vecteurs définis par le premier point de la liste et le barycentre et le dernier point de la liste et le barycentre. Le signe de la coordonnée Z du produit vectoriel indiquera le sens de parcours.

Cette méthode évite d'avoir à utiliser des fonctions trigonométriques coûteuse en temps CPU.

PhM