Open maorp opened 3 years ago
I have seen this behavior before, but unfortunately I haven't found a good fix for it. The problem arises when the texture coordinate of a vertex falls directly on a texture grid line. In general, adding a tiny random jitter resolves this problem. However, in principal, it is possible that the small jitter moves the texture coordinate to some other position that is still on a grid line.
Hi Misha,
Regarding this error, would you mind elaborating a bit what exactly is a "texture grid line"? I am working in a setting where I know generate the UVs and I know the target resolution. As such, I think I should be able to detect and prevent such cases, rather than jittering the entire set of UVs. It seems however that my understanding of "texture grid line" is flawed. My initial attempt to ensure that no UV coordinate falls on exact integer value (i.e. rather it being (128, 128) it is (128 + epsilon, 128 + epsilon) did not remove the factorization issue.
I would be grateful for any pointers!
Maciej
Hi Maciej,
Unfortunately, there is some funny padding that goes on (depending on the resolution of the texture atlas) that could result in coordinates that were not on "texture grid lines" to be re-positioned lie on those lines.
I believe that the transformations is deterministic (and invertible) so you could, in principal, apply it to your coordinates to determine if they will be on texture lines, but I think it's a bit of a mess.
Apologies that I don't have a better/simpler answer.
-- Misha
Hi Misha, I sometimes get the following error, even when I'm running with --jitter. the mesh is not watertight but there are no multiplied vertices. and it does not reproduce every time.
[WARNING] InitializeMassAndStiffness: Zero row at index 13178. Try running with jittering. [ERROR] EigenSolverCholeskyLDLt<float,struct MatrixEntry<float,int> const *,double>::update: Failed to factorize matrix
the data: inpaintMask000004.zip