Volume is wrong when reversed faces are present!
-
Make a copy of the group over the top of itself.
Their two volumes report the same.
Now move the copy say 500m in X [red].
Compare the volumes of the two now.
The one you moved will report a different volume, although all of its geometry is identical in count/lengths/areas...
Now move the original over the top of the copy.
Their two volumes report the same - although now the changed value.
It seems that a group/instances location relative to the Origin [0,0,0] and its relative position to that along axes affect the reported volume, but it does not affect the reported lengths/areas.
The original post about negative volumes is superseded by this worrying anomaly !
As Jim says, a volume consisting of reversed faces must report as negative.
Imagine a thin walled nutshell...
It has two surfaces, an outer one and inner one.
The outer surface is modeled facing outwards from its solid part.
The inner surface is also modeled facing outwards from its solid part.
If you do a section-cut the inner surface's volume faces appear reversed, and so its volume is negative.
But this is correct.
To get the true volume of the nutshell SketchUp needs to calculate the volume of the outer part and subtract the volume of the inner part.
The only way SketchUp can tell if a volume is to be subtracted is to see if it has a reversed surface.
If the inner surface is reversed to mimic the outer surface then SketchUp will take both as positive volumes and report an incorrect result ! -
Seems working in m3 with 6 decimals there is no more this problem !
inversed faces are always negative but moving group don't change m3 measures
move it to 10 KMS It don't change !
-
@unknownuser said:
Make a copy of the group over the top of itself.
Their two volumes report the same.
Now move the copy say 500m in X [red].
Compare the volumes of the two now.You speak about my volume or SRX Volumes ?
Because mine don't change if you Copy move its' copy or the original by 10 Kms in any direction
as shown in my post above!I suspect Unities ! Here i work in meter with 6 decimals
here in negative x
-
@srx said:
You got me with that nutty line. But Maybe it was my intention to make it not ortho... It is still a solid, not bad geometry, and has nothing to do with the problem mentioned. I think what TIG has found also has nothing to do with bad geometry. The exact same copy has different volume on different places on UCS... Regarding the negative volume,it is not "physically correct", so I think it could be useful for many people to fix the way SU calculates the volume of reversed faces solids inside the group.
Your composed group has at least two blocks with ugly/=bad geometry that needs to be fixed first.
I suspect that SketchUp will then act as expected: displaying the same volume for all copies. -
@wo3dan said:
....bad geometry that needs to be fixed first.
I suspect that SketchUp will then act as expected: displaying the same volume for all copies.See attached file with explanation. If your geometry is fixed you might optain the same volume.
Even one isolated solid group can act weird like you observed.
-
I agree the SRX version has some issues that need fixing.
@Pilou
But the mis-reported volume depending on the object's location occurs in all SKP's not just that one.
Here's an example of a new SKP with a 1m cube.
It displays two different volumes depending on where the group is located relative to the Origin.
Admittedly the variance is small, but it is still there.
-
That I said from the start! "In the rules of Art!"
-
It's for that I work in meters with 6 decimals!
there are no difference at this scale!
precision to the cm3 seems reasonnable for 10 or 100 KMs!
-
if you copy a 100" cube, 10000" away you get 1000000 in³ for both...
is this issue a metric rounding error?
john -
@tig said:
The original post about negative volumes is superseded by this worrying anomaly !
.....
To get the true volume of the nutshell SketchUp needs to calculate the volume of the outer part and subtract the volume of the inner part.
The only way SketchUp can tell if a volume is to be subtracted is to see if it has a reversed surface.
If the inner surface is reversed to mimic the outer surface then SketchUp will take both as positive volumes and report an incorrect result !I see people are making connections between bad lines in my example and this new problem TIG discovered. Both has nothing to do with original post, which is about how SU calculates reverse faces geometry volume as negative value. I also understand that it is happening because of the way SU calculates nutshell volume...But, Su should be smarter in recognizing solid which is not a nutshell...that means it should orient faces the right way,which is in fact the old problem whit which users have to deal manually orienting...I guess this is my request for SU 2016.
-
@unknownuser said:
is this issue a metric rounding error?
It's surelly a round error or limit double precision's computers
but rounding 1 cm3 by m3 is 1/ 1 000 000 error !
And this for 1, 1o or 1 ooo kms is some negligible! -
@tig said:
....But the mis-reported volume depending on the object's location occurs in all SKP's not just that one.
Here's an example of a new SKP with a 1m cube.
It displays two different volumes depending on where the group is located relative to the Origin.
Admittedly the variance is small, but it is still there.TIG, could you share the file itself?
I can't get any differences is volume results and would like to see why, which settings. -
Make your own SKP with a 1m cube Group located at the Origin.
Copy that Group ~1000m away [Move+Ctrl].
Have your Model Info > Unit set to 'mm', with max 0000's etc...The Entity Info will report the volumes for the two slightly differently.
[v2015 Pro PC 64bit] -
@tig said:
...The Entity Info will report the volumes for the two slightly differently.
...Got it: 1000000000 mm³ vs 999999999,999898 mm³
The differences in SRX's original model were significantly larger (in percentage) due to bad geometry.
But yes, that doesn't mean these same two simple solids should report same volumes. -
Yes, I see it too. The size of the difference varies depending on how far away the copy is placed! This certainly looks like a finite-precision effect, but it also seems like a bug because (as already stated) the placement of an instance should be irrelevant when calculating position-independent quantities such as volume.
-
So 0.000 102 mm3 missing on 1 000 000 000 mm3 !
ps
And how many number are available before the numeric decimal point for landscape?
Seems lost precision and pedal : a number is added after
123456789012345680000.000000mm for 123456789012345678901mm or more ENTER
(tested on radius circle)
-
Interesting discussion.
For info, I just publish a rudimentary version of a plugin, FredoTools::SolidVolume, which computes the volume of the solids in the current selection (solids as groups or component instances).
It gives the same result regardless of the orientation of faces in the solids and their position in the model.
For the time being, it just display a messagebox with the volume in various units.
I this is of interest I can later derive a more advanced version with choice of units and interactive selection, similar to what I did for areas with FredoTools::ReportLabelArea.Fredo
-
Cool!
And about the M2 surfaces faces?
No possibility to add this inside this one? -
Thank you Fredo! You are my hero!
This should be incorporated in Sketchup 2016 to prevent people for making mistakes in calculations..In the meantime we have Fredo Sketchup. -
@fredo6 said:
......I this is of interest I can later derive a more advanced version with choice of units and interactive selection, similar to what I did for areas with FredoTools::ReportLabelArea.Fredo
It would be nice to be able to make your own selection of multiple solids to obtain the sum of volumes. And with unit of choice! And without differences in volume due to location!
Although I do believe that solids with all back faces outwards should be considered as negative. (also see previous post by TIG).
A mixture of front and back faces in a single shell should result in a warning.
Advertisement