CloudCompare forum

Yes, so you can see that the bounding box along X and Y is super small (<0.02) and super large along Z (> 420). This is once again typical from a geographical coordinate system. You can try to rescale X and Y with the 'Edit > Multiply / scale' tool (by using a factor of 100 for instance for X and Y ...

I don't believe there's any such feature in CloudCompare...

To export to ascii, you have to use -C_EXPORT_FMT ASC (or TXT should work). This must be placed before -SAVE_CLOUDS.

And before calling -EXTRACT_VERTICES, I would remove the cloud with -POP_CLOUDS (so that only the plane remains, because it's a mesh).

See https://github.com/CloudCompare/CloudCo ... rtObject.h (it's part of the 'DB' library)

Animation Trajectory: the plugin can only export a polyline for now... The other pieces of information would have to be exported as a series of 'viewport objects' I guess? As one 'viewport' object for each frame, or something like that. But that would require to modify the code of the plugin. And sa...

Yes, CCCoreLib doesn't manage normals at all. So it would definitely not be easy to pass this information and use it in the existing algorithm without a lot of refactoring...

Generally, when this issue happens (a 'linear' cloud), this is due to the cloud being saved with a Geographic coordinate system (with angular coordinates for X and Y, and metric coordinates for Z, and a totally different scale). CloudCompare doesn't automatically convert these geographic coordinates...

By any chance, are the coordinates of the points very large? Maybe Blender doesn't like large coordinates? (just as CloudCompare, OpenGL, etc.). In which case, before exporting the cloud to a new file, you could remove the Global shift (with 'Edit > Edit Global Shift & Scale') so as to only keep...

Well, sadly not. And this tool is meant to be used on a 'surface' (cloud), not a linear one. That may be the cause of the issue?

The bounding-box (and more generally the entity properties) doesn't appear in this capture...