Working with VStudio 2013. Execution error. ARAP Mesh parametrization functions. about libigl HOT 15 CLOSED

This could be a problem in your input or some wrong settings in the visual studio project. Are the parametrization examples in the tutorial folder working for you? In there, there is a cmake that can be used to generate a visual studio project with the correct settings. If the tutorials are working and you still get the crash for your particular mesh then there is probably a face with zero area.

from libigl.

Hi Daniele,

Test1.obj file (hemisphere very simple) hasn't any zero area face, ...The code I'm testing is very similar (I don't use the viewer) to the Harmonic Parametrization tutorial example (501_HarmonicParam). I'm doing a tesselation of the hemisphere surface with faces of 3mm (very similar faces)...

The code is very easy, but crash when save obj file (I don't need the viewer, just need save the final flatten file).
I observe that when print Faces and Vertices of original and flattening meshes, there are differences between V vertices and V_uv vertices¿?
I understand that the number of vertices and faces must be equal, ok?

Is ok my way of save final obj_flat file?

Thanks in advance.
VStudio 2013 express edition project.

#include "stdafx.h"

#include

#include <igl/readOBJ.h>
#include <igl/writeOBJ.h>
#include <igl/boundary_loop.h>
#include <igl/map_vertices_to_circle.h>
#include <igl/harmonic.h>

int _tmain(int argc, _TCHAR* argv[])
{
Eigen::MatrixXd V;
Eigen::MatrixXi F;
Eigen::MatrixXd V_uv;

// Load a mesh in OFF format
igl::readOBJ("c:\\temp\\test1.obj", V, F);
std::cout << "OBJ Input File -> " << "Faces: " << F.count() << "-" << "Vertices: " << V.count() << "\n";
std::cout << "OBJ Input File readed!!" << "\n";

// Find the open boundary
Eigen::VectorXi bnd;
igl::boundary_loop(F, bnd);
std::cout << "Boundary loop done!!" << "\n";

// Map the boundary to a circle, preserving edge proportions
Eigen::MatrixXd bnd_uv;
igl::map_vertices_to_circle(V, bnd, bnd_uv);
std::cout << "Map vertices to circle done!!" << "\n";

// Harmonic parametrization for the internal vertices
igl::harmonic(V, F, bnd, bnd_uv, 1, V_uv);
std::cout << "Harmonic done!!" << "\n";

// Scale UV to make the texture more clear
//V_uv *= 5;
std::cout << "OBJ Output File -> " << "Faces: " << F.count() << "-" << "Vertices: " << V_uv.count() << "\n";
igl::writeOBJ("c:\\temp\\flat_test1.obj", V_uv, F);
std::cout << "OBJ Output file writed!!" << "\n";

}

from libigl.

Can you verify that the path exists? Also verify the sizes of V_uv and F?
If you can run in debug get a line number of the crash inside writeOBJ,
then this will be easier to diagnose.

On Thu, Mar 12, 2015 at 6:09 AM, mdavia [email protected] wrote:

Hi Daniele,

Test1.obj file (hemisphere very simple) hasn't any zero area face, ...The
code I'm testing is very similar (I don't use the viewer) to the Harmonic
Parametrization tutorial example (501_HarmonicParam). I'm doing a
tesselation of the hemisphere surface with faces of 3mm (very similar
faces)...

The code is very easy, but crash when save obj file (I don't need the
viewer, just need save the final flatten file).
I observe that when print Faces and Vertices of original and flattening
meshes, there are differences between V vertices and V_uv vertices¿?
I understand that the number of vertices and faces must be equal, ok?

Is ok my way of save final obj_flat file?

Thanks in advance.
VStudio 2013 express edition project.

[image: crash]
https://cloud.githubusercontent.com/assets/11426067/6615817/91ec017a-c8a7-11e4-8a76-8f9b8633a4cc.png

#include "stdafx.h"

#include

#include
#include
#include
#include
#include

int _tmain(int argc, _TCHAR* argv[])
{
Eigen::MatrixXd V;
Eigen::MatrixXi F;
Eigen::MatrixXd V_uv;

// Load a mesh in OFF format
igl::readOBJ("c:\temp\test1.obj", V, F);
std::cout << "OBJ Input File -> " << "Faces: " << F.count() << "-" << "Vertices: " << V.count() << "\n";
std::cout << "OBJ Input File readed!!" << "\n";

// Find the open boundary
Eigen::VectorXi bnd;
igl::boundary_loop(F, bnd);
std::cout << "Boundary loop done!!" << "\n";

// Map the boundary to a circle, preserving edge proportions
Eigen::MatrixXd bnd_uv;
igl::map_vertices_to_circle(V, bnd, bnd_uv);
std::cout << "Map vertices to circle done!!" << "\n";

// Harmonic parametrization for the internal vertices
igl::harmonic(V, F, bnd, bnd_uv, 1, V_uv);
std::cout << "Harmonic done!!" << "\n";

// Scale UV to make the texture more clear
//V_uv *= 5;
std::cout << "OBJ Output File -> " << "Faces: " << F.count() << "-" << "Vertices: " << V_uv.count() << "\n";
igl::writeOBJ("c:\temp\flat_test1.obj", V_uv, F);
std::cout << "OBJ Output file writed!!" << "\n";

}

—
Reply to this email directly or view it on GitHub
#45 (comment).

from libigl.

I think I found a little bug in writeOBJ function...

Yes, path is ok, I save obj file in the same folder I read obj geometry.
Original geometry has: 296 vertices and 480 faces,...
...but when I read obj file, Faces = 1438 and Vertices = 729 ¿?

Debugger stops and crash in line 33 of writeOBJ.cpp file:

s << "v " << V(i,0) << " " << V(i,1) << " " << V(i,2) << std::endl;

...because V(i, 2) -> V has only 2 cols!!! It's necessary test before dimensions...

If I change this line by:

s << "v " << V(i,0) << " " << V(i,1) << " " << "0.0" << std::endl;

...program don't crash and save OBJ file, OK!!!!!

I'm going to test another geometries more complex than hemisphere.

from libigl.

Technically this is a bug in the input to writeOBJ. The documentation
specifies that V should have 3 columns. For now, libigl places the onus of
error checking on the caller. In you case, it seems like you want to
append a column of zeros to your V_uv. For example with something like:

V_uv.conservativeResize(V_uv.rows(),3);
V_uv.col(2).setConstant(0);

On Thu, Mar 12, 2015 at 10:46 AM, mdavia [email protected] wrote:

I think I found a little bug in writeOBJ function...

Yes, path is ok, I save obj file in the same folder I read obj geometry.
Original geometry has: 296 vertices and 480 faces,...
...but when I read obj file, Faces = 1438 and Vertices = 729 ¿?

Debugger stops and crash in line 33 of writeOBJ.cpp file:

s << "v " << V(i,0) << " " << V(i,1) << " " << V(i,2) << std::endl;

...because V(i, 2) -> V has only 2 cols!!! It's necessary test before
dimensions...

If I change this line by:

s << "v " << V(i,0) << " " << V(i,1) << " " << "0.0" << std::endl;

...program don't crash and save OBJ file, OK!!!!!

I'm going to test another geometries more complex than hemisphere.

[image: crash]
https://cloud.githubusercontent.com/assets/11426067/6620054/d915e99a-c8ce-11e4-9fe9-87a412e39c14.png

—
Reply to this email directly or view it on GitHub
#45 (comment).

from libigl.

Ok, is a good solution...
But, when I try to do ARAP parametrization with geometry show below, Harmonic parametrization is good but ARAP parametrization is wrong...why? Initial solution is good but the final flat mesh...¿?

This is the code added for ARAP parametrization example:

    // Add dynamic regularization to avoid to specify boundary conditions
igl::ARAPData arap_data;
arap_data.with_dynamics = true;
Eigen::VectorXi b = Eigen::VectorXi::Zero(0);
Eigen::MatrixXd bc = Eigen::MatrixXd::Zero(0, 0);

// Initialize ARAP
arap_data.max_iter = 500;
// 2 means that we're going to *solve* in 2d
arap_precomputation(V, F, 2, b, arap_data);

// Solve arap using the harmonic map as initial guess
V_uv = initial_guess;

arap_solve(bc, arap_data, V_uv);

V_uv.conservativeResize(V_uv.rows(), 3);
V_uv.col(2).setConstant(0);
V_uv *= 20;
igl::writeOBJ("c:\\temp\\flat_test2.obj", V_uv, F);

from libigl.

Hmmm. Indeed looks bad. Would need your input to debug further though. Can
you share it?

On Thu, Mar 12, 2015 at 11:27 AM, mdavia [email protected] wrote:

Ok, is a good solution...
But, when I try to do ARAP parametrization with geometry show below,
Harmonic parametrization is good but ARAP parametrization is wrong...why?
Initial solution is good but the final flat mesh...¿?

[image: crash]
https://cloud.githubusercontent.com/assets/11426067/6620735/a9de2eea-c8d2-11e4-8390-f36f1ee1b14f.png

This is the code added for ARAP parametrization example:

// Add dynamic regularization to avoid to specify boundary conditions

igl::ARAPData arap_data;
arap_data.with_dynamics = true;
Eigen::VectorXi b = Eigen::VectorXi::Zero(0);
Eigen::MatrixXd bc = Eigen::MatrixXd::Zero(0, 0);

// Initialize ARAP
arap_data.max_iter = 500;
// 2 means that we're going to solve in 2d
arap_precomputation(V, F, 2, b, arap_data);

// Solve arap using the harmonic map as initial guess
V_uv = initial_guess;

arap_solve(bc, arap_data, V_uv);

V_uv.conservativeResize(V_uv.rows(), 3);
V_uv.col(2).setConstant(0);
V_uv *= 20;
igl::writeOBJ("c:\temp\flat_test2.obj", V_uv, F);

—
Reply to this email directly or view it on GitHub
#45 (comment).

from libigl.

Could it be a scale problem? ARAP is not scale invariant. Could you please check the area of your mesh in 3d and the area of the harmonic solution? They should be similar.

If they are not similar, you can scale the harmonic solution to get identical areas and this should at least improve the result.

from libigl.

Oh right, map_vertices_to_circle is mapping to the unit circle, right? So
then one should scale the harmonic solution by sqrt the area of the
original mesh.

On Thu, Mar 12, 2015 at 4:00 PM, Daniele Panozzo [email protected]
wrote:

Could it be a scale problem? ARAP is not scale invariant. Could you please
check the area of your mesh in 3d and the area of the harmonic solution?
They should be similar.

If they are not similar, you can scale the harmonic solution to get
identical areas and this should at least improve the result.

—
Reply to this email directly or view it on GitHub
#45 (comment).

from libigl.

Right!!! harmonic solution fits with unit circle...in image above red circle has been scaled for best visualization...

from libigl.

K. so can you try scaling the output of the harmonic solution before
passing it to ARAP?

On Thu, Mar 12, 2015 at 4:57 PM, mdavia [email protected] wrote:

Right!!! harmonic solution fits with unit circle...in image above red
circle has been scaled for best visualization...

—
Reply to this email directly or view it on GitHub
#45 (comment).

from libigl.

Hi,
I have scaled harmonic initial solution and ARAP works...but solution is not good. See image below:

Harmonic solutions in the examples is Ok, ARAP solution with arap_data.with_dynamics = true, is very similar to HARMONIC solution...but parametrization is not good...
So, when I change with_dynamics = false, in test2 ARAP solution is VERY GOOD!!! area2d = area3d, ...
...in test1 don't work with errors show in image. ¿?

I'm thinking, are there any relation between geometry position (1st cuadrant) and solver processing? Must be all coordinates (x,y,z) >0? I don't know...

from libigl.

Again, please share your input. It will be much easier for us to diagnose.

On Friday, March 13, 2015, mdavia [email protected] wrote:

Hi,
I have scaled harmonic initial solution and ARAP works...but solution is
not good. See image below:

[image: crash]
https://cloud.githubusercontent.com/assets/11426067/6635082/e7aad270-c961-11e4-8567-2f5557146f66.png

Harmonic solutions in the examples is Ok, ARAP solution with
arap_data.with_dynamics = true, is very similar to HARMONIC solution...but
parametrization is not good...
So, when I change with_dynamics = false, in test2 ARAP solution is VERY
GOOD!!! area2d = area3d, ...
...in test1 don't work with errors show in image. ¿?

I'm thinking, are there any relation between geometry position (1st
cuadrant) and solver processing? Must be all coordinates (x,y,z) >0? I
don't know...

—
Reply to this email directly or view it on GitHub
#45 (comment).

from libigl.

Do it!! I've sent 2 files to your email. Previous example works fine if I weld all vertices of the mesh. But, with new test files...don't work.

from libigl.

Closing this due to inactivity. Please reopen if it is still relevant.

from libigl.