Bande noire/blanche rectangulaire dans Masks — indépendant du DEM

[hervesolaris]

Description

Sur une tuile contenant une rivière (pas de mer, pas de littoral), le générateur de masques
"eau transparente XP12" étiquette la zone comme [Coastal] et applique les paramètres
foam/falloff/noise/peak par défaut. Le mask PNG généré ne suit pas la géométrie réelle de la
rivière : il produit une séparation parfaitement rectiligne et horizontale entre une moitié
blanche (haut) et une moitié noire (bas) de l'image, ce qui ne correspond à aucune forme
géographique plausible.

Ce qui a déjà été testé (sans effet sur le bug)

• Changement de source DEM
  Triangulate 3D Mesh complet → aucun changement sur la position/forme de la bande.
• masks_use_DEM_too : False (donc l'option d'affinement DEM de l'ancien système de masques
  n'est pas en cause).

Pourquoi ça semble être un bug de code plutôt qu'un problème de données

La ligne de séparation est parfaitement droite et identique avant/après changement de DEM.
Une géométrie de rivière réelle (ou un artefact DEM) bougerait ou changerait de forme avec
une source d'élévation différente. Ici rien ne change, ce qui suggère que la position de la
bande est calculée indépendamment des données de terrain réelles — possiblement un buffer
d'image partiellement rempli, ou un fallback qui dessine un rectangle englobant au lieu du
contour réel de la rivière.

Environnement

• Version : ORTHO4XP_V3.3
• OS :Mac OS SONOMA
• Tuile : 48+000 (Normandy/France)

Image jointe

[hervesolaris]

when I put MASK FOR ISLAND : False...it's ok because no more masks....but it will be good to know what is the problem ! 😉

[hervesolaris]

nobody to help ? 😅

[Ypsos]

Je cherche

I'm looking for

[Ypsos]

Hello

Thank you for the report.

I have entered on my list the corrections to be made in the meantime.

Where exactly does the problem come from

In version V3.3 (adapted for X-Plane 12):

XP12 mask generation: X-Plane 12 manages water bathymetry and transparency differently from XP11. Ortho4XP V3 modifies the way transparency (Alpha channel of the mask) is calculated from OSM (waterway=river, natural=water) data.

Script incompatibility: On macOS (including Sonoma), some versions of Python libraries (Pillow/PIL or GDAL) treat 1-channel binary masks (L or 1) differently. The filling of an unclosed or out-of-bound polygon falls on a default bounding box that cuts the image in half.

What to remember & Solutions

Your bypass (Mask for the island: False):

This is the right temporary manipulation to unlock the tile. By disabling the custom mask, Ortho4XP allows X-Plane 12 to apply its own default water shader to rivers rasterized by OpenStreetMap data.

For interior tiles (rivers only):

In X-Plane 12, the complex Ortho4XP water masks are only really useful for the coast/sea (to make beautiful depth gradients and see the seabed). For continental rivers in France (such as the +48+000 tile), leaving the masks disabled or using the default water of XP12 gives a very clean rendering without risking this bug.

Bonjour

Merci pour le signalement.
j'ai inscrit sur ma liste des correction a réaliser en attendant.

D'où vient précisément le problème
Dans la version V3.3 (adaptée pour X-Plane 12) :
Génération des masques XP12 : X-Plane 12 gère la bathymétrie et la transparence de l'eau différemment de XP11. Ortho4XP V3 modifie la façon dont la transparence (canal Alpha du masque) est calculée à partir des données OSM (waterway=river, natural=water).
Incompatibilité de script : Sous macOS (notamment Sonoma), certaines versions des bibliothèques Python (Pillow/PIL ou GDAL) traitent différemment les masques binaires à 1 canal (L ou 1). Le remplissage d'un polygone non fermé ou hors-limite retombe sur un bounding box par défaut qui coupe l'image en deux.
Que retenir & Solutions
Votre contournement (Masque pour l'île : Faux) :
C'est la bonne manipulation temporaire pour débloquer la tuile. En désactivant le masque personnalisé, Ortho4XP laisse X-Plane 12 appliquer son propre shader d'eau par défaut sur les rivières rasterisées par les données OpenStreetMap.
Pour les tuiles d'intérieur (rivières uniquement) :
Dans X-Plane 12, les masques d'eau Ortho4XP complexes ne sont réellement utiles que pour le littoral/mer (pour faire de beaux dégradés de profondeur et voir le fond marin). Pour les rivières continentales en France (comme la tuile +48+000), laisser les masques désactivés ou utiliser l'eau par défaut d'XP12 donne un rendu très propre sans risquer ce bug.

[Ypsos]

Je vien de faire vérifier le foicheoir par Claude IA voici son analyse il n'identifie aucun problème de codage.
Les correctifs proposés (Fix #1, #2, #3) ne correspondent pas à ce fichier.
Ils parlent de fonctions et de variables qui n'existent nulle part dans le vrai code : build_water_mask(), water_progression, xp12_transparent_water, has_ocean, water_boundary_polygons, river_polygons, is_coastal, une étiquette [Coastal], et des effets « mousse / chute / bruit / pic ». Rien de tout cela n'est présent dans O4_Mask_Utils.py. Ce texte décrit un autre logiciel.

Par contre pour la jointure linéaire:
Les quatre coins sont les angles WGS84 de la tuile voisine (lat/lon, lat/lon+1, etc.). Une arête de ce quadrilatère qui suit une latitude constante (bord nord ou sud d'une tuile) devient, en projection Web Mercator locale, une droite horizontale. Ensuite les triangles de mer (dico_sea) repeignent en noir par-dessus.
Donc si, pour la tuile fluviale, un seul mesh voisin remplit du blanc mais que les triangles d'eau noirs ne couvrent qu'une partie, on obtient exactement ce que décrit l'utilisateur : blanc en haut / noir en bas, frontière parfaitement droite, alignée sur un bord de tuile. Et c'est cohérent avec « ça ne bouge pas quand on change le DEM » : cette frontière ne dépend d'aucune donnée d'altitude, uniquement de la présence/absence de meshes voisins et de la répartition des triangles d'eau.
C'est la piste la plus solide au vu du code. Elle reste à confirmer sur les données réelles de la tuile +48+000 (quels meshes voisins présents, quels triangles marqués eau) — L'utilisateur n'a plus le souci si l'option mask est désactivé pour les tuiles sans bord de mer.

[Ypsos]

Lorsque use_masks_for_inland est sur false pas de mask c'est normal
sr use_masks_for_inland est sur true = mask fabriqué

Correction faite dans fichiers masks.py

La prochaine mise a jour intégrera le correctif. ( cette nuit)