STORM-IRIT / Radium-Engine

Research 3D Engine for rendering, animation and processing
https://storm-irit.github.io/Radium-Engine/
Apache License 2.0
100 stars 50 forks source link

Non-Manifold edges/vertices handling in topological mesh #672

Closed nmellado closed 3 years ago

nmellado commented 3 years ago

In several projects, we need to be able to process non-manifold edges/faces when adding them to the topological mesh. Currently, such elements are simply discarded and not added to the topomesh (there is an assert in debug, but nothing in release).

I was wondering if we could add a functor allowing to add specific processing when detecting such cases. The default implementation of this functor could be kept to what we have now (assert+ignore), but anyone could change that.

If we agree on this, I can do the changes. However, I am not familiar with topomesh, and I don't know where we should expose this Functor. @dlyr @MathiasPaulin if you have hints here, that would be helpful. Also, I know that there are more advanced changes planned on topomesh. I see the functor as a very simple and quick way to fix the current state, considering that we need that for two on-going projects (thus the high priority label).

dlyr commented 3 years ago

Well I think there is no way to handle non manifold edges/faces with OpenMesh. We can duplicate the vertices and add the faces, but connectivity will be lost. What kind of processing do you plan for such non manifold meshes ?

nmellado commented 3 years ago

One can duplicate the vertices, other can simply store those faces for further processing, etc... The idea is just to let users know adding custom processing if they want to. This could also be printing some debug information for user feedback.

dlyr commented 3 years ago

Right, I'm not sure how this can be done, because the processing might be done at different steps (some part during conversion, some as a fixup step) see https://www.graphics.rwth-aachen.de/media/openflipper_static/Daily-Builds/Doc/Free/Developer/OBJImporter_8cc_source.html for instance.

nmellado commented 3 years ago

ok, so we could have two functors: one at the conversion stage, and another one at the end, in a fixup stage.

dlyr commented 3 years ago

After discussion, one functor may be sufficient (i.e. fixup) During conversion, we can store the problematic face indices (in a std::vector for instance) Then, the functor takes this list and the mesh as argument and performs whatever the user wants with it. I don't think open mesh handles non manifold face or edge, the doc only speak about non manifold vertices "(like two faces meeting in only one vertex)." So special care must be taken to handle navigation on mesh, simplification, or subdivision (I think this would need to adapt most of the basic functionality of OpenMesh to handle this correctly), but at least debug information can be printed on purpose.

nmellado commented 3 years ago

I have started to work on a proposal with a single functor, will try to submit it as a PR later today.

nmellado commented 3 years ago

Fixed by #675