Command Line Use

[deepminder]

Hello Daniel,

I have a bit similar problem with CC command line.
I'm trying to compare Cloud2Mesh. Here is the command:
"C:\Program Files\CloudCompare\CloudCompare.exe" -O -GLOBAL_SHIFT AUTO cloudfile.las -O -GLOBAL_SHIFT AUTO modelfile.ply -c2m_dist
The problem I got, is that mesh and cloud are not identical (that's the reason to compare them) and Global Shift values are different. So I get completely wrong results.
Is there a way to add LAST_INPUT parameter to Global Shift?

[daniel]

Nope, you have to set it manually (and with the same values for each cloud) in this case.

[a_brokenpencil]

Hi Daniel,

I am having the same problem as deepminder. I am writing a script to automate the filtering of point clouds inside meshes using the command line. I want to load a point cloud and then a mesh and have the auto global shift values for the point cloud be applied to the mesh as well so that they align. Setting -GLOBAL_SHIFT AUTO for both the point cloud and the mesh results in them having different global shifts and they don't align. I thought the FIRST option would do the trick and apply the auto global shift value of the point cloud to the mesh, but it behaved the same as before. Maybe, I am missing something with the syntax of the command line when using the FIRST option.

Since my batch script has to be generalized, I cannot hard code in the global shift values as they will change with different LAS files the user inputs. Is there a way to have the first auto global shift value of the point cloud be applied to the mesh in the command line? I know the GUI has the last input option and it was not possible to do this before, but since a long time has passed since then I am wondering if a solution exists for this now.

Thanks.

[daniel]

What mesh file are you loading? I believe the issue might be that not all mesh formats support large coordinates, and CC won't even try to apply a Global Shift when loading them.

[a_brokenpencil]

Thank you for your quick response. I am using STL format. It does ask to do a global shift in the GUI. It also does the global shift in the command line when set to auto, but with a slightly different shift so the mesh is not placed on top of the point cloud.

I loaded the point cloud and the mesh in the GUI version and I can see that the command line is applying the suggested global shift for the mesh instead of the point cloud's global shift which was loaded first. In the GUI version, it automatically fills in the dialogue with the last input's global shift which is what I am hoping to achieve in the command line.

[daniel]

Okay, understood. Then I guess one has to update the code to achieve that ;). Not sure who and when though ;)

[a_brokenpencil]

Is it possible for -Global Shift FIRST command to solve the issue? How does the command work? How does its syntax work? I am using cloud compare 2.11.3. Would using cloud compare 2.12 help?

[daniel]

You have to set -GLOBAL_SHIFT AUTO for the first entity, and then -GLOBAL_SHIFT FIRST for the next ones.

I don't believe this code has changed for a while. Therefore I would need to reproduce your environment to clearly understand where the issue comes from. Would you be able to share with me a pair of files with the command line you use? (admin [at] cloudcompare.org)

[a_brokenpencil]

I have used the commands in that way and it still did not work as expected. With that said, I was able to solve my problem with a python script that reads my las file with laspy module and creates the rounded negative number of the first point's xyz, and writes this info to a text file. My batch script runs the python script and takes this information to do the global shift and then run the other cloud compare commands.

But, there is another issue that I am noticing. If I use the -FWF_O command instead of the -O to open my las files, the code runs faster and the file size of the result is the same as the source file, but the projection information is lost. When I use the -O command the script is slower and the file sizes of the result become larger, but the file retains the projection information. Do you know why this is?

[daniel]

Ah, interesting. Clearly the other library (LASlib / -FWF_O) is less used than the first one, and I can't remember if it saves the projection information.

I would have to take a look at that.

Can you maybe send me an email? (admin [at] cloudcompare.org) with a summary of your issues (it will help me keep track of it and try to address these issues when I'll have some more time).