Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to factorize matrix #12

Open
maorp opened this issue Jun 10, 2021 · 3 comments
Open

Failed to factorize matrix #12

maorp opened this issue Jun 10, 2021 · 3 comments

Comments

@maorp
Copy link

maorp commented Jun 10, 2021

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

@mkazhdan
Copy link
Owner

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.

@mhalber
Copy link

mhalber commented Aug 13, 2021

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

@mkazhdan
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants