Volume is wrong when reversed faces are present!
-
I prefer green fluo for the internal faces
Some different volumes are not well built!
No coplanar (?) or missing line on the top?...
When you erase this line that open the faces/Volumes!!!
That makes the difference at the end!
-
@pilou said:
Explanation !
Inversed volumes are "negative"
So I am not sure that we can consider that as a real bug!
[attachment=1:1mnmnwyg]<!-- ia1 -->nobug.jpg<!-- ia1 -->[/attachment:1mnmnwyg]
Yes, I was thinking the same.
I think it would be better not to count reversed solid as negative. I can not think of the proper use for this "feature", only the mess when measuring volumes.And what TIG found out is a real twilight zone. It has something to do with the relativity
-
@srx said:
YI can not think of the proper use for this "feature", only the mess when measuring volumes.
And what TIG found out is a real twilight zone. It has something to do with the relativity
It is useful for 3D printing because printed volumes are normally hollow to reduce material use. So if you have an outer sphere and an inner sphere where the faces are reversed, you would get the volume of material used in the 3d printing process instead of the solid volume.
-
@unknownuser said:
And what TIG found out is a real twilight zone
I am not sure of that!
It's just these volumes are not orthodox!
If you draw volumes in the rules of art there is absolutly no problemo!
(no bad reversed faces, no forgiven lines, all coplanar faces etc..) -
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.
-
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.
Advertisement