When you are a surveyor, as I am, you need to always work in real coordinates, i.e. in the national datum. So you are always working with large coordinates.
Almost every software can not display point clouds with such coordinates. In cloudcompare, you also have kind of "strips" in the display when you want to display large coordinates.
For example in Montpellier in France, coordinates will be around X=724000m and Y=145000m with a area of 150m x 200m for example. And we need to get at least the millimeter for the coordinates. I guess this is a problem of size of the table for storing points in the software, but can we imagine a trick for automatically translate in the software and still display real coordinates.
Since this is a common trouble and really annoying point for us, i hope it can be solved. It would be a really good point for CC.
we had similar issues because the present version of Cloudcompare is compiled in float rather than double. Unless a double version is compiled, you'll end up with discretization issues at large distances.
What we've done : just use a local referential which is simple horizontal translation of your data and keep this info in mind. CC can do this automatically and displays the parameters of the translation.
After that you can whatever you want in CC. And when you need to put back your data in its original georeference frame, you just have to do the translation back (with another software because CC will truncate your data if you do this in CC).
Ideally, it's always best to work on the original scan dataset and then apply the georeference transformation on the results as you're sure that the geometry of the scan data is locally consistent (i.e. no distortion due to georeferencing). If you're looking at surface deformation, it's only possible if you have a local reference framework (fixed targets, fixed structures....).
in fact, the very first version of CloudCompare (the one you'll never see ;) was using kind of tricks(as well as handling per-cloud units) but it was very hard to maintain the global consistency after each modification of entities or to take that information during comparison, etc. (you have to apply either a multiplication factor on the 3 coordinates of both points, or to do a lot of tests every time you do a comparison! And when you compute distances, you do a looooooooot of comparisons - even with the octree).
So it has been a great relief to suppress this. And as said Dimitri, it appeared that it was seldom usefull, and with a few more steps you could do the same (by the way, the actual version of CloudCompare re-centers the cloud - if the user agrees to do so - but it is done on coordinates already stored on 32 bits and therefore it's a bit too late. The sad thing is that in order to do this properly, you would have to open the cloud twice ... well we have to correct this anyway)
So to answer to JF:
in order not to go back to the old system, we could use an intermediate mechanism: at loading, the cloud/mesh is automatically recentered (if the users agree to do so, and at this time the user could also specify it's own translation - to apply a common translation to multiple clouds). This translation is stored with the entity and then ... CloudCompare forget about it ... until you want to save your data and CC will re-center the entity accordingly. Meanwhile, it's quite impossible to handle relative positioning for all entities (it's much too heavy, for a feature that is very seldom used). So CC will only work on local coordinates.
the solution you propose is great. I like the fact that the translation is stored in the file (I tend to loose these kind of information with time ....;-).
Maybe it's time to create a new type of binary file which can hold this kind of information as well as more than 1 scalar ? Maybe an ascii header file could hold a description of the raw bin data so that you don't need to open CC and load a (potentially very) large cloud to know its contains in terms of scalars, translation etc...
This strategy has been implemented in the last version (28 June 2011). Proper restoration on save works only with all ASCII formats (asc, obj, etc.) and the LAS format (the other formats use 32 bits representations of coordinates for storage, so restoration is not possible).
