Ce commit introduit un système hiérarchique de bounding boxes dans les routines de détection du contact. En d'autres termes, il est question de ne plus restreindre l'algorithme aux seuls objets géométriques de bas niveau mais bien de l'étendre autant que possible à tous les niveaux d'objets. Les nœuds des éléments de contact sont ainsi testés par un système de boîtes en cascade. Ce choix est justifié par le fait que l'algorithme réalise des opérations de calcul peu coûteuses en termes de temps CPU et qu'il permet d'exclure des éléments de contact plus en amont dans les routines de détection du contact. Toutefois, un surcoût de calcul pourrait se manifester sur certains cas-tests. La dégradation du temps de calcul ne peut alors le cas échéant être sévère et est espérée négligeable.

Par la même occasion, l'algorithme est étendu effectivement à toute la panoplie d'objets géométriques implémentés dans Metafor (cylindre, spline).

Pour ce faire, en début de chacun des opérateurs de projections, il est ajouté un test de boîte s’il n’était pas présent. Les classes suivantes sont complétées :

• mtGeoWireProjectionOperator,
• SplineSurfaceProjectionOperator,
• mtGeoSkinProjectionOperator,
• mtGeoRevolutionSurfaceProjectionOperator,
• mtGeoCylinderProjectionOperator,
• mtGeoCurveProjectionOperator,
• mtGeoCubicSplineProjectionOperator.

• Quelques corrections sont apportées sur le calcul des boîtes dans les classes mtGeoCubicSpline, mtGeoCubicSplineSeg, mtGeoCylinder et mtGeoRevolutionSurface.
• Il est à noter qu'aucune boîte n'est définie pour un plan. Si la skin comporte un plan, aucun boîte n'est définie pour cette skin.

• La méthode fillNumberedObjectHashSet(NumberedObjectHashSet &_numberedObjectHashSet, const ObjectID &po) est ajoutée dans la classe mtGeoCubicSpline pour permettre l'affichage des boîtes de contact dans VizWin.

Désormais, le reset des boîtes est étendu aux objets géométriques de type contour et skin. Auparavant, le reset était limité aux courbes et surfaces puisque seules les boîtes relatives à ces deux derniers types d'objets géométriques étaient utilisées.

Les animations ci-dessous mettent en évidence le système hiérarchique de bounding boxes.

Cas-test apps.complex.tombeBordEas2D_1

La première animation ci-dessous illustre que l’algorithme de bounding boxes se structure en deux niveaux. En comparaison avec l'animation réalisée lors du commit 1992, on peut relever, outre des boites de couleur violette se rapportant aux objets géométriques de type courbe, des boîtes de couleur verte relatives aux objets de type contour.

Par ailleurs, on peut observer des boites violettes clignotantes pour la même raison qu'expliquée au commit 1992. Par le système hiérarchique de boîtes et la recherche de la première projection géométrique valide, toutes les boîtes relatives aux courbes ne sont pas testées et donc affichées.

Cas-test apps.qs.contactCylProj0

On peut remarquer sur l'animation ci-dessous que l'algorithme de bounding boxes est à présent effectivement opérationnel pour les objets géométriques définis par la classe mtGeoCylinder.

Cas-test apps.qs.contClosedSpline1

On peut remarquer sur l'animation ci-dessous que l'algorithme de bounding boxes est à présent effectivement opérationnel pour les objets géométriques définis par la classe mtGeoCubicSpline.

Cas-tests de profilage

Les animations de profilage présentent les deux possibilités permises par le jeu de données pour la construction des interactions de contact, à savoir des interactions dites 'byRoll' et des interactions globales. Les deux stratégies sont clairement discernables suite au commit 1992 sur l'affichage des bounding boxes dans VizWin. Sur la première animation de profilage, nous observons des boîtes de couleur rouge englobant chacun des outillages, caractéristiques des interactions de contact 'byRoll'. En revanche, pour la seconde animation, nous pouvons dénombrer 3 interactions de contact globales.

De plus, nous pouvons remarquer que l'algorithme de boîtes est désormais étagé en 4 niveaux : skin (rouge), surface (bleu), contour (vert) et courbe (violet).

Enfin, on peut noter que les cas-tests de profilage dans la batterie ont un temps CPU réduit.

Simulation de profilage avec des interactions de contact 'byRoll'

Simulation de profilage avec des interactions de contact globales

En ce qui concerne la simulation lagrangienne de profilage de référence avec une gestion dynamique des interactions de contact, on peut noter que le gain en temps d’horloge se chiffre à 27 % (cf. diagrammes ci-dessous).

Sans boîtes gigognes

Avec boîtes gigognes

Des fuites mémoires ont pu être décelées dans la méthode createMissingSurface() de la classe mtGeoSide. Il s’ensuit une petite baisse du nombre de fuites mémoires sur 2 cas-tests de la batterie : apps.ale.coining3Dusym et apps.ale.cubeCG.

— Yanick Crutzen 2014/06/13