Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

[Resolved]: MeshDecimator bug after calling SurfaceMesh::...
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=15&t=202		 Page 1 of 3
Author:  DefiniteIntegral [ Fri Apr 22, 2011 1:57 pm ]
Post subject:  [Resolved]: MeshDecimator bug after calling SurfaceMesh::...
Hello,

This thread relates to the MeshDecimator bug noted in Will Smith's post here and my post here.

After some debugging, I have found the issue isn't actually with canCollapseRegionEdge() etc. The problem occurs (at least in my code) because SurfaceMesh::extractSubset() is missing this line:

Code:
result->m_Region = inputMesh.m_Region;


As a result the extracted subset is missing region coordinates, causing MeshDecimator::fillInitialVertexMetadata() to incorrectly flag all vertices as touching region edges which they actually aren't.
Author:  DefiniteIntegral [ Fri Apr 22, 2011 3:23 pm ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
Actually with a bit more testing, although this fixed my decimation problems, it hasn't fixed the one pointed out by Will. I will try to look into that as well.
Author:  DefiniteIntegral [ Fri Apr 22, 2011 4:53 pm ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
It seems as though the collapse issue pointed out by Will can be fixed by changing the minimum dot product threshold in MeshDecimator<PositionMaterial>::canCollapseNormalEdge

All I did was change
Code:
return !collapseChangesFaceNormals(uSrc, uDst, 0.999f);

to
Code:
return !collapseChangesFaceNormals(uSrc, uDst, 0.999999999f);
Author:  Will Smith [ Sat Apr 23, 2011 9:09 am ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
Awesome thanks for the help :D, I'll try these changes soon.
Author:  David Williams [ Sat Apr 23, 2011 6:53 pm ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
Great, thanks for looking into these. I'll get your changes applied to the repository as soon as I can.

@Will - it would be good to know if they do fix your problem.
Author:  kattle87 [ Sun Apr 24, 2011 7:51 am ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
DefiniteIntegral wrote:
Code:
return !collapseChangesFaceNormals(uSrc, uDst, 0.999999999f);


Isn't that just equal to 1 because of float numbers only having 7-8 digits precision?
if so, perhaps it might bring problems in some other areas.
Author:  DefiniteIntegral [ Sun Apr 24, 2011 9:13 am ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
I actually originally tested it by just setting it to 1.0f which worked. 0.9 recurring shouldn't get rounded up, but rather just stay as 0.99999998f I think... ?

collapseChangesFaceNormals function actually has the opposite effect to what I would expect. I expected a lower min dot product value to be safer, but all that did was make even more edges be incorrectly merged.

I think the function collapseChangesFaceNormals needs to be looked at in more detail. According to the comments it only needs to check for flipped normal, so the threshold value could probably be taken out altogether.

I haven't really had time to look at it though. Maybe another day.
Author:  David Williams [ Sun Apr 24, 2011 11:33 pm ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
We commited the change to extractSubset(), to make sure the region is copied across. Didn't commit the 0.999... change yet, I'd like to get back on my other PC to look at that.

DefiniteIntegral wrote:
collapseChangesFaceNormals function actually has the opposite effect to what I would expect. I expected a lower min dot product value to be safer, but all that did was make even more edges be incorrectly merged.


Ah, so you would expect the provided value to be a maximum error, such that a value of 1.0 would allow more collapses than a value of 0.0f. This does make some sense, but actually the value is treated as a threshold such that if two surfaces can collapse then they must have similar normals and hence a high dot product.

DefiniteIntegral wrote:
I think the function collapseChangesFaceNormals needs to be looked at in more detail. According to the comments it only needs to check for flipped normal, so the threshold value could probably be taken out altogether.


It's also used for decimation of the smooth marching cubes surfaces, and so the threshold is used in this case. But yes, you could have a separate version for the cubic case.
Author:  DefiniteIntegral [ Mon Apr 25, 2011 1:25 am ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
David Williams wrote:
Ah, so you would expect the provided value to be a maximum error, such that a value of 1.0 would allow more collapses than a value of 0.0f. This does make some sense, but actually the value is treated as a threshold such that if two surfaces can collapse then they must have similar normals and hence a high dot product.


Sorry, what I mean is... since a normal triangle and a collapsed triangle on a cubic mesh should have the same normal, I would expect a lower threshold value to allow for more floating point error as the angle between the vectors increases.

I am guessing it was floating point error allowing the corner to incorrectly collapse.... so I was confused as to why increasing the value prevented the collapse.

But now that I think about it, it was the width of the error margin that allowed the invalid collapse in the first place, right? Since the dot product resulting from the normal comparison in Will's example case would be quite close to 1.0.... so that is why it only occurs on an straight voxel edge length of 28 or more, and raising the threshold value appears to fix it.....

I am not really sure what the best way would be to account for floating point error while simultaneously preventing invalid collapses when the normals are similar such as in Will's case. Probably as you said, a separate function for cubic meshes.
Author:  David Williams [ Wed Apr 27, 2011 10:11 am ]
Post subject:  Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
Sorry, I'm not really having much time to look at this, and to be honest I'm a little hazy as to how it worked :-)

If it seems that changing the threshold to 1.0 (or 0.999999...) then I'm happy to make this change as this hardcoded value is only used when decimating cubic surfaces. I don't have any test cases, but I'm also not using this feature so if it helps you and Will then that's good enough for me.

Overall though I'm intending to remove this decimation code and replace it with a version which does the decimation as the mesh is extracted. Maybe the smooth version remains, and if it does then it can at least be cleaned up with the cubic stuff out of the way.
Page 1 of 3 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/