Initial translation / offset of the point cloud after loading

[rlewandowski]

First of all I would like to thank the author/developer for the great program, I can see a lot of potential in it!;)

My problem, anyway, is that when I load the point cloud, there is >about< [X,Y,Z]=[50,40,40] offset in relation to the initial coordinates I set it to.

My question is: is that exactly the vector I put above? Can I just load the cloud without the need to offset it back to where it was?

I carried out the registration in ZF Laser Control, created the database in LFM, then exported the clouds to *.ptx.

Many thanks!,

Raf

[daniel]

Does CloudCompare display the 'Global shift & scale' dialog when you load the cloud?

Otherwise it's strange as there should be no shift. Maybe if the orientation matrices (in the PTX file) are a little bit crooked and the coordinates are big you could observe such a shift (but it would still be strange ;).

Can you share the data with me?

[rlewandowski]

It does not display the window after loading, the console doesn't say anything about the shift either.

Might be the issue with matrices as you say, not the very first time when I, for example register some scans with Z&F Laser Control and then want to create the database with LFM and it refuses one of the scans because it's "Not registered", although I have got it registered and it is even in the report from Laser Control...;) Recently I spotted that LFM doesn't like any of the scans in the origin of coordinate system, but this time it is not the issue.

Anyway what I mean is that it is quite a lot of data and its processing isn't the easiest, also it has to be difficult to get all the software to correspond well all together.

I am uploading the cloud, you will get the link on your e-mail. It will take a while though, as it's over 550MB (about 20 scans, subdraw level: 8).

One more question, when I loaded the full cloud and saved it, it is about 6GB. Segmented it to keep just the part I want and it seems like it doesn't dump it out of the memory, but just doesn't display the part I got rid of. Still works a bit slow as it is a lot of data. I have Decimation selected in display settings, any other thing I can do to speed it up?

BTW... Mother of god! I do no get such a quick respond for queries send to manufacturers of software my company spends a fortune on! Pour that man a couple pints! ;)

[rlewandowski]

Apologies!

I have cut out some more, saved and the file is 3.4GB instead of 4.3GB! I must have been doing something wrong.. Could it be that I had the "folder" file selected instead of having "cloud" file selected in DB Tree?

Works a bit quicker now;)

Thanks a ton!

[daniel]

Indeed, it's easy to mistakenly select the folder instead of the cloud itself. Same thing, after you have cropped your cloud, the other part may remain in the DB tree. To unload it from memory you have to delete it.

If you have normals, just disable them! (it's terribly slow). And activate the qEDL plugin instead if your cloud is blank (it's a real time shader that does a much better and faster job than normals).

And last but not least, you may want to try the latest beta version (it has a smarter way of displaying big clouds - the LOD structure may take a while to be ready so the display speed may still be low at the beginning):
http://www.cloudcompare.org/release/Clo ... in_x64.zip

[rlewandowski]

Thanks very much for all!

[rlewandowski]

Similar case, so I am posting to possibly help somebody in future although it might be just my cloud, so:

I cleaned the cloud from noises and left only the bit I wanted analysed. Then I generated these cross sections, but when I export them to *.dxf they are shifted to another place...

I scaled them back (x1000) to work on mm, now I just need to put them back where they belong, so that I can compare the job CC has done with the cloud, using LFM.

I checked how far they are offset, comparing equivalent points and... the offset is same as the offset of the cloud inititally, although I shifted it in CC already - [50,40,40].

No big deal, but maybe it will help somebody with same issue;)

Thanks a lot one more time!

[daniel]

Not sure to follow you ;)

What is your conclusion: do you know now were this shift comes from?

[rlewandowski]

Haha, no!;) I just realised that the shift of the cross sections is just like the shift of the clouds, even though I translated all the clouds. I guess you are right - it might be problem with the rotation matrices..

[daniel]

I checked the file you sent me and the matrices are good (I mean they are valid transformation matrices - I don't know if they are correct in term of positioning). And the coordinates are not so big, so no numerical inaccuracy can explain your issue.

Can you maybe export the same cloud to another file format (e.g. PTS or E57) and test that the result is in the same position?