It is currently Tue Aug 11, 2020 9:11 pm


All times are UTC




Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: [Resolved]: MeshDecimator bug after calling SurfaceMesh::...
PostPosted: Fri Apr 22, 2011 1:57 pm 

Joined: Sun Jan 23, 2011 6:06 am
Posts: 92
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Fri Apr 22, 2011 3:23 pm 

Joined: Sun Jan 23, 2011 6:06 am
Posts: 92
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Fri Apr 22, 2011 4:53 pm 

Joined: Sun Jan 23, 2011 6:06 am
Posts: 92
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);


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Sat Apr 23, 2011 9:09 am 

Joined: Thu Apr 21, 2011 1:13 am
Posts: 18
Awesome thanks for the help :D, I'll try these changes soon.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Sat Apr 23, 2011 6:53 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Sun Apr 24, 2011 7:51 am 

Joined: Thu Mar 10, 2011 10:34 am
Posts: 19
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Sun Apr 24, 2011 9:13 am 

Joined: Sun Jan 23, 2011 6:06 am
Posts: 92
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Sun Apr 24, 2011 11:33 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Mon Apr 25, 2011 1:25 am 

Joined: Sun Jan 23, 2011 6:06 am
Posts: 92
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: MeshDecimator bug after calling SurfaceMesh::extractSubs
PostPosted: Wed Apr 27, 2011 10:11 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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.


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net