Suite à la parallélisation du contact, le calcul et la mise à jour des bounding-boxes pour le contact suivaient 2 schémas différents selon que l'on était en parallèle (via un pré-calcul explicite) ou pas (avec un flag invalidé en amont et le calcul unique de chaque BBox au besoin)
au delà de devoir gérer 2 schéma d'intégration selon le parallélisme, chaque méthodes avaient son inconvénient :
Le pré-calcul des BBox (pour les calculs parallèles) pouvait amener à calculer plusieurs fois le même outil (si il participait à plusieurs interactions de contact)
l'invalidation des BBox et le calcul au besoin nécessiterait un mutex au moment du calcul de la BBox, ce qui n'est pas optimal du tout
Le choix s'est posé sur un mix des 2 méthodes :
les BBox conservent leurs flags de validité (pour ne calculer que 1 seule fois chaque BBox)
les BBox sont explicitement invalidées à chaque pas de temps (RDContactInteraction) ou chaque iteration (DDContactInteraction)
le calcul des BBox est explicitement appelé hors boucle parallèle (nb : pour les outils facetisés, les boucles sur les facettes pourraient être rendues parallèles) et une seule fois par objet grace au flax de validité
Dans la mesure des possibilités, chaque objet sur lequel on calcule une bbox conserve celle-ci (quitte à légèrement augmenter la mémoire) et on essaye de ne plus “rediriger” des bbox
Attention, il reste un soucis sur les QuadSide dont les BBoxes sont calculées sur base des 4 points, et le projectionOperator est le SurfaceOperator générique (d'où la copie de la BBox QuadSide vers la surface sous-jascente)
Attention2 : les BBoxes sont aussi utilisées dans le remaillage (mais de manière moins claire) à travers les fonctions “insideForConvexe”, “preCompute2BoundingBox”,…
Attention 3 : l'interaction entre BBox et les méthodes d'arbre WithBoundaryVolume ne me semblent pas nécessairement très claire (⇒ si vous observez un soucis, n'hésitez pas)
To Be Continued : Un certain nombre d'opérations géométrique m'ont interpellé en tombant dessus et une grosse remise à plat serait bénéfique à la lisibilité du code. Des refactoring à prévoir serait :
d'implémenter des opérateurs de projection optimisé pour les faces maillées (QuadSide)
supprimer la couche “ProjectionOperator” en créant un “ProjectionData” reprenant les paramètres de projection et en déplacant les fonctions de projection dans les classes géométriques
…