[Core] Convert warning to error in object factory

[alxbilger]

I converted the warning to an error in the following code of the ObjectFactor:

        if (isUserTemplateNameInTemplateList)
        {
            msg_warning(object.get()) << "Requested template '" << usertemplatename << "' "
                                      << "is not compatible with the current context. "
                                      << "Falling back to the first compatible template: '"
                                      << object->getTemplateName() << "'.";
        }
        else
        {
            msg_warning(object.get()) << "Requested template '" << usertemplatename << "' "
                                      << "cannot be found in the list of available templates [" << ss.str() << "]. "
                                      << "Falling back to default template: '"
                                      << object->getTemplateName() << "'.";
        }

To me, this situation is to be taken into account more seriously than a warning.

As failing template deduction is now an error, it leads to a lot of failing tests. I fixed them as well.

I added unit tests for OglModel. I factorize the parse code from the 3 masses.

---

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

---

Reviewers will merge this pull-request only if

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

[damienmarchal]

Looks ok to me.

EDIT: @alxbilger want to remove the new errors.

[alxbilger]

[ci-build][with-scene-tests]

[alxbilger]

@fredroy Was there a mechanism to support DiagonalMass template="Vec3d"? Or does it only fall back to DiagonalMass template="Vec3d,Vec3d" because it is the default template?

[fredroy]

@fredroy Was there a mechanism to support DiagonalMass template="Vec3d"? Or does it only fall back to DiagonalMass template="Vec3d,Vec3d" because it is the default template?

Nope, there is a check to see if the 2nd template is the previous MassType (removed) but there is no mechanism to implicitly suppose the geometry type to be like the data type of the mass (which is like 99.999% of the time actually) Do you think it would be a good idea to do it ? (aka if no 2nd template, then implictely suppose it is the same as the the 1st one)

[alxbilger]

@fredroy I prefer not adding another implicit complex mechanism for templates. If there are two templates, the user must set 2 templates. If the user set only one, there is an error message containing the list of all available templates. It should give a hint about the fact that there are two templates to provide.

[alxbilger]

[ci-build][force-full-build][with-all-tests]

[sofabot]

[ci-depends-on] detected during build #9.

To unlock the merge button, you must

• Merge or close https://github.com/sofa-framework/ManifoldTopologies/pull/6 _For this build, ManifoldTopologies/ExternalProjectConfig.cmake.in will be edited by builders with GIT_REPOSITORY https://github.com/sofa-framework/ManifoldTopologies GITTAG 7e63fdff87d8dea05beaa2668fbc84d364404821
• Merge or close https://github.com/sofa-framework/Registration/pull/6 _For this build, Registration/ExternalProjectConfig.cmake.in will be edited by builders with GIT_REPOSITORY https://github.com/sofa-framework/Registration GITTAG 65155e9985b4b31d24d169fb69f7fd6bab74dfbe

[sofabot]

[ci-depends-on] detected during build #10.

To unlock the merge button, you must

• Merge or close https://github.com/sofa-framework/ManifoldTopologies/pull/6 _For this build, ManifoldTopologies/ExternalProjectConfig.cmake.in will be edited by builders with GIT_REPOSITORY https://github.com/sofa-framework/ManifoldTopologies GITTAG 1623e8023d58313e5b30e244fb998797e057e352
• Merge or close https://github.com/sofa-framework/Registration/pull/6 _For this build, Registration/ExternalProjectConfig.cmake.in will be edited by builders with GIT_REPOSITORY https://github.com/sofa-framework/Registration GITTAG 1edd80521f6493f4716a922e5b9f552e4f7e41e6

[sofabot]

[ci-depends-on] detected during build #11.

To unlock the merge button, you must

• Merge or close https://github.com/sofa-framework/ManifoldTopologies/pull/6 _For this build, ManifoldTopologies/ExternalProjectConfig.cmake.in will be edited by builders with GIT_REPOSITORY https://github.com/sofa-framework/ManifoldTopologies GITTAG 231198ab18ca3efb8c1042cbc8abbe08c1d89551
• Merge or close https://github.com/sofa-framework/Registration/pull/6 _For this build, Registration/ExternalProjectConfig.cmake.in will be edited by builders with GIT_REPOSITORY https://github.com/sofa-framework/Registration GITTAG 1edd80521f6493f4716a922e5b9f552e4f7e41e6

[alxbilger]

Some image plugin scenes fail because the template used is not compiled in the standard set. It needs the full set. Only the standard set is compiled on the CI.

Decision to take: 1) The failing scenes are ignored on the CI 2) The failing scenes are modified to use a templated available in the standard set 3) The CI compiled the full set

I am in favor of the third option, but we already talked about it in https://github.com/sofa-framework/ci/pull/15. It seems to take too much time at the compilation.

[fredroy]

Some image plugin scenes fail because the template used is not compiled in the standard set. It needs the full set. Only the standard set is compiled on the CI.

Decision to take:

1. The failing scenes are ignored on the CI

2. The failing scenes are modified to use a templated available in the standard set

3. The CI compiled the full set

I am in favor of the third option, but we already talked about it in sofa-framework/ci#15. It seems to take too much time at the compilation.

I think there is a 4th solution, adding the ImageB type in the "standard" set, as it is seems quite important if lots of scenes need it after all

[alxbilger]

@fredroy Excellent suggestion. I'll do that. Thanks

[sofabot]

[ci-depends-on] detected during build #12.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[sofabot]

[ci-depends-on] detected during build #13.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[sofabot]

[ci-depends-on] detected during build #14.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[sofabot]

[ci-depends-on] detected during build #15.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[alxbilger]

@fredroy I applied your suggestion, but there are remining failing scenes. I suggest to ignore them on the CI.

[sofabot]

[ci-depends-on] detected during build #16.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[sofabot]

[ci-depends-on] detected during build #17.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[alxbilger]

@hugtalbot Can you remind me why you switch this pull request back to wip?

[fredroy]

If I remember, just because there are conflicts to solve

[sofabot]

[ci-depends-on] detected during build #18.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[alxbilger]

[ci-build][with-scene-tests]

[sofabot]

[ci-depends-on] detected during build #19.

All dependencies are merged/closed and all ExternalProject pointers are up-to-date. Congrats! :+1:

[alxbilger]

[ci-build][force-full-build][with-all-tests]

[fredroy]

[ci-build][force-full-build][with-all-tests]

[fredroy]

Conflicts were solved, tests are OK, and it has been long enough this PR is opened;ready to merge