Les calcul d'écrasement de tôle par un rouleau de laminage non lisse (discrétisé par une spline cubique composée de +- 1000 segments très petits) montrait des détections de faux contacts
La routine mtGeoCurveProjectionOperator::iterativeProcedure présentait une boucle “for” dont la non convergence n'était pas traitée (et le hasard faisait que la dernière iteration se trouvait dans la courbe ⇒ la projection était détectée “IN” …et les tests d'appartenance sur le gap ne corrigeaient pas ce problème)
Nb : comme Romain l'a déjà indiqué au vu de l'ALE, il est indispensable de séparer calcul de la projection et validité de celle-ci en terme de gap !!!
Divers
correction du print de Vect3 (version Debug de Ewen commitée)
correction de quelques MaxIte passés en tant que double ⇒ int