jannessm / quadric-mesh-simplification

Fast python implementation of the quadric mesh simplification algorithm from http://mgarland.org/files/papers/quadrics.pdf
MIT License
103 stars 10 forks source link

Tracking simplification #9

Open CLemeunier opened 3 years ago

CLemeunier commented 3 years ago

Hi !

First, thanks for your work, it works very nicely !

I have a question : what do you think about tracking the simplification ? Could the function to simplify a mesh return like a set of edges and the movement of vertices that were simplified ? With those return infos, it would be possible to apply exactly the same simplification to a mesh that has the same connectivity but that has its vertices other positions.

Thanks !

jannessm commented 3 years ago

Hi @CLemeunier,

this would be a nice addon. Currently, I am very busy. But I will add it to my ToDo list. If you want to, you are highly encouraged to give it a try and implement it by yourself. For this, I would recommend to include a flag to the function to make this behavior optional.

CLemeunier commented 3 years ago

Ok, I can give it a try.

What is the workflow to adopt ? I can see that in the file 'simplify.c' there are two variables 'deleted_positions ' and 'deleted_faces'. Do they indicate by true or false that the vertex / face of the mesh with this index has been deleted ? So I should return those two variables, if a flag is set to true ?

jannessm commented 3 years ago

Regrading the workflow: please implement it and create a pull request so that I can do some quality checks.

Regarding the variables: Yes, exactly. But they do not contain any information about which pairs where contracted. I would suggest to keep track of all contractions. And return a 4 x n array with the following entries for each of the n contracted pairs:

[id of v_1, id of v_2, new vertex id (v_1), influence of old v_1].

And return the deleted_faces array. This will contain almost all information of the simplification process. The movement can be calculated for each pair. But the order matters. Because if v_1 and v_2 are contracted, all references to v_2 will be mapped to the v_1 index. Please reference it in the documentation.

Here some infos regarding the last attribute: all new vertices lie on a line between v_1 and v_2. The line is split into 11 steps (1v_1 + 0v_2, 0.9v_1 + 0.1v_2, ..., 0v_1, 1v_2). To change vertex features the factor of v_1 should be returned, too. (see targets.c)

Additionally, I would only store these informations if the according flag is set to True. Otherwise, it could produce some exzessive memory overhead which is not needed in some cases.

If you have any questions please ask. And thank you for your effort!

CLemeunier commented 3 years ago

Great, thanks for the informations ! I have some work to do, I'll give it a try when I can !

I'll keep you in touch

jannessm commented 3 years ago

No worries. I am glad for your interest and support!