[SofaCombinatorialMaps] dynamic topology into Sofa

[untereiner]

Hi guys,

This PR is a proof of concept to show an alternative implementation dynamic topologies and meshes using the CGOGN library. If you never heard about, CGOGN is a topological modeling kernel (see https://cgogn.github.io) implementing efficiently combinatorial maps to encode the topology and geometrical informations.

The current implementation is based on implementing new topology into new components.

The PR introduce the following components:

• VolumeTopologyContainer
• CMTetrahedralCorotationalFEMForceField
• MapTetrahedronSetTopologyContainer (wrapper that allows to use "classical" sofa components)

The PR is not supposed to be merged in this state and we welcome any feedback on how to improve and generalize this work.

EDIT: I (damien) changed the description of the PR trying to summary the discussion.

EDIT 2: Steps to compile:

• checkout the branch with a modularized version from (https://github.com/mimesis-inria/sofa/tree/cmtopology_module)
• checkout CGoGN in a folder sofa/modules/SofaCombinatorialMaps/cgogn2 Compile and run the examples in sofa/modules/SofaCombinatorialMaps/examples

---

This PR:

• [ ] builds with SUCCESS for all platforms on the CI.
• [ ] does not generate new warnings.
• [ ] does not generate new unit test failures.
• [ ] does not generate new scene test failures.
• [ ] does not break API compatibility.
• [ ] is more than 1 week old (or has fast-merge label).

Reviewers will merge only if all these checks are true.

[damienmarchal]

Wow, thank Lionel for the PR. This is a fat one :)

[untereiner]

😄 I do not know how to proceed for you to test it. Maybe I can add test scenes to start somewhere.

[hugtalbot]

Hi @untereiner could you point us some examples scenes to run with your integration work ? Cheers

[hugtalbot]

and about the process, I think this PR is a very good test case for everyone to give it a try. Regarding the feedback we should be able to package it together as a public plugin.

[hugtalbot]

@untereiner could you please include CGOGN as an external library + separate the core changes and the pluginizable changes Any scene to test ? We are all curious to test it !

[damienmarchal]

Hi @untereiner

From my experience you will have more feedback if you provide more information on the PR description to give other some envy to try it.

Given the complexity of the PR here is what people passing by may need:

• what the PR does precisely ?
• what is the existing state on this topic in Sofa (the title speak about dynamic topology...isn't there dynamic topology in Sofa since year) ?
• how this PR handle the problem,
• use CGOGN library... what is this CGOGN library ?
• argument on why the PR is it useful/mandatory/improvement,
• trying to convince people why they should spend time testing it,
• provide some idea on how invasive the PR will be (non breaking at all, breaking the SofaCore API, breaking existing scenes)

[untereiner]

Hi guys,

Actually I think this PR should not be merged in this state. It is a proof of concept to show the possibilities. I just updated a scene that you can use to test the new components.

The scene called "TetrahedralCorotationalFEMForceField" has two nodes. The first one uses the components "VolumeTopologyContainer" and "CMTetrahedralCorotationalFEMForceField" that are completely written using cgogn and "MapTetrahedronSetTopologyContainer" a compatibility wrapper that allows to use "classical" sofa components with cgogn.

@damienmarchal concerning your questions:

• what the PR does precisely ?
  • This PR adds a new data structure for handling meshes. This data structure is designed to handle dynamic (with topological changes) meshes.
• what is the existing state on this topic in Sofa (the title speak about dynamic topology...isn't there dynamic topology in Sofa since year) ?
  • I think there is a pipeline for topological changes in Sofa. I do not know much about the efficiency of this pipeline. What I can say (I should provide figures) is that this data structure is as effective as the sofa ones in "static" scenarios and more effective and reliable in "dynamic" scenarios.
• how this PR handle the problem,
  • by changing to a more appropriate data structure
• use CGOGN library... what is this CGOGN library ?
  • a topological modeling kernel (see https://cgogn.github.io). I am not sure you need more information about it.
• argument on why the PR is it useful/mandatory/improvement, trying to convince people why they should spend time testing it,
  • this work has been in progress since 3 years now. His interest has already been debated. I do not want to debate an infinite time on it. If someone is interested in topological changes, it should save him time.
• provide some idea on how invasive the PR will be (non breaking at all, breaking the SofaCore API, breaking existing scenes)
  • depends on the meaning of beaking. It does not change the sofa API for topology classes but it adds a hierarchy of classes in the core with a new API and a compatibility layer with the old one.

[damienmarchal]

Thanks for the answers, I moved them to the PR description.

"This work has been in progress since 3 years now. His interest has already been debated. I do not want to debate an infinite time on it. " I searched in the issues and PRs if there was ever any debate on that topic so that I could provide a link in the description but I didn't found one. Maybe you are referring to face to face discussions ? If this was the case maybe writing a summary of these debate (pro/cons) would be very informative and helpful for all of us.

"depends on the meaning of breaking" In general we are considering the following:

• a PR is non breaking if its merge will be un-noticeable for people that don't care of the added feature.
• a PR is breaking the scene if, after the PR, any scenes that was working before is not working anymore.
• a PR is breaking the API if any plugin compiling with master is not compiling anymore after the PR.

Damien

[damienmarchal]

After a quick look here are my notes:

• CM is for CombinatorialMap (in case you wonder :)),

• there are changes on some core mapping that seems to add only minor details as the 'useRestPosition' in SofaKernel/modules/SofaBaseMechanics/BarycentricMapping.h Could this be merged independenty using a fast path.

• could the the extlibs/NGOGN should be removed to help in readbility of the PR

• is it possible that the new topology layer (from sofa/core/topology and SofaBaseTopology) to be moved out of the core in a module/plugin CMTopology and be part of the same cmtopology namespace.

• could the new CMforcefields moved to a module/plugins CMMechanics ?

• why there is files that appears like new files but does not seems to use the cmtopology like ?: modules/SofaMiscFem/ElementFEMForceField.cpp modules/SofaMiscMapping/BeamMapping.h is this a mistake or do I mis-understood something ?

DM. NOTE: I will edit my notes if after more reading I found some note are not relevant.

[guparan]

I'll try to take some time to refactor this.

[guparan]

Here is a rebased + cleaned + updated version without CGoGN: https://github.com/sofa-framework/sofa/compare/master...guparan:cmtopology_rebased_cleaned

To be mixed with this extracted CGoGN: https://github.com/guparan/sofa_cgogn

Please tell me if it works :-)

[damienmarchal]

75 files changes...instead of 1300 :) so much better. Thanks Guillaume.

[untereiner]

Thank you @guparan!

What I see first is:

• [ ] the files modules/SofaMiscFem/HexaFEMForceField.* should be renamed with CM prefix
• [x] the files modules/SofaMiscMapping/BeamMapping.* should be erased (merged from another branch and unrelated to combinatorial topologies )
• [x] the changes to modules/SofaGeneralSimpleFem/BeamFEMForceField.* should be erased (merged from another branch, juste a wip and unrelated to combinatorial topologies)
• [x] And as said by @damienmarchal, the changes related to SofaKernel/modules/SofaBaseMechanics/BarycentricMapping.* should be extracted to another branch (unrelated to combinatorial topologies)
• [x] the modifications in the files modules/SofaGeneralSimpleFem/TetrahedralCorotationalFEMForceField.* should be erased (test work of one of our former trainee)
• [x] The file modules/SofaMiscMapping/BarycentricMappingRigid.h has modifications unrelated to combinatorial topologies should be extracted to another branch too

These modifications should decrease the number of changed files a bit more

[guparan]

the files modules/SofaMiscFem/HexaFEMForceField.* should be renamed with CM prefix

Removed HexaFEMForceField and ElementFEMForceField instead.

[untereiner]

With the help of @guparan with made a few :) changes to this branch. To summarize:

• we made all changes I listed above to remove dead or unrelated code
• since the messages were not very helpfull, all the remaining commits were squashed in a single one which is the contribution.

cgogn is for now an external dependency and has to be checkouted manually in the extlib directory in order to compile the branch. We have to discuss a way to do it automatically (maybe an ExternalProject_Add ?). After a quick check, this proposal is compatible with the last commit of the cgogn devel branch.

[untereiner]

Hi everyone.

I just created a new branch (https://github.com/mimesis-inria/sofa/tree/cmtopology_module) where I put everything into a module called "SofaCombinatorialMaps" instead of using different existing sofa modules. To test it, you just have to put the cgogn repository that @guparan extrated earlier into a sofa/modules/SofaCombinatorialMaps/cgogn2 directory and it should compile :crossed_fingers:. I am able to launch examples/CMTetrahedralCorotationalFEMForceField.scn

[guparan]

This PR now contains the "module" version of cmtopology. Reviews are welcome :+1:

[guparan]

I did some cleaning on the PR but still need some help to make it compile. If someone could check it out that would be great :1st_place_medal:

[hugtalbot]

Well @untereiner the CI is not passing due to an issue of cmake version:

5.4_options_release/build/external_directories/fetched/CGoGN/CGoGN-prefix/src/CGoGN-stamp/CGoGN-configure
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.7.2 or higher is required.  You are running version 3.5.1

we will investigate this next week

[hugtalbot]

Hi @untereiner @guparan

The commit https://github.com/sofa-framework/sofa/pull/700/commits/15a74a5966296d0611e617eaa9f2af4848251f36 seems to lead to a compilation failure

When removing it, ubuntu and MacOS are compiling. Windows crashes: error C2679: binary '>>': no operator found which takes a right-hand operand of type 'const sofa::core::cm_topology::TopologyChange *' (or there is no acceptable conversion) Centos failure was due to assimp: ninja: error: '/lib64/libassimp.so', needed by 'lib/libColladaSceneLoader.so', missing and no known rule to make it

[damienmarchal]

I was looking at he "stalled" PR,

And was wondering about this one, it contains a lot of valuable work and it seems to be connected to the cleanig & refactoring work on topologies started by @epernod.

@guparan , @epernod , @untereiner, @StephaneCotin what are your suggestion on how to move forward and have that work "not lost" ?

[untereiner]

There is only a windows compilation problem if I remember correctly. If someone can solve this issue I think It will be mergeable asap.