Ortho4XP

[Oscar Pilote]

Hummm je ne suis pas d'accord avec ce principe.
Pourquoi?
Car l'utilisation à titre privé reste privée, donc si les concepteurs sont "mort" ta scène reste donc moche ..
Orthophoto pour moi est un outil pour avoir un rendu supérieur , c'est comme si tu me demandes de te faire un nouveau toit , et je te laisse les vieilles tuiles, car c'était le propriétaire d'avant ! , c'est ta maison donc tu as le droit de changer de tuile si tu ne partages pas ta tuile chez le voisin...

Bon je dois vraiment ne pas être clair alors je précise :
selon mon point de vue voilà comment les choses devraient fonctionner
- les concepteurs de scènes s'occupent de la modélisation 3D des bâtiments (et autres) et du placement horizontal de ceux-ci (concernant le placement vertical des objets, ils
indiquent seulement une hauteur RELATIVE par rapport au maillage (j'imagine que c'est permis (?) je ne me suis encore jamais intéressé à cette partie de la modélisation) [typiquement 0 en un point d'ancrage sur l'objet situé à sa base - mais il y a des cas particuliers].
- le concepteur (mais cela peut aussi être l'utilisateur qui modifie ensuite, je l'ai fait hier soir pour Courchevel en quelques minutes puisque bien sûr elle
n'en avait pas) crée (avec JOSM en quelques clics de souris et avec la photo sat juste en dessous) un fichier de patch qui décrit des zones polygonales destinées à être aplanies par Ortho4XP, ainsi que leur altitude souhaitée (il y a aussi un type particulier pour les pistes qui ne sont pas destinées à être planes, mais pour lesquelles ont peut choisir le type de profil (plan incliné, en forme de S couché, et plus si affinités).
- Ortho4XP est programmé pour respecter ces souhaits
J'ai fait cela hier soir, finalement cela a été très simple à introduire dans le code et je suis très satisfait à la fois du résultat et de la simplicité d'utilisation. Attends de tester avant de te prononcer, tu jugeras sur pièce ;-)

Si j'ai assez de temps ce soir j'essaierai de mettre en ligne, mais comme j'ai touché au code à pas mal d'endroits
pour divers essais il faut d'abord que je remette un peu en forme.
Je te ferai aussi ton utilitaire d'assemblage désassemblage d'orthophotos, je sais que tu es impatient mais j'ai imprimé,
laisse moi seulement du temps pour le faire.

@ Pascal et Dobro : est-ce que le problème du répertoire avec espace intervient avec le code source non modifié (de mémoire j'avais mis Ortho4XP_dir = "."
en dur dans la source et plus dans le fichier de config, peut-être justement à cause de cet écueil) ou bien est-ce parce que Dobro avait modifié la source (et perdu
la garantie ) ?

[Pascal]

Le but est bien sûr que les concepteurs de scènes puissent distribuer le patch (un petit fichier texte) qui modifiera (il faudra relancer Ortho4XP)
le maillage à leur convenance en l'endroit voulu.

Si la mise à jour du DSF se fait par une commande très simple à lancer (par exemple update_dsf), c'est la solution idéale : l'usager qui télécharge la scène lance la commande et le dsf utilisé est mis à jour localement pour la scène en question.

Ce serait une excellente alternative à la solution que j'avais proposé à Ben Supnik et qui avait été refusée : pouvoir ajouter dans une scène un DSF local pour palier aux défauts du terrain sur la surface de la scène. (J'avais abordé ce problème quand j'écrivais mon éditeur de DSF : il est apparu très rapidement qu'un DSF terrain modifié pour une scène devenait mutuellement exclusif avec toute autre version modifiée pour une autre scène sur la même tuile, ce qui aurait posé des problèmes récurrents et avait entraîné la non diffusion de mon programme).


Par contre, l'utilisateur devra relancer le patcheur pour chaque scène concernée s'il change de fichier DSF pour une tuile, par exemple après mise à jour de la tuile, ou même changement d'ordre d'utilisation des tuiles dans le dossier Curstom Scenery ou dans le scenery_pack.ini, ce qui risque de rapidement devenir fastidieux pour ceux qui auraient de nombreuses scènes nécessitant des patches.

L'idéal serait que le fichier contenant les données de patch se trouve dans le dossier de la scène sous un nom unique "normalisé" (par exemple patch_dsf.txt) et qu'un programme patcheur unique parcoure automatiquement toutes les scène installées pour appliquer chaque patch dans la tuile utilisée. Ca veux dire aussi que ce programme patcheur doit être capable de déterminer quel DSF est utilisé pour chaque tuile lorsqu'il y en a plusieurs, et éventuellement être capable de patcher la tuile du Global Scenery => Fastidieux à écrire, mais pas insurmontable. En tout cas, ce serait un outil fabuleux pour les créateurs de scènes.

[Pascal]

concernant le placement vertical des objets, ils indiquent seulement une hauteur RELATIVE par rapport au maillage (j'imagine que c'est permis (?) je ne me suis encore jamais intéressé à cette partie de la modélisation) [typiquement 0 en un point d'ancrage sur l'objet situé à sa base - mais il y a des cas particuliers]

A ce que j'en sais (suite à une autre discussion avec Ben), c'est ce qui est toujours fait : le placement en Z des objets est calculé par X-Plane au moment du chargement de la scène : il place chaque objet en déterminant l'altitude du point d'ancrage par interpolation linéaire des coordonnées du triangle qui contient ce point d'ancrage pour la V9 ou de la table rester altitude pour la V10.

C'était le cas seulement pour les objets en V9, et ca a été étendu aux routes et autres données dans la V10, pour tous les points des "Pool" qui n'ont plus de coordonnée en Z mais l'unique valeur -32768 (FFFF). C'est pour faciliter et accélérer cette opération que les tuiles V10 intègrent le raster altitude (la V9 générait en interne un quadtree des triangles du mesh pour retrouver dans quel triangle se trouve le point de référence de chaque objet !)

[atanorr]

@OScar,
entre les tuiles 51 002 avec masque et 50 001 avec masque , la tuile en bas à droite n'est pas encore faite 50 002 ni la tuile 51 001, haut gauche
Je n'arrive pas à supprimer un triangle à gauche de la tuile 51 002 donc le triangle à partir de la tuile supérieur droite , dans le coin de gauche donc à la jonction, vas t'il disparaître automatiquement grâce aux 2 tuiles manquantes..? Pourtant mon masque est bien réalisé , il suit bien le banc de sable..

Perso si vous voulez je fait un tuto pour les masques ;) ça va super vite ;)

[Dobro]

Perso si vous voulez je fait un tuto pour les masques ;) ça va super vite ;)

sans vouloir te commander , c'est toujours bon a prendre

@Oscar , pour ton "." si je l'ai changé c'est que ça ne devait pas marcher pour moi
j'ai du mettre le chemin absolu ...

je referai un essai .. je te tiens au jus

[Mclnight]

Salut oscar,
Je viens de tomber sur ce post dans le ORG, http://forums.x-plane.org/index.php?showtopic=81152

Un outil qui converti le mesh en objet 3D permettant de le modifier à souhait sur AC3D ou autre...

[atanorr]

Salut oscar,
Je viens de tomber sur ce post dans le ORG, http://forums.x-plane.org/index.php?showtopic=81152

Un outil qui converti le mesh en objet 3D permettant de le modifier à souhait sur AC3D ou autre...

C'était celui-là que j'avais remarqué;) merci pour le lien je ne le retrouvais plus

Du coup possible modification du mesh contour des Aéroports en pente ;) Bravo de retrouver le lien Mclnight

[Mclnight]

Quand je suis tombé dessus me suis dit, tiens ça doit être ce logiciel dont Atanorr a parlé 😊

[Oscar Pilote]

L'idéal serait que le fichier contenant les données de patch se trouve dans le dossier de la scène sous un nom unique "normalisé" (par exemple patch_dsf.txt) et qu'un programme patcheur unique parcoure automatiquement toutes les scène installées pour appliquer chaque patch dans la tuile utilisée. Ca veux dire aussi que ce programme patcheur doit être capable de déterminer quel DSF est utilisé pour chaque tuile lorsqu'il y en a plusieurs, et éventuellement être capable de patcher la tuile du Global Scenery => Fastidieux à écrire, mais pas insurmontable. En tout cas, ce serait un outil fabuleux pour les créateurs de scènes.

Il y a une chose à bien comprendre : dans la solution que je propose ce n'est pas le patch qui cherche sa tuile, mais la tuile qui cherche ses patchs.
Il ne s'agit pas d'un traitement a posteriori des dsf, mais au contraire le traitement des patchs intervient au tout début du processus d'Ortho4XP (à l'étape 1),
il est à mettre sur le même pied d'égalité que la définition des arêtes sol/eau, simplement au lieu de lire les infos sur openstreetmap comme pour l'eau je les
lis dans les fichiers .patch.osm (c'est le nom barbare que j'ai choisi...). L'étape 1 est l'étape où je définis les "arêtes requises" pour le maillage, et les tags
associés aux régions que délimitent ces arêtes (par exemple pour une zone destinée à être aplanie, le tag est simplement l'altitude souhaitée).
En particulier, puisque ce n'est pas un patch a posteriori sur le dsf, mais une procédure interne au maillage, cela ne s'applique a priori qu'aux maillages que
crée Ortho4xp (j'aurais une autre solution à proposer pour les autres maillages, mais il faudrait que je la code et elle est serait moins commode à utiliser
(il faudrait bouger les points du maillage un par un), et certainement moins commode que ton outil).
Pour ce qui est du traitement des patchs "en groupes", à l'étape 1 Ortho4XP lit tour à tour tous les fichiers à extension .patch.osm contenus dans le répertoire
Patches du répertoire maître d'Ortho4XP (mais cela pourrait être modifié en la lecture de tous les fichiers des répertoires Patches n'importe où sur les disques,
ou seulement dans les sous-répertoires du scenery_pack par exemple) et applique le patch en question. Un patch n'est pas forcément attaché à une tuile, c'est
juste un fichier qui contient des zones polygonales avec des altitudes cibles, si elle sont hors de la tuile en construction elles sont simplement ignorées.

Pour l'exemple (je ne suis pas certain que ce soit très éclairant...) voici le contenu du fichier LFLJ.patch.osm que j'ai créé hier. Cela peut paraître barbare mais les
seules données que j'ai du entrer sont en fait les points (en cliquant à la souris) et les tags (au clavier) dans JOSM, cela prend 3 minutes (peut-être pas la
première fois... je ferai une vidéo quand j'aurai mis la source en ligne).
JOSM est l'outil le plus utilisé pour entrer des données sur openstreetmap, là je ne les uploades pas (je peux ainsi faire ce que bon me semble)
mais je les enregistre localement (le fichier ci-dessous) pour les utiliser. Ce qui peut être le plus délicat c'est de déterminer les bonnes altitudes
(mais c'est immédiat à éditer a posteriori), hier j'ai pris ma Top 25 et les chiffres ci-dessus sont ceux de ma première tentative). Le premier "way" à 1925m
correspond à un pâté de maisons en aval à gauche de la piste, le second à 2025m est le gros batîment en amont de la piste et en bas des pistes de ski, celui à
1990m des maisons en contre bas de la tour, celui à 2010 est le bar qui jouxte la piste en haut à gauche, celui à 2000 engloble tout l'apron et la partie plane
haute de la piste, et le dernier (d'un type différent : tags altitude_high, altitude_low et profile) concerne la piste (en dehors de la partie plane sommitale), entre les
altitdes 2000m et 1945m.

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='true' generator='JOSM'>
  <node id='-1898' action='modify' visible='true' lat='45.39996825813' lon='6.634591968' />
  <node id='-1896' action='modify' visible='true' lat='45.39961133255' lon='6.63473612079' />
  <node id='-1894' action='modify' visible='true' lat='45.39961665982' lon='6.63531273197' />
  <node id='-1892' action='modify' visible='true' lat='45.39987769514' lon='6.63563138551' />
  <node id='-1890' action='modify' visible='true' lat='45.40038378059' lon='6.63566173347' />
  <node id='-1888' action='modify' visible='true' lat='45.40063415803' lon='6.63497131746' />
  <node id='-1887' action='modify' visible='true' lat='45.40027190946' lon='6.63467542488' />
  <node id='-1883' action='modify' visible='true' lat='45.3947153646' lon='6.63214137049' />
  <node id='-1881' action='modify' visible='true' lat='45.39511494263' lon='6.63252071995' />
  <node id='-1879' action='modify' visible='true' lat='45.39489117928' lon='6.63326424489' />
  <node id='-1878' action='modify' visible='true' lat='45.3944010279' lon='6.6325586549' />
  <node id='-1874' action='modify' visible='true' lat='45.39488585157' lon='6.635987974' />
  <node id='-1872' action='modify' visible='true' lat='45.39519485789' lon='6.63632180153' />
  <node id='-1870' action='modify' visible='true' lat='45.39571696818' lon='6.6356389725' />
  <node id='-1869' action='modify' visible='true' lat='45.39541862004' lon='6.63522927509' />
  <node id='-1865' action='modify' visible='true' lat='45.39658003788' lon='6.63253589393' />
  <node id='-1863' action='modify' visible='true' lat='45.39688903494' lon='6.63215654447' />
  <node id='-1861' action='modify' visible='true' lat='45.3966386409' lon='6.63170132512' />
  <node id='-1860' action='modify' visible='true' lat='45.39632964248' lon='6.63214895748' />
  <node id='-1855' action='modify' visible='true' lat='45.39728327011' lon='6.63286972145' />
  <node id='-1853' action='modify' visible='true' lat='45.39698493024' lon='6.63236139318' />
  <node id='-1851' action='modify' visible='true' lat='45.39656938278' lon='6.63266487275' />
  <node id='-1849' action='modify' visible='true' lat='45.39626038398' lon='6.63282419952' />
  <node id='-1847' action='modify' visible='true' lat='45.39591941781' lon='6.63238415415' />
  <node id='-1845' action='modify' visible='true' lat='45.39566369184' lon='6.63276350361' />
  <node id='-1843' action='modify' visible='true' lat='45.39546656895' lon='6.633188375' />
  <node id='-1841' action='modify' visible='true' lat='45.39537067108' lon='6.63364359435' />
  <node id='-1839' action='modify' visible='true' lat='45.39543993067' lon='6.63391672596' />
  <node id='-1837' action='modify' visible='true' lat='45.39575958922' lon='6.63433401036' />
  <node id='-1835' action='modify' visible='true' lat='45.39581819309' lon='6.63470577283' />
  <node id='-1833' action='modify' visible='true' lat='45.39614317709' lon='6.63490303455' />
  <node id='-1831' action='modify' visible='true' lat='45.39638824576' lon='6.63456920703' />
  <node id='-1829' action='modify' visible='true' lat='45.39619112539' lon='6.63429607542' />
  <node id='-1824' action='modify' visible='true' lat='45.39641488359' lon='6.63404570478' />
  <node id='-1822' action='modify' visible='true' lat='45.39909991287' lon='6.63771780754' />
  <node id='-1820' action='modify' visible='true' lat='45.39951544172' lon='6.63710326141' />
  <node id='-1819' action='modify' visible='true' lat='45.39685706981' lon='6.63342357166' />
  <way id='-1889' action='modify' visible='true'>
    <nd ref='-1887' />
    <nd ref='-1888' />
    <nd ref='-1890' />
    <nd ref='-1892' />
    <nd ref='-1894' />
    <nd ref='-1896' />
    <nd ref='-1898' />
    <nd ref='-1887' />
    <tag k='altitude' v='1925' />
  </way>
  <way id='-1880' action='modify' visible='true'>
    <nd ref='-1878' />
    <nd ref='-1879' />
    <nd ref='-1881' />
    <nd ref='-1883' />
    <nd ref='-1878' />
    <tag k='altitude' v='2025' />
  </way>
  <way id='-1871' action='modify' visible='true'>
    <nd ref='-1869' />
    <nd ref='-1870' />
    <nd ref='-1872' />
    <nd ref='-1874' />
    <nd ref='-1869' />
    <tag k='altitude' v='1990' />
  </way>
  <way id='-1862' action='modify' visible='true'>
    <nd ref='-1860' />
    <nd ref='-1861' />
    <nd ref='-1863' />
    <nd ref='-1865' />
    <nd ref='-1860' />
    <tag k='altitude' v='2010' />
  </way>
  <way id='-1830' action='modify' visible='true'>
    <nd ref='-1824' />
    <nd ref='-1829' />
    <nd ref='-1831' />
    <nd ref='-1833' />
    <nd ref='-1835' />
    <nd ref='-1837' />
    <nd ref='-1839' />
    <nd ref='-1841' />
    <nd ref='-1843' />
    <nd ref='-1845' />
    <nd ref='-1847' />
    <nd ref='-1849' />
    <nd ref='-1851' />
    <nd ref='-1853' />
    <nd ref='-1855' />
    <nd ref='-1819' />
    <nd ref='-1824' />
    <tag k='altitude' v='2000' />
  </way>
  <way id='-1821' action='modify' visible='true'>
    <nd ref='-1819' />
    <nd ref='-1820' />
    <nd ref='-1822' />
    <nd ref='-1824' />
    <nd ref='-1819' />
    <tag k='altitude_low' v='1945' />
    <tag k='altitude_high' v='2000' />
    <tag k='profile' v='atanh' />
  </way>
</osm>

Cette solution permet aussi facilement de palier aux aéroports "plats" mais dont les frontières n'ont pas été encodées dans openstreetmap, il n'est alors
pas crucial d'en suivre méticuleusement les contours mais il suffit de tracer un polygône rudimentaire à la souris (je vais adopter cette solution pour Orly
juste pour l'exemple).

[Dobro]

ça fait un moment que je cherche une info, que je n'arrive pas a trouver


les tuiles types +45 +004 << ces valeurs, ça correspond a quoi comme format ? c'est pas du WG84 .. ni du UTM

si je voulais faire une carte du monde, reprenant ce genre de quadrillage , faudrait que je m'y prenne comment ? (pour le quadrillage )

y a t'il quelque part sur le Net une carte (toute faite) qui reprenne ce genre de quadrillage mais recouvrant la Totalité du monde ? (pas celle de Zone Photo qui n'est pas complete )

[guro]

y a-t-il quelque part sur le Net une carte (toute faite) qui reprenne ce genre de quadrillage mais recouvrant la Totalité du monde ? (pas celle de Zone Photo qui n'est pas complète )

Bonjour

Pascal a ajouté une fonction depuis un certain temps " le Graticule" qui te permet de voir n'importe quadrillage et de plus tu as aussi les coordonnées du lieu (en haut à gauche juste au-dessus de la carte)que tu choisirais ......



Ça devrait convenir ....

Gunther

[Oscar Pilote]

les tuiles types +45 +004 << ces valeurs, ça correspond a quoi comme format ? c'est pas du WG84 .. ni du UTM

si je voulais faire une carte du monde, reprenant ce genre de quadrillage , faudrait que je m'y prenne comment ? (pour le quadrillage )

Si, c'est du WGS84. Tu prends la terre (comme une orange), tu l'entoures d'une feuille de papier en forme de cylindre (l'axe passant
par les pôles étant confondu avec l'axe du cylindre), et tu projettes chaque point de la surface de la terre sur la feuille de papier
en traçant la demi-droite qui part du centre de la terre et qui passe par le point en question. Ensuite tu déplies le cylindre.
Tu vois bien que les pôles n'ont pas de projection, ou bien on dit qu'ils se projettent à l'infini : pour représenter la terre suivant
cette projection (projection de type Mercator) il faudrait donc une feuille infinie en hauteur. En pratique, on coupe donc toujours en haut
et en bas (et sur aucune carte de tes atlas en projection Mercator tu ne verras les pôles, si tu as l'impression que si regarde bien
les annotations des parallèles), il est fréquent de couper vers 85° ce qui donne une carte carrée (et les tuiles d'X-Plane s'arrêtent
aussi à cet endroit je crois, pas question de jouer à l'amiral Peary. Par ailleurs ce n'est pas
exactement la surface de la terre que l'on projette (trop complexe et sans intérêt) mais une approximation par une patate de référence
(un géoïde), et WGS84 correspond à une patate qui a été définie en 1984. Avant il y avait une patate de 1919 je crois. Si tu avais pris
un axe autre que celui passant par les pôles, tu aurait obtenu de l'UTM (T pour transverse et M pour Mercator). Avant cette normalisation
(et encore souvent maintenant pour beaucoup de raisons) chaque pays avait son propre standard (en France le Lambert 93, qui
correspond en gros à remplacer le cylindre par un chapeau pointu (un cône)), et qui est utilisé dans beaucoup des données de l'IGN).

Mais donc la réponse à ta deuxième question est : tu ne peux pas t'y prendre, à moins d'avoir un écran avec une résolution infinie en
hauteur...

[Odevillée]

y a t'il quelque part sur le Net une carte (toute faite) qui reprenne ce genre de quadrillage mais recouvrant la Totalité du monde ? (pas celle de Zone Photo qui n'est pas complete )

http://www.goeldenitz.org/map_grid.html#zoomIn

http://wiki.x-plane.fr/images/4/47/X-Plane_world.jpg

[jasum]

- le concepteur (mais cela peut aussi être l'utilisateur qui modifie ensuite, je l'ai fait hier soir pour Courchevel en quelques minutes puisque bien sûr elle
n'en avait pas) crée (avec JOSM en quelques clics de souris et avec la photo sat juste en dessous) un fichier de patch qui décrit des zones polygonales destinées à être aplanies par Ortho4XP, ainsi que leur altitude souhaitée (il y a aussi un type particulier pour les pistes qui ne sont pas destinées à être planes, mais pour lesquelles ont peut choisir le type de profil (plan incliné, en forme de S couché, et plus si affinités).

Pour moi cela serait une solution parfaite.

[Oscar Pilote]

Concernant les deux autres utilitaires mentionnés :

XMeshCore dit : "Remember - program does not create additional points of mesh (it's impossible) - only changes elevation of existing one."
et
Mesh Remexe dit :"Selecione o arquivo dsf.txt (com elevação corrigida)" click on "selecionar" an select the file with the elevation corrected (with the extension “_fix.txt”)

Autrement dit ces deux utilitaires peuvent changer l'altitude des points du maillage, mais pas leur positionnement horizontal ou en ajouter là ou nécessaire (et le premier
dit que c'est impossible, il est vrai qu'il est russe, pas français). Si un triangle est trop grand et mal incliné, en changer l'altitude des sommets ne résoudra pas vraiment le
problème, et en créera d'autres. Ce que je propose est me semble-t-il plus simple et plus efficace.

En deux mots voilà la raison de leurs difficultés :

La "bonne" manière de stocker l'information d'un maillage avec K sommets et N triangles est la suivante
(il existe 36 formats mais ils ne diffèrent que dans les détails) :

Liste de sommets :
S1 x1 y1 z1 -> le sommet d'indice S1 (un nombre entier, souvent S1=1,S2=2 etc) a pour coordonnées (x1,y1,z1 qui sont trois nombres à virgule)
S2 x2 y2 z2
S3 x3 y3 z3
...
SK xK yK zK

Liste des triangles :
T1 S_(1,1) S_(1,2) S_(1,3) -> le triangle T1 repose sur les sommets d'indices S_(1,1) S_(1,2) et S_(1,3) (qui sont donc trois nombres entiers entre 1 et K)
T2 S_(2,1) S_(2,2) S_(2,3)
...
TN S_(N,1) S_(N,2) S_(N,3)

La "mauvaise" façon de stocker un maillage, celle utilisée par X-Plane dans la version "texte" des DSF, est la suivante :

T1 (x_(1,1),y_(1,1),z_(1,1)) (x_(1,2),y_(1,2),z_(1,2)) (x_(1,3),y(1,3),z(1,3))
T2 (x_(2,1),y_(2,1),z_(2,1)) (x_(2,2),y_(2,2),z_(2,2)) (x_(2,3),y(2,3),z(2,3))
...
TN (x_(N,1),y_(N,1),z_(N,1)) (x_(N,2),y_(N,2),z_(N,2)) (x_(N,3),y(N,3),z(N,3))

-> on ne décrit que les triangles en donnant la liste entière des coordonnées de leurs sommets (c'est en gros ce qu'X-Plane appelle des primitives)

Avec la "bonne" méthode, quand on modifie les coordonnées d'un sommet S_j, cela se répercute automatiquement dans tous les triangles
qui possèdent ce sommet (puisque ce ne sont que des labels vers des points), et donc il n'y a aucun risque de "déchirer" le maillage.
Au contraire, avec la "mauvaise" méthode, si on bouge certaines coordonnées d'un triangle, il faut chercher tous les autres triangles qui
auraient aussi un point de même coordonnée (avec le danger des erreurs d'arrondi, d'où les fameuses Point Pools de DSFTool qui ne sont
qu'une manière compliquée de se réengager dans la bonne voie - et uniquement au niveau des DSF binaires) afin de ne pas déchirer le maillage.
C'est plus compliqué et moins efficace.

Dans Ortho4XP, je travaille uniquement avec des maillages stockés sous la première forme, et ce n'est qu'à l'ultime instant que je
les traduit dans le "mauvais" format que requièrent les DSF.
Ben Supnik ne pouvait pas non plus être spécialiste dans tous les domaines, il déjà épatant de voir la quantité de domaines du jeu
qu'il gère à la fois (par contre, comme l'a dit Milan, il fait volontiers la sourde oreille!)