CloudCompare forum

Hello,

I'm having a strange problem with CloudCompare (probably user error). I upload a point cloud exported from Agisoft or ER Mapper, and it appears as a thin line. A couple times, I've started with what looks like the map-view of my point cloud, but when I try to rotate the point cloud to see if the height field is there, it turns into the thin line, and won't go back. Do you have any advice? Or is this likely a fault in the point cloud that I import?

Thanks,
Kendra

That's strange indeed. Can you send me a sample file?

Hi,

Just an idea.

I had this kind of problem (but not with Cloud Compare I think) working with georeferenced models.
3D softwares like meshlab for example cannot manage a point cloud or a mesh with terrestrial coordinates (very large numbers).
To deal with this problem you have to use the shift tool when you export your data with Agisoft.
For example if your X coordinates are 5000001, 5000001.4, 5000001.2, 5000006.1, etc...
You should use a X shift of 5000000 that translate you model.
Next you point would have X : 1, 1.4, 1.2, 6.1, etc...
Little numbers are more manageable by the 3D inspection software.

But it may be not the solution because I think Cloud Compare already manage terrestrial coordinates.

Best regards,

AdrienA

Well, CC doesn't like big coordinates, just as Meshlab and some other softwares. But at loading time, CC will ask the user to apply a shift (just as you suggested) that is kept by the entity and then applied back when saving it (most of the times ;).

with the last version, the user can manually edit this 'shift' information.

I encountered the same issue. I imported a LAS file, and saved as a PLY in ASCII format. The x coordinates were rounded to the nearest meter (barely acceptable), but the y coordinates were rounded to the nearest 10 m using scientific notation (totally not acceptable).

I see three solutions:
1. Recenter the cloud before import, and just live with those coordinates.
2. Figure out how to remove the offset in cloud Compare, but I could not get this to work.
3. Avoid that format, and use the binary (I went to the ASCII to see why the PLY file was working correctly in another program, where the size might be the problem).

I am not sure the scientific notation for the Y coordinates saves any space. If the export could force the output to avoid scientific notation, and ideally record to a tenth, that would be a nice addition. You could probably keep scientific notation, but have to store more decimals.

Peter Guth

Hello.. I'm facing the same problem. The exported points from Agisoft turned out to be a straight line. I've tried the shift method but did not help. Any other suggestion to properly extract the point cloud from Agisoft..? What would you recommended the best file format to be imported into CloudCompare? Is there any step that I've miss to visualize 3D model in CloudCompare ??

It's not a shift problem (the Global Shift mechanism would handle this properly). It's probably more a coordinate system issue: either it is not a cartesian one, or one coordinate (dimension) is very different from the others. There must probably be a way to fix this in Photoscan directly.

Otherwise to answer your question, PLY is a very good format to exchange between Photoscan and CC.

Hello again,
seems like I found the solution:
I exportet my point cloud in the WGS 1984 cooordinate system which means that the X and Y coordinates were in degrees. CloudCompare thought these values were metres und tried to fit my whole cloud within a few meters. That's why it looked like a line. Exporting my point cloud in a coordinate system that uses meters solved the problem.