Algorithms Preserve/Calculate Texture Coordinates

[mokafolio]

Is your feature request related to a problem? Please describe.
Right now pmp has limited support for texture coordinates. I.e. seams are preserved during decimation. I'd love to see all of the existing algorithms to become texture coordinate aware. Based on my initial scoping this should only affect algorithms that emit new vertices which in the pmp case might only be the subdivision functions?

At the same time it could be super awesome to add optional tex coord generation to all the shape functions!

Describe the solution you'd like
Make v:tex/h:tex a "core" vertex property that is properly calculated/respected by algorithms if present. Affected functions:

• quad_tri_subdivision
• loop_subdivision
• catmull_clark_subdivision

Please let me know what other functions might be affected, I might start working on a feature branch in the nearish future.

[dsieger]

I'd definitely like to see that as well! Remeshing would be another algorithm to consider...

[mokafolio]

Do you think this should partially work/be implemented at the level of insert_vertex and insert_edge etc. or is that too granular? In my mind that makes sense, just wanted to see if you have any better/other ideas.

[dsieger]

I think this should not be implemented on the core data structure level, but on an algorithm level. We had a similar discussion for the seam-aware decimation. The bottom line is that this is not a responsibility of the mesh data structure.

One other idea would be to provide hooks into the data structure that could check for user-specified conditions, but I would have some concerns about performance implications.

[mokafolio]

Yeah, from a theoretical, architectural standpoint, I tend to agree with that assessment. That said, let's look at quad_tri_subdivision under that assumption. A bulk of the initial logic relies on insert_vertex and insert_edge. If quad_tri_subdivision should be capable to properly deal with uvs, certain things should most likely already happen at the stage of splitting edges. Would you be ok with adding free utility functions in algorithm that could handle this splitting logic in a uv aware way (which would be used inside the algorithms listed above instead of calling insert_vertex etc. directly?). (that of course might have mild performance implications for meshes not using uvs at all)

[mokafolio]

While this might be too extreme, I think another approach could be to treat vertex/half edge properties as first class citizens that automatically get interpolated. That actually makes a lot of sense for many different use cases. We could make this either opt in on a per property basis and possibly allow custom interpolation methods that way, too. Just thinking out loud here :)

[dsieger]

I'm not sure what the purpose of those wrapper functions would be. Maybe you could make this more concrete with some code or pseudo-code? I'd think that deciding what exactly happens with the texture coordinates is specific to the concrete algorithm.

[mokafolio]

After a good night of sleep, I think you are right. I oversimplified/-generalized things a bit too much in my mind yesterday.
I will create a branch and just add uv handling to quad_tri_subdivision for now so you can take a look to ensure we are on the same page before moving on!

[mokafolio]

I added a version of quad_tri_subdivision over here that properly deals with uvs if they are present: https://github.com/mokafolio/pmp-library/tree/moka/uv_algos
Please let me know if that makes sense. Here are two screenshots showing the results of applying it to a uv mapped cube that is open at the bottom.

I think I still need to add some code to properly handle isolated vertices?

[mokafolio]

One thing that I don't like about this approach right now is that it is hard coded to support only one set of uvs. I think it could be super useful to at least allow to somehow support multiple sets of uv coordinates or possibly a more generic way to tell the algorithm what to do with specific properties. That could take a lot of different forms so I just wanted to put that thought out there for the time being!

[mokafolio]

I added uv support for loop_subdivision and catmull_clark_subdivision at the current tip of uv_algos over here. I consolidated a lot of shared logic between the three algorithms along the way, that was kind of what I meant initially with wrapper functions. Let me know if this is somewhat what you had in mind. Still interested to find a solution to make this a little bit more generic (see previous comment).

Screencast.from.07-12-2023.12.29.25.PM.webm

[mokafolio]

I have been digging into the remeshing source to figure out what is required to keep uv's in tact and at this point I am not quite sure if there is a meaningful way to achieve this as the output mesh topology is so drastically different from the input. Here are the current "naive" steps that I think will be necessary:

Preprocessing

• detect seams on input mesh (I think this can be identical to how it is currently handled inside decimate)

Remeshing

• split uv's inside split_long_edges.
• check seams inside collapse_short_edges (this can most likely be identical to texcoord_check in decimate)
• inside flip_edges I guess we need to perform texcoord_check again? In my testing this did not fully fix artifacts and this is the step I am most confused about.
• tangential_smoothing might want to adjust the uvs based on how vertices are moved?
• remove_caps most likely needs to take seams into account, too.

Please let me know if these steps sounds reasonable and if you have any thoughts!

[dsieger]

Awesome progress! I did not yet look at the changes in detail, but I hope to find some time now that 3.0 is out the door.

As for remeshing: I agree this gets ugly and I'm not really sure this is feasible or reasonable. We might think about something simpler along the lines of not trying to preserve the texture coordinates during all those changes but instead to reconstruct them from the original mesh afterwards.

Again, thanks for looking into this! I think this work could be well suited for a 3.1 feature release.