CloudCompare forum

I find the volume calculation between 2 meshes in CloudCompare a useful check routine on our own volume programme. These are volumes for stock piles, quarries etc.

However, in order for the CloudCompare volume function to be practical, the following 2 conditions seem to be necessary :-

1. that both mesh surfaces have the same minimum Z (height) value, and
2. That both mesh surfaces cover the same planimetric (X, Y) area.

It seems that the volume routine takes the minimum Z value for a mesh and then computes the area from that level. If the two mesh surfaces have different minimal Z values, then the volume calculation becomes meaningless. Is it possible for CloudCompare to determine the minimum Z value of the combined 2 mesh surfaces, and then compute the volumes for each mesh from that minimum Z value? The difference between the 2 volumes would then be the net volume between the 2 surfaces.

Further, in the case of a small mesh surface overlying a larger mesh surface, is it possible to restrict the volume calculation of the larger mesh to the X, Y dimensions of the smaller mesh? This problem often arises when, for example, a stock pile has been created on an undulating piece of ground and the volume of the stock pile is required.

Thank you.

Hi,

In fact the volume calculation routine of CloudCompare expects a closed mesh (i.e. even the 'bottom' should be filled with triangles). If you input a 'classical' 2.5D mesh (I guess this is what you have?) it could work indeed if Zmin = 0 but it would be fortuitous.

If it does works for Zmin = 0 (I'll have to check the theory behind the algorithm again) then I'll change the code as you suggest. This way it will work for both closed meshes AND meshes like yours (well if you confirm me how they look like ;).

For the second question, I guess the next version of the 'Edit > Crop' tool (in version 2.6.2 - will do 'clean' mesh segmentation) will help you to crop the bigger mesh to the same extents in (X,Y) as the smaller one. But I fear that the resulting mesh won't be compliant with the 'hacked' version of the mesh calculation routine as there will be holes not only on the 'bottom' but also potentially on the sides.

Can you can share a set of meshes with me? Maybe it will be easier for me to think of something with the real data...

Hi Daniel,

I have been trying to send you an example regarding volumes which is 720 Kb in siz,e and the message "attachment too large" keeps coming up! Is there any way I can send you this example?

Regards,

Keith young

For 720 Kb?! Maybe you can try to send it at my personal address: daniel.girardeau [at] gmail.com.

Otherwise you could use a dropbox or google drive account?

Hi Daniel,

Thank you for your reply. Before going any further, let me say what a great programme CloudCompare is and it has many applications for both surveying and mining.

It is not that I require the Z value for the meshes to be 0, but that that both meshes use the same minimum Z value when computing volumes. For example, if you have Mesh A, representing a stock pile surface, and Mesh B, representing the original ground below the stock pile, then the volume between Mesh A and B can be computed by calculating the volume of A from a defined minimum Z value plane, then calculating the volume of B, using the same minimum Z value plane. The difference between the two volumes is obviously the required net volume between A and B. However this is only true if meshes A and B cover the same Y,X areas.

I have checked example where the above two conditions hold true, and the resulting net volume from CloudCompare is very close to that obtained from our SURPAC Surveying Software.

However, as soon as I use and example where A and B have different minimum Z values, the resulting volume is way off. I am sending two simple .asc files (one representing the stock pile Surface and the other the original ground) directly to your personal e-mail. They cover the same surface (Y, X) area, but the Base model has Z values less than that of the Surface model. CloudCompare shows the two volumes as :-
Surface = 7,674 cubic metres
Base = 865 cubic metres
Diff = 6,809 cubic metres

the volume between these two surface models should be 10,597 cubic metres.

So what I am asking here is :-
Is it possible to get CloudCompare to search through two user defined (and loaded) meshes and determine the minimum Z value that occurs when looking in both files. Can the User then tell the Volume routine that, when computing the volume of each of the two defined Meshes, it must do so from this minimum Z value plane. I appreciate that this would only apply to "open" meshes (such as in this example) and not closed meshes.

The problem of one mesh covering a smaller area then the other can perhaps be looked at after the above query has been addressed.

Thank you and regards,

Keith Young

Hi Daniel,
I agree with Keith Young that volume between meshes in z projection can be nice add to your software, the extent of calculation can simply be the intersection of both area.

Thank You
Cedric

Yes a dedicated tool is in the pipe (well the TODO list ;). I'm just not sure exactly when we'll have the time to implement it!

Just to announce that the first version of a 2.5D volume estimation is now available (in the latest beta version - 2.6.3):
http://www.cloudcompare.org/release

And here is the documentation:
http://www.cloudcompare.org/doc/wiki/in ... generation

This tool is in it's early development stage therefore comments are welcome!

Hi Daniel,

Thank you for the latest Upgrade that includes the 2.5D Volume estimation between two surfaces. I have carried out tests on several different topographical models and I am please to say the results I get using Cloud Compare agree very closely with the results obtained using our SURPAC Surveying Software. The differences obtain are less than 0.1%, which is excellent.

For what it is worth, my only negative comment is that the colour display bar shown to the right of the volume model, entitled "Height above ground", should perhaps be labelled "Height above Datum" and should show the actual height values used for the model, or models currently being used.

Other than that, this is great addition, especially for Surveyors, Mining Engineers etc. Keep up the good work!

Regards,

Keith Young

Thanks for the feed-back!

About the coloring scheme I guess the best solution would to add an option to let the user choose (i.e. between 'Height above ground' and 'Absolute height'). I'm just not sure how to represent the heights of both models at once ;)