Hi all
I am not sure I'm doing the right thing here......
I have two aerial surveys of a sand dune system as meshes (the PCs are rather large!). I have managed to align them by point picking, and then do a mesh to mesh comparison.
The scalar field that is generated on one of the layers makes some sense - some areas have eroded, particularly in blow out/slack areas, and some areas have grown by deposition (ridge crests and clumps of vegetation). However, the magnitude of the change seems rather large for a 10 week gap between flights...up to and over 1m
So, I was thinking - what ACTUALLY is being measured here. Is it the cumulative change in x,y, and z direction?
I note that the dialogue box that comes up allows me to disentangle x, y, and z changes - strangely these seem empty and show nothing, which confuses me even more.
thanks
Paul
Comparing meshes - what am I really measuring?
-
- Posts: 5
- Joined: Fri Nov 06, 2015 3:31 pm
Re: Comparing meshes - what am I really measuring?
Well, it's a bit hard to answer without seeing the data ;)
First, you'd better be sure of the alignment step. Then, silly question, are you sure that the units of the meshes are meters? (the distances use implicitly the same units as the mesh coordinates).
And to answer your questions:
- the distance computed by the C2M tool is the '3D' distance (square_root(dx^2 + dy^2 + dz^2)) of each vertex of the compared mesh to the nearest triangle in the reference mesh
- I believe the decomposition of the distance along x, y and z is only available when comparing clouds...
Don't hesitate to post a snapshot of the meshes, or even send me some sample files if you want a better diagnostic (to cloudcompare [at] danielgm.net)
First, you'd better be sure of the alignment step. Then, silly question, are you sure that the units of the meshes are meters? (the distances use implicitly the same units as the mesh coordinates).
And to answer your questions:
- the distance computed by the C2M tool is the '3D' distance (square_root(dx^2 + dy^2 + dz^2)) of each vertex of the compared mesh to the nearest triangle in the reference mesh
- I believe the decomposition of the distance along x, y and z is only available when comparing clouds...
Don't hesitate to post a snapshot of the meshes, or even send me some sample files if you want a better diagnostic (to cloudcompare [at] danielgm.net)
Daniel, CloudCompare admin
-
- Posts: 5
- Joined: Fri Nov 06, 2015 3:31 pm
Re: Comparing meshes - what am I really measuring?
Hi Daniel
Yes, I appreciate registering meshes like this are tricky....but I am not sure what else to use otherwise!!
As I say, the trends in the data make sense to me, it is just the magnitudes. I did check the unit issue, the processing of the work in done in WGS84, heights are in m. the scale bar (if in m) looks correct against the image of the mesh - so I'm pretty confident that is ok). I've edited the two meshes such that I am only focussed on the areas that are not covered by a falling or rising tide
Given your algorithm for distance, then, I feel a little more certain - if the computation says 1m, then the sum of all the squared differences would also be 1, meaning the difference in one plane need to not be so large (or at least within accuracy of the method).
Paul
Yes, I appreciate registering meshes like this are tricky....but I am not sure what else to use otherwise!!
As I say, the trends in the data make sense to me, it is just the magnitudes. I did check the unit issue, the processing of the work in done in WGS84, heights are in m. the scale bar (if in m) looks correct against the image of the mesh - so I'm pretty confident that is ok). I've edited the two meshes such that I am only focussed on the areas that are not covered by a falling or rising tide
Given your algorithm for distance, then, I feel a little more certain - if the computation says 1m, then the sum of all the squared differences would also be 1, meaning the difference in one plane need to not be so large (or at least within accuracy of the method).
Paul