"Request for Test Data and Resolving Code Assertion Errors"

[TaiXiaonan]

Hello author, first of all, thank you for sharing the code of this project. I wonder if you could upload the test data. Second, when I was testing the code, I often had assertion errors about input file handling. Since the algorithm is designed to repair meshes with flipped triangles, why does it produce a false assertion when I input a planar triangle mesh with flipped triangles, which can only be executed until the Schnyder labeling is completed. Some immature suggestions, but also please take time to answer, thank you.

[TaiXiaonan]

[ugogon]

Hey,

thanks for reaching out to us. Can you send me an example file that generates such errors? The test data is quite large. Do you want all meshes?

[TaiXiaonan]

My gosh,  thank you so much for your reply. Yes, your test data is very important to me ，because I haven't been able to figure out what the right input file should look like! Maybe I didn't have a thorough understanding of your paper, so I didn't have a thorough understanding of the position of the flipped triangle in the repair grid. Where do the flipped triangles come from? Does the input triangle mesh file itself have the flipped triangles generated by the mapping?  I will enclose the  input files that I made mistakes in. I would be grateful if you could give me your advice!

------------------ 原始邮件 ------------------ 发件人: "ugogon/E3A" @.>; 发送时间: 2024年5月9日(星期四) 晚上10:54 @.>; @.**@.>; 主题: Re: [ugogon/E3A] "Request for Test Data and Resolving Code Assertion Errors" (Issue #1)

Hey,

thanks for reaching out to us. Can you send me an example file that generates such errors? The test data is quite large. Do you want all meshes?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ugogon]

Ah, I think I understand some of your problems:

The example (e3a_fix) assumes a path to a triangle mesh file. The requirements for this file/mesh are:

1. It must be in a file format that can be loaded by libigl (.ply, .off, .obj, etc.).
2. It must represent a triangulation in 2D with (possibly) flipped triangles.
3. The 2D position is stored as x and y in the vertices. The z coordinate is ignored.
4. ~The boundary of the triangulation must be a triangle.~

~The last point is most likely the root of the error you saw. I should have included a warning in the example if the boundary is not 3 -.-.~

I think our test data is not helpful to you, as it is just a bunch of thingi10k meshes containing flips after applying Tutte's embedding using floating-point arithmetic.

[TaiXiaonan]

Thanks for your answer, I still can't quite understand your fourth point. Is it related to the input file? Because your code includes processing of boundary meshes with more than 3 vertices, it should not matter if the boundary of the input file is complex or not?  As for the test data , I still hope you can provide it to me, because the subsequent comparison with tutte embedding is also the reference part of my learning.  And finally, I want to know, what is the surface parameterization approach that you are taking in your research? Is your input file the result of parameterization?  Thank you again for your reply！

------------------ 原始邮件 ------------------ 发件人: "ugogon/E3A" @.>; 发送时间: 2024年5月9日(星期四) 晚上11:41 @.>; @.**@.>; 主题: Re: [ugogon/E3A] "Request for Test Data and Resolving Code Assertion Errors" (Issue #1)

Ah, I think I understand some of your problems:

The example (e3a_fix) assumes a path to a triangle mesh file. The requirements for this file/mesh are:

It must be in a file format that can be loaded by libigl (.ply, .off, .obj, etc.).

It must represent a triangulation in 2D with (possibly) flipped triangles.

The 2D position is stored as x and y in the vertices. The z coordinate is ignored.

The boundary of the triangulation must be a triangle.

The last point is most likely the root of the error you saw. I should have included a warning in the example if the boundary is not 3 -.-.

I think our test data is not helpful to you, as it is just a bunch of thingi10k meshes containing flips after applying Tutte's embedding using floating-point arithmetic.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ugogon]

Ah yes your are right. We already wrap the mesh. Yes our input is the result of a parameterization. For the paper we used Tutte. I gathered some inputs generated with Tutte that contains flipped triangles: example_input.zip

[TaiXiaonan]

Thank you for your patient answers and selfless sharing!! Since I am still an undergraduate student who is learning a lot of relevant knowledge. Please understand if I ask some stupid questions. 1.how was it discovered that tutte embedding would result in flipped triangles. I opened the example you sent and did not observe the inverted triangle. 

2. why your input file is surrounded by a triangle as normal tutte embeddings can't do this.
3. I sent several input files in my previous reply to you. May I ask if you will get any errors when running? Do you know the source of the errors? Which input condition does not conform to the rule?

------------------ 原始邮件 ------------------ 发件人: "ugogon/E3A" @.>; 发送时间: 2024年5月10日(星期五) 凌晨0:28 @.>; @.**@.>; 主题: Re: [ugogon/E3A] "Request for Test Data and Resolving Code Assertion Errors" (Issue #1)

Ah yes your are right. We already wrap the mesh. Yes our input is the result of a parameterization. For the paper we used Tutte. I gathered some inputs generated with Tutte that contains flipped triangles: example_input.zip

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ugogon]

Hey,

1. I first read about it in Progressive Embedding. Theoretically, there should be no flipped triangles, but due to floating-point precision, the triangle can flip. These flips are very small and usually not visible in renderings. In addition, the renderer maps these vertices to screen coordinates, which adds additional floating-point errors, and usually works in float, not double, adding even more errors to the rendering. So what you see on the screen is not trustworthy. To visualize these flips, you have to write your own renderer that compensates for this.
2. Tutte's method can handle any boundary, so we used a mesh with a single triangle as boundary, mapped it to the unit sphere and run Tutte's method to find the position for all other vertices.
3. I did not receive any files, you can send it to my email finnendahl@tu-berlin.de.