Sélection et traitement de nuages de points via octrees

[PierreGEOSCAN3D]

Bonjour,

Ma méthode actuelle pour manipuler de grands nuages de points s'appuie sur un système de tiling avec génération de proxy.

Pour chaque tuile du nuage, je crée un proxy en réduisant le nombre de points par échantillonnage. Cela permet d'alléger l'affichage graphique et de rendre la navigation plus fluide. Ainsi, pour chaque tuile, je possède à la fois le nuage complet et son proxy réduit. Lorsque je navigue, je désactive temporairement le nuage complet et j'active uniquement le proxy correspondant pour trouver les zones d'intérêt. Ensuite, je bascule entre le proxy et le nuage complet pour effectuer divers traitements.

Pour optimiser cette approche, j'ai pensé à une seconde méthode. Après avoir calculé les octrees pour chaque tuile, je désactive le nuage de points et active les octrees, visibles sous forme de points. Cela me permet de manipuler plus facilement le nuage tout en ajustant l'affichage de manière interactive.

Serait-il possible de permettre la sélection et le traitement du nuage de points via les octrees ? Par exemple, sélectionner un octree à un certain niveau pourrait, en arrière-plan, sélectionner automatiquement les points contenus dans ces octants ?. Cela permettrait de supprimer l'étape de création des "proxies".

De plus, est-il envisageable d'afficher dynamiquement les niveaux de détail des octants en fonction de la distance à la caméra ? Par exemple, afficher les octants avec un niveau de détail 10 dans un rayon de 100 mètres autour de la caméra, et avec un niveau 3 au-delà de 300 mètres.

Avez-vous une estimation du temps nécessaire pour développer cette fonctionnalité ? Et éventuellement une idée du coût envisagé pour son développement ?

Merci d'avance pour vos retours et suggestions.
Cordialement,
Pierre

[daniel]

Alors je tente : c'est à peu près ce que fait le mécanisme de LoD (Level of Detail) automatique pour les gros nuages. Celui qui s'active par défaut au delà d'un nombre custom de points si l'option 'When moved, decimate clouds over XXX points' dans le dialogue "Display > Display parameters".

Ca ne vous convient pas ?

[PierreGEOSCAN3D]

Bonjour Daniel,

Merci pour votre réponse. En effet, j'avais complètement omis cette option, qui est largement suffisante pour de nombreux traitements et utilisateurs.


Cependant, je reste pour le moment convaincu par l'utilisation des octrees à un niveau plus avancé. À titre d'exemple, l'intégration récente du format copc.las dans QGIS a, selon moi, apporté une véritable valeur ajoutée, sans oublier le viewer Potree. Pensez-vous que CloudCompare pourrait, à terme, prendre en charge ce type de format et ainsi permettre une complémentarité entre ces deux merveilleux logiciels ?

Je suis conscient que CloudCompare est un logiciel généraliste, orienté principalement vers une dimension "discrète", et que son développement a surtout été axé sur des applications comme l'auscultation, le suivi ou le dimensionnement. Je comprends également que le besoin d'afficher l'intégralité des points est essentiel dans ces contextes. Cependant, avec l'essor du mobile mapping — qui tend à devenir une norme pour les relevés sur une échelle territoriale — la nécessité d'afficher tous les points devient moins pertinente. Une fonctionnalité permettant de gérer automatiquement et de manière fluide les zones d'intérêt dans une dimension continue pourrait donc être un atout.

Peut-être que ce n'est pas dans la feuille de route de CloudCompare, et auquel cas, tout cela serait sans objet. Quoi qu'il en soit, CloudCompare reste un outil exceptionnel qui répond déjà à un très grand nombre de besoins dans notre domaine.

Encore Merci !
Pierre

[daniel]

Alors ce n'est pas exclu, et nous avons discuté avec Howard Butler de l'integration du format COPC. C'est par contre énormément de travail, et il faut qu'un contributeur (développeur) se porte volontaire pour le faire !

[PierreGEOSCAN3D]

Ce développement pourrait-il éventuellement être accéléré par une campagne de dons ?
Si oui, auriez-vous une estimation du temps nécessaire et du budget ?
Le sujet pouvant être sensible pour certains, il serait peut-être préférable d’en discuter autrement?.

Qui sait, cette mise à jour pourrait peut-être faire passer CloudCompare à la version 3.0 :)

[daniel]

Ah je ne sais pas, c'est avant tout une question de personne, mais j'imagine que certains seraient plus enclin à collaborer avec un soutient financier... Il faudrait qu'on ait un moyen d'appeler aux contributions avec ou sans don.

C'est aussi un gros chantier, donc ça peut en effet mener à un changement de génération ;)

[PierreGEOSCAN3D]

Très bien. Pourriez-vous me fournir une liste des compétences recherchées ? Un développeur Cpp est-il suffisant ? Si je trouve des développeurs, quelles ressources dois-je leur transmettre pour obtenir une première estimation du travail à réaliser ?
Et surtout, quel serait l'ordre de mission à leur confier ? Par exemple, "'intégration du format COPC et mise à jour du moteur de rendu graphique" ?

[daniel]

Oui un développeur C++ avec une connaissance idéalement de Qt et OpenGL.

Pour le travail, ça dépend de vos ambitions.

1) Si ce n'est que de l'affichage, alors ça peut rester relativement simple en créant une nouvelle entité dans CloudCompare qui serait une sorte de "Virtual cloud" qui ne peut qu'être affichée (en utilisant la structure octree intégrée au format COPC et avec un chargement intelligent des points 'visibles' à partir du disque quand nécessaire - ce qui mèle les concepts de LoD (pour Level of Detail) et de Out of Core.

2) Après vous pouvez aller plus loin et permettre à l'utilisateur de convertir un tel "virtual cloud" en un vrai nuage. Car sinon les traitements de CloudCompare ne seront pas accessibles ... Ca va sans doute de paire avec la modification de certains outils pour travailler directement sur ces "virtual clouds" comme la segmentation avec les ciseaux ou l'outil Cross Section, ou encore la mesure de distance entre 2 points, etc. Car sinon ça reviendrait à charger le nuage LAS sous-jacent complet et ça perd de son intérêt.

3) Enfin, si vous êtes très ambitieux, et c'est aussi la raison pour laquelle on est un peu bloqué, c'est que pour faire en sorte que CC puisse à la fois gérer ces nuages en mode "out of core" (en gardant toujours une partie des points sur le disque et en ne chargeant que ceux nécessaires), il faudrait que ce mécanisme soit intégré en profondeur, dans les couches basses, et que des structures d'accélérations comme l'octree utilisé pour de nombreux calculs supporte ces nuages. Et c'est un énorme chantier qui remettrait beaucoup de choses en cours ... Et là vous aurez besoin de quelqu'un assez pointu dans le domaine !

Pour info, Howard Butler était aussi prêt à financer un tel chantier au moins en partie.