Prefab management

[hugtalbot]

Status of prefabs could be discussed further:

• should they be located in the SofaPython3 plugin?
• should we create many level of abstractions/prefabs?
• definition of current prefabs, e.g. ElasticObject using a UniformMass?

[damienmarchal]

Glad to see someone asking question on that topic. Since the release of sofapython3, I'm waiting someone having interest on that topic so we can modernize the prefab's using the added feature of sp3 and experience gained since sofapython2.

Short answers to your questions:

• should they be located in the SofaPython3 plugin? It is unclear to me about what you are talking about, prefab are already in SofaPython3. Are you in fact talking about the prefab that are in stlib ? If this is the case, it make sense to have prefab in SofaPython3 to demonstrate a "standard" way of doing a prefab through "examples", there could also have a standard prefab library, but I see no problem in having that in stlib or any other third party plugin. That's said, I don't consider the prefab in stlib mature enough for such move, first, because they are still implemented as they were back to python2 time, and up to now, not a lot of people have expressed interest in changing that to move forward;

• should we create many level of abstractions/prefabs? From the experience in stlib there is always a trade-off between abstraction and usability and the overhead of modularization. But yes, there is always an interest in being able to build prefab from other prefab to make complex systems.

• definition of current prefabs, e.g. ElasticObject using a UniformMass? Prefab just means you have an "all-in-one" object. There is no more constraint except from that. So it the choice of the one that make a prefab to decide prefabricating "what". That's said it is highly desirable to have set of prefabs that shares common structures and idioms so they are interoperable in the same scene.

Additional point:

• the prefabs implementation in SofaPython3 is only partially working and some fix are required

• there is a far too much limited support for prefab in our user interface, if we are going for generalize their use then additional support should be added.(eg: right-click navigating itno prefab should be implemented, dedicated icons in the scene graph, docbrowser linking the the prefab documentation => so updating the prefab documentation now we managed to fix the sofapython3 one)

• there is also non trivial issues related to design practices, especially on re-usability through inheritance, composition or prototypes.

• there is an issue smoothing transition from a scene to a prefab (visible in the two way by which you can define a prefab, with the python decorator or by in-heriting from Sofa.Prefab)

• there is also issues related to the fact that Sofa is relying on the scenegraph to do the simulation, this has the consequence that currently some useful scene-patterns are not easy to make through prefab. I think the work from @alxbilger on refactoring the animation loop and solving relax these constraints... I'm not sure it is at the point there is no more contraint so we can freely move on that.

Probably there is many more on that... but I can for sure make a clear summary of all that are missing before having prefab first class citizen in SofaPython3 :)