Crashing during priority queue preparation

[vsantosu]

First of all, congratulations for your publication! This is are high quality results! :)

The issue:

The execution crashes during the Priority queue preparation. I don't know if it is due some logic error in the procedure or some inconsistencies with the libigl internal structures and how it reads the OBJ. The code crashes at the following line:

cost_and_placement.cpp#L106

The error is the following:

libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: unordered_map::at: key not found

To replicate:

Use the following OBJ 3D model of a Tractor:

Tractor Model

On a side note, it seems like there is a weird non deterministic behavior with libigl... the assertions and runtime errors show up randomly, specially if running in a debugger or release, the same line of code yields different errors.

[sinclairzx81]

@vsantosu did you find a solution to this?

[vsantosu]

@sinclairzx81 sadly not... I think it has to do with the dependency library (libiGL). Something changed and I was unable to figure out a fix to make it work. This is a great solution, but like all academic projects there are no man power to maintain it :(

On a side note, I recall reading the libIGL source code and there was a decimater included, perhaps this technique will be included in the library itself at some point.

[sinclairzx81]

@vsantosu thanks for the insights :) i might take a deeper dive into this and see if i can figure something out. But yeah, this project is pretty great, the UV seam awareness is a top feature of this particular library, curious about other approaches for clean UV preservation.

[vsantosu]

@sinclairzx81 I have look into it many times. From all the techniques(planar, remeshing, quadric edge collapse) this one is the best based on many samples I tried, I wish it where more stable.

[Rage997]

Hi,

Any update regarding this issue?

I still haven't be able to process any obj other than the one provided as example in the repo

[TheOriginalBytePlayer]

I think I may have a solution -- a lot of OBJ files have 3 UVS--such as the ones produced by Cinema4D --which is valid though they actually seem to only use the first 2 values as the 3rd is always zero. In any case

1. Goto the ReadOBJ.cpp file, and to insert the line

       Count = 2;

just before Line 131,

       std::vector<Scalar > tex(count);

You need to do this because the decimation function requires the UVs to have exactly 2 columns and OBJ can legally have 3. By Explicitly setting it to 2 you are tossing the third value which appears to always be zero in files I’ve seen, anyway.

Similarly, OBJ files can legally have NO UVs but the library can't handle that, so make sure they have UVs assigned.