CloudCompare forum

Basically: (meanX+meanY)*meanZ*area-of-cylinder*# of valid points and that will give me a signed total change.

But there's no way to distinguish between positive change (deposition) and negative change (erosion) correct? This is what I'm really after. My output maps show some areas with erosion and some with deposition and I need to try to separate the two volumes which would be easy if I could distinguish which valid points have a negative z value vs a positive z value.

Or am I just missing something obvious?

For this you should simply use the "Edit > Scalar Fields > Filter by value" method. It will generate a new point cloud with only the points falling inside a given interval (two clouds in your case: [dist_min ; 0] and [0 ; dist_max]).

And for the volume formula, I'm not sure about the 'mean' things. I'd rather use: sum-of-positive/negative-distances * area-of-cylinder * # of valid points.

Apologies for bringing this up again, but I'm currently looking at different methods of change detection in 3D - I've tried meshing and boolean intersection methods on my meshes to calculate volumes etc, but given the number of points in my scans (~350-400 million in both), splitting the scans into many smaller slices to carry out these operations is fairly unfeasible over the area that I'm considering (20 km or so, cliffs are failing iteratively w/ fairly small volumes of change). I've been looking at cloud-to-cloud type operations instead, and trying to figure out ways that a series of volumes can be identified and quantified using M3C2 - while I got a fairly positive result for my accumulated volume using the cylinder method outlined above (2064 m^3 compared to 1989 m^3), my eroded volume was way out using the same method (3651 m^3 vs 2163 m^3). I appreciate that overlapping cylinders etc may be problem here. I'm just wondering how feasible this really is as a method for calculating volumes, given the difficulties I've had with just one very large, contiguous failure, and whether anyone had any ideas?

Dear Daniel,
"The easiest idea would be to divide the result by 9 (i.e. 30^2/10^2) considering that you get cylinders with a section 9 times wider than the minimal empty area around each core point."
Could you explain why 30^2/10^2. shouldn't it be either 30^2/20^2 or 15^2/10^2 if r = 0,5*projection scale (means 15cm). Or did i get it totally wrong?
Is this way of estimating the change of volume still advisable?

Thanks!

I believe I was referring to the fact that the initial radius was 10 cm, and the scale was 30 cm. Thus the multiplication of 9 of the section area, and equivalently of the volume (the cylinder height does not change).

This method of volume computation is quite coarse of course (but it can help get a first approximation on complex "3D" cases). For 2.5D cases, there's now a dedicated tool.

Daniel,

Speaking of the 2.5D tool...I wonder if you could somehow combine the Z and X (or Y) calculation for complex topographies where M3C2 really excel like a slumping bluff face (assuming the face was oriented to X or Y).

Any thoughts on that?

Ah, ah, it would be something like a 2.75D tool? :D

I'm not sure what you are thinking about here. Especially since the calculation done by this tool is really simple (i.e. difference between two grids with the same XY coordinates).

Don't hesitate to explain it of course ;)

Ha, well in that naming scheme i guess so!

I guess this is what I mean:

I have a time series (annual) of TLS data for a slumping cliff face where it's eroding back (inland) and down (-Z). The face isn't overhanging nor is it vertical so the bottom of the cliff face is closer towards the water than cliff edge.

I'm also very interested in estimating volume loss on this area. However, since it's such a complex surface from year to year, not to mention that occlusion seems to happen in different areas from year to year even though scan positions were rough the same (on the beach shooting towards bluff face) the 2.5d method might have some drawbacks.

One idea for me was to rotate the cliff face to be perpendicular to the X axis and run the 2.5d with that projection. My thinking was that the tool would be projecting the raster in the same direction that the scanners were scanning. Does that sound reasonable.

To get back to the original question, could I take maybe an average of the 2.5d volume change from both the Z and X axes in this case...since the topography is expected to be moving in that way?