VertexLinkDistanceSqr setting is not used - no option to preserve holes
xwipeoutx opened this issue · comments
Tried fiddling with the VertexLinkDistanceSqr property, to no effect. Documentation states this is only used when PreserveHoles is enabled, but this does not exist.
Has this property been deprecated or something?
Thank you for reporting this. The documentation there is not up to date. It should say that it is only used whenever the EnableSmartLink property is true on the MeshSimplifier class.
The value decides the maximum squared distance between two vertices when detecting vertices at the same or very near position. The default value is double.Epsilon which covers most basic cases, but I allowed for changing it in case one would have meshes of large scale. Increasing this value too much will have strange effects.
If you are having problems with holes being created in simplified meshes, or simply necessary triangles getting stripped, because of vertices not being close enough to link, there is no good solution except for modifying the original mesh to be more friendly to the algorithm. One would have to link edges or even triangles in order to prevent those issues, which would make the algorithm a lot heavier to run. An alternative solution would be to support increasing weight on certain areas of a mesh, or improve the algorithm for determining the error of edges so that the more visually important triangles stay a little longer before being considered for decimation.
Does that help you?
Edit: The documentation has been fixed: dbed80b
Ah fair enough, I think I misinterpreted it as being related to the threshold - to use this number over 1 iteration instead of the ever-increasing threshold over many iterations.
I see now I'm wrong :) Thanks for the clarification and advice.
The Agressiveness property is related to the threshold, however it won't be super easy to find a good value because of the formula of calculating the threshold from that if you are only doing one iteration.
Would you desire more control over the threshold that is actually used per iteration?
No, I think it works well the way it is - I was experimenting with optimising it for my mesh, and didn't know how to use this variable - the doco update solves that
For context, I'm generating meshes of heightmaps from GIS data and looking to simplify them and overly other features on top of them. Turns out a lot of my issues was the scale of my heightmap - I exaggerated the Y component waaay too much - once I got that under control, a my issues went away. Unless there's a magical threshold that'll work for all heightmaps, I don't think there's much value here.
I notice the original paper (https://www.ri.cmu.edu/pub_files/pub2/garland_michael_1997_1/garland_michael_1997_1.pdf) recommends to generally use t=0 - is this the same as the threshold parameter? And will 2 passes at t=0 produce anything different to just 1 pass?
That paper explains another older algorithm. I based my work off of Fast Quadric Mesh Simplification by sp4cerat.
Based on this blog post, he appears to have been inspired by the algorithm that you linked to. But I have not talked to him myself, and I haven't analyzed too much into what similarities they share.
And based on my quick read of the article, it appears to be a different type of threshold. With this algorithm, you might want to look into the SimplifyMeshLossless method, which aims to simplify the mesh without losing too much quality, which it sounds like you may want? I haven't had very good results with it in the past however, and I haven't touched that part of the algorithm since I ported it from C++.
Hello again!
I just wanted to let you know that I released version 1.0.3 with the following fixes: 6a0b71e
This is directly related to your issue, and might have been the problem that you had. This fixes the issue where VertexLinkDistanceSqr had little to no effect after I made the huge optimizations in version 1.0.1
If you happen to test it out, it would be great to hear about your results.
Thanks!
Thanks for the heads up @Whinarn - I've since moved on from the project that used this library, and ended up switching to geometry3sharp (described in this blog post) for simplification - it turned out a little faster and the more sophisticated mesh structure helped immensely for some other transforms I needed (such as removing islands and plane cutting).
I do think my main problem was misunderstanding the use of thresholds - which the documentation fix solved anyway.
For what it's worth, I had a look at the diff and it looks sensible :)
Feel free to close this issue out if you don't need to track it.
Alright. Thanks for the information. I will close this issue then.