Dégradé de couleur mal orienté avec iTowns et Potree2Layer (displayMode: "elevation")

[Aymar1016]

Bonjour,

Je travaille actuellement sur un projet de visualisation 3D avec iTowns, dans lequel j’affiche un nuage de points via Potree2Layer. J’utilise le displayMode: "elevation" pour styliser le nuage en fonction de l’altitude.

Cependant, j’ai remarqué que le dégradé de couleurs semble s’appliquer de manière horizontale, comme si la variation se faisait sur l’axe X ou Y, plutôt que sur l’axe vertical (Z). Cela donne l’impression que la coloration ne reflète pas correctement les différences d’altitude réelle.

Je voulais savoir :

Est-ce un comportement attendu ?

Y a-t-il un paramètre ou une projection spécifique à configurer pour que le displayMode: "elevation" utilise bien l’axe vertical (Z) comme référence ?

Est-ce lié au système de coordonnées (j’utilise EPSG:4978) ou à la structure du nuage généré avec PotreeConverter v2 ?

Merci d’avance pour votre aide !

Illan

[Desplandis]

Bonjour,

Normalement la coloration se fait selon l'axe z, peut-être une rotation de ton jeu de données nuage de point issu de PotreeConverter ? Si tu as un jeu de donnée pour tester, on pourrait regarder. =)

[Aymar1016]

bonjour , merci pour votre réponse. Cependant je ne sais pas trop comment vous envoyer mon nuage de points vu que github ne permet pas de joindre un fichier .bin

[Desplandis]

Peut-être un hébergeur qui pourrait te stocker toute la hierarchie sous une archive ?

[Aymar1016]

Voici en lien menant à un dossier contenant mon nuage de points en .las et le dossier obtenu après la conversation avec potree Converter : https://drive.google.com/drive/folders/1kUydCNSBxyKVc2mtI9XUr4mX2HrpzhsJ?usp=drive_link .
Et pour revenir au problème avec le displayMode:"ELEVATION" , j'ai constaté le même problème avec l'exemple "Potree 3D map" disponible sur le site iTowns : https://www.itowns-project.org/

[ftoromanoff]

Actuellement l'exemple potree 3D map affiche des données potree qui sont dans le même référentiel que la vue globe c'est à dire EPSG 4978, qui est un système géocentrique. Ce qui fait que le z des données n'est pas du tout aligné avec l'élévation locale, d'où l'impression d'une colorisation selon les autres axes.
Une PR est en cours pour améliorer et réussir à afficher des jeux de données qui ne sont pas directement dans le système de projection géocentrique.
Serait il possible d'avoir accès a ton jeu de données ? Mais si celui ci est en 4978, le probleme sera le meme. Il faudrait avoir accés a un jeu de données en projection locale (avec un z aligné avec l'élévation locale)
Merci d'avance

[ftoromanoff]

Le jeu de données est en 4978. Comme l'on peut voir ci après l'axe des z n'est pas du tout aligné avec l'élévation 'vraie'. iTowns se passe sur le z des données pour faire sa palette de couleur, se qui amène au 'bug' décrit au premier message.

Il faudrait recupere les données dans leur crs originel (avant reprojection en géocentrique).
@Aymar1016 Aurais tu moyen d'avoir les données en crs natif ? (et leur version potree ?)

[Aymar1016]

Bonjour et merci beaucoup pour vos retours détaillés !

Effectivement, en comparant le nuage de points avant et après la conversion avec PotreeConverter (via Anaconda Prompt), j’ai pu constater que les axes changent de comportement. Je vais ajouter des captures d’écran pour illustrer cela plus précisément.

Comme vous l’avez justement souligné, mes données sont initialement en Lambert 93 (EPSG:2154), et je les ai reprojetées en EPSG:4978 afin de les positionner correctement sur un globe dans iTowns. Ce passage en géocentrique semble effectivement fausser la référence verticale pour la colorisation par displayMode: "elevation".

Cela dit, comme mon objectif est d’intégrer ces nuages sur un globe 3D, je me demande s’il serait pertinent de générer les fichiers Potree directement à partir des données en Lambert 93, et de confier la reprojection à iTowns au moment de l’affichage.

Auriez-vous des suggestions ou idées sur la meilleure manière de procéder dans ce cas ? Est-ce qu’une telle approche permettrait de conserver un axe Z local cohérent avec l’élévation réelle tout en s’intégrant correctement dans la vue EPSG:4978 d’iTowns ?

Merci encore pour votre aide !

[ftoromanoff]

Bonjour,

Pourriez vous me faire parvenir votre nuage de point potree en Lambert 93 ?
Je travail actuellement sur une PR qui permettrait de faire exactement ce que vous suggérez (confier la reprojection a iTowns, et ce pour tous les format de nuage de point : entwine, copc et potree) PR #2498.
Mais pour le moment le format potree et le moins bien géré (n'ayant pas accès a un bon jeu de données).

[ftoromanoff]

@Aymar1016 Dans le dossier partagé, je ne trouve pas le fichier originel en Lambert 93 (EPSG:2154), ni potree ni las..

[Aymar1016]

Bonjour,

Merci pour votre retour !
Voici le lien vers le dossier contenant le nuage de points en Lambert 93 (EPSG:2154), au format .las ainsi que la version convertie avec PotreeConverter :
https://drive.google.com/drive/folders/13GBPLjvYSzrPH0nZLMVfoBN9z7wB6O4v?usp=sharing
N'hésitez pas à me dire s’il manque des fichiers ou si vous avez besoin d'autres formats.
Merci encore pour votre aide !

[ftoromanoff]

Si jamais vous avez possibilité de fournir le même jeu au format potree 1 ca serait super pour mes tests.
J'ai commencé a regarder pour prendre en compte le format potree2 avec une reprojection faite par itowns, mais je n'ai pas pu finir et je pars en vacances. Je continuerais a regarder ca a mon retour.

PS: En attendant si vous avez possibilité de convertir votre jeu las en entwine ou copc, ses formats sont mieux gérer. Et en vous basant sur ma branche, vous pouvez les intégrer en crs 2154 directement dans une vue globe.

[Aymar1016]

J’ai ajouté le fichier converti avec Potree1 comme vous me l’aviez demandé :
https://drive.google.com/drive/folders/13GBPLjvYSzrPH0nZLMVfoBN9z7wB6O4v?usp=sharing