CloudCompare forum

E57 files from terrestrial laser scanners include all of the station setup information. It should be possible to create a sensor for each scanner location in the file.

Indeed! I'll add this to the TODO list.

Hi Daniel and team,

From recent work with the latest stable release (2.10.2 Zephyrus) I don't believe the scanner location has yet been preserved when saving an e57 from cloud compare??

We use both Faro and Z&F scanners, import the raw scans into Autodesk Recap Pro, align the scans to the control points, do some basic cleaning and then export them to e57 format for importing to CloudCompare. We use CloudCompare for further filtering, cleaning, and analysis before exporting the data back to e57 format for importing to Bentley ContextCapture for processing with high definition photography to create high resolution, accurate 3D mesh models.

To enable Bentley ContextCapture to correctly process the scanning files and create the mesh models it needs to know the laser scanner location for each file. When importing e57 directly exported from Recap Pro into ContextCapture all individual scans and their scan locations are correctly maintained and imported. If the e57 file is imported to CloudCompare and then saved to e57 format the scanning locations are lost. I see in the file structure imported to CloudCompare that the scanner locations are correctly read in under \\ FileStructure \ No name [structure] \ data 3D [VECTOR] \ 0 [STRUCTURE] \ pose [STRUCTURE] \ rotation [STRUCTURE] \ translation [STRUCUTRE], however this information is not written when the files is saved from CloudCompare that I can see. If you like I can email you a link to some test data.

Is it likely this improvement \ data integrity issue will be resolved soon? or something that may never receive attention?

Great work, I think the whole laser scanning community is right behind you and you and your contributors are doing fantastic work!

Indeed, most of the pieces of information were there, but handling the potential rotations of the clouds and the Global Shift was a little bit tricky.

I updated the code (you can test the 2.11.alpha version - NOT THE STEREO ONE, ONLY THE STANDARD ONE). I'll let you test.

Best

Daniel

Hi, wondering if you still have plans to have CC read in the following metadata from the e57 and create a sensor from it:

<translation type="Structure">
<x type="Float">1.45285997999999994e+00</x>
<y type="Float">-6.60723456999999903e-01</y>
<z type="Float">3.71718703299999973e+01</z>
</translation>

This would be terrific, and while slightly less convenient than directly loading a FARO LSPROJ file, would make the FARO sdk way less important to the FARO > CC > mesh workflow.

Thanks!

So create a sensor only from its position? Without any information about the orientation?

I meant for the purpose of normals generation.

Isn't that how the "use sensors whenever possible" feature works in the Computer Normals dialog?

Each point's normal vector is just pointing at the sensor xyz location, and doesn't require any orientation data. Right?

Yes that's true. In this case a sensor with only the origin would work.

Ok that's done! I'll update the online version soon (but not now, time to go to sleep ;).

I just updated the online 2.11.alpha version!