Aller au contenu
Table des matières

ipc-toolkit : Les requêtes de collision comme frontière de bibliothèque

ipc-toolkit fournit des composants géométriques pour la simulation avec contacts. Ce fork contient maillages de collision, candidats, détection continue et énergies de contact. Une simulation externe conserve la gestion du temps et de la résolution.

Bibliothèque Fork Algorithme
  • Mis à jour
  • C++ · 94.46%
  • MIT
C++CCDCMake C/C++ (CMake) Python Catch2 Crédit amont
Composants documentés
2Explorer les modules
Documents source
6Lire les instructions
Langages du dépôtC++ 94.46%5

Parts calculées à partir des octets GitHub Linguist.

C++94.46%
94.46%2 400 346 octets
CMake2.98%
2.98%75 800 octets
Python2.1%
2.1%53 463 octets
Cuda0.38%
0.38%9 561 octets
Langage%Octets
C++94.46%2 400 346
CMake2.98%75 800
Python2.1%53 463
Cuda0.38%9 561
Dockerfile0.08%2 051

1. Aperçu

1.1. Pourquoi il existe

Boîte à outils d'ingénierie pour la gestion du contact et de la friction dans les simulations par éléments finis.

1.2. Cas d’usage

Mécanique du contact continu non linéaire pour moteurs physiques.

2. Cas d’utilisation

Bibliothèque C++ avec liaisons Python pour l’Incremental Potential Contact : barrières, CCD et frottement pour simulateurs.

Diagramme de cas d’utilisation de ipc-toolkit : Construire un maillage; Trouver les contacts sous dhat; Évaluer barrière et dérivées; Obtenir un pas sans collision; Ajouter le frottement; Le piloter depuis Pythonipc-toolkitConstruire un maillageTrouver les contacts sous dhatÉvaluer barrière et dérivéesObtenir un pas sans collisionAjouter le frottementLe piloter depuis PythonDéveloppeur simulation«système»Simulateur hôte
Acteurs à gauche (personnes) et à droite (systèmes externes) ; chaque ovale est un cas d’utilisation appuyé par les fichiers cités ci-dessous.
Construire un maillage
Développeur simulation

ipc::CollisionMesh reçoit les matrices de sommets, d’arêtes et de faces (Eigen), comme dans le démarrage rapide du README.

Trouver les contacts sous dhat
Développeur simulationSimulateur hôte

NormalCollisions::build() s’appuie sur une phase large (grille de hachage, LBVH, balayage…) pour réunir les paires de primitives plus proches que dhat.

Évaluer barrière et dérivées
Développeur simulationSimulateur hôte

BarrierPotential renvoie l’énergie, le gradient et la hessienne creuse que le solveur hôte ajoute à son objectif.

Obtenir un pas sans collision
Développeur simulationSimulateur hôte

compute_collision_free_stepsize() lance la détection de collision continue (Tight Inclusion par défaut, variantes non linéaire et additive dans src/ipc/ccd) entre deux états de sommets.

Ajouter le frottement
Développeur simulationSimulateur hôte

FrictionPotential agit sur les TangentialCollisions ; smooth_mu.hpp ajoute des coefficients de frottement anisotrope elliptique (commit Anisotropic friction #210).

Le piloter depuis Python
Développeur simulation

Les liaisons pybind11 de python/src exposent la même API sous ipctk (pip install ipctk), compilées quand IPC_TOOLKIT_BUILD_PYTHON est activé.

2.1. Scénario : Ajouter le contact à un pas de temps implicite

  1. Installer les liaisons avec pip install ipctk, ou ajouter la bibliothèque à un projet CMake.
  2. Créer un CollisionMesh à partir des sommets, arêtes et faces de la scène.
  3. Construire les NormalCollisions avec dhat = 1e-3 pour les positions actuelles.
  4. Ajouter l’énergie, le gradient et la hessienne de BarrierPotential au système de Newton du solveur.
  5. Avant d’accepter le pas de Newton, le limiter avec compute_collision_free_stepsize pour qu’aucune surface ne se traverse.

Fichiers consultésREADME.mdCMakeLists.txtsrc/ipc/ipc.hppsrc/ipc/collision_mesh.hppsrc/ipc/potentials/barrier_potential.hppsrc/ipc/friction/smooth_mu.hpppython/src/bindings.cpp

3. Démarrage

Ces commandes viennent de la documentation du dépôt. Elles n’ont pas été exécutées pendant cette revue.

python/README.md · Installation
pip install ipctk
python/README.md · Installation
pip install git+https://github.com/ipc-sim/ipc-toolkit
python/README.md · Build
pip install .
python/README.md · Build
python -c "import ipctk"
python/README.md · CMake Build
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DIPC_TOOLKIT_BUILD_PYTHON=ON ..
make -j$(nproc)

4. Références du dépôt

Extraits des guides du dépôt, dans leur langue d’origine. Les liens ouvrent la version du code consultée.

Prérequis et premier essai

4.1. Quick Start

README.md

C++ (include via CMake; see build instructions): Python (install via pip install ipctk): For more details, see the tutorials and API documentation.
Lire les instructions complètes ↗

4.2. Installation

python/README.md

To install the latest release, you can use pip: If you wish to install the current development code, you can compile the library from scratch. Either clone the repo manually or use git+ with pip:
Lire les instructions complètes ↗
Développement et contributions

4.3. Contributing

README.md

This project is open to contributors! Contributions can come in the form of feature requests, bug fixes, documentation, tutorials, and the like. We highly recommend filing an Issue first before submitting a Pull Request. Simply fork this repository and make a Pull Request! We would appreciate:

  • Implementation of new features
  • Bug Reports
  • Documentation
  • Testing
Lire les instructions complètes ↗

4.4. Contributing (CONTRIBUTING.md)

docs/CONTRIBUTING.md

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
Lire les instructions complètes ↗
Documentation source

6 documents lus parmi 6 candidats.

5. Fonctions et composants 2

Géométrie et requêtes de collision
ipc.hpp prend un CollisionMesh et des positions pour vérifier les intersections ou un déplacement sans collision. Les phases large et étroite ont des paramètres explicites avec valeurs par défaut, séparant candidats et tests détaillés.
Calculs de contact
L’arborescence sépare distance, barrière, friction, tangente et potentiels. Ces composants alimentent les objectifs et dérivées de l’appelant, sans intégrer automatiquement toute une scène physique.

6. Architecture

Ouvrez un composant pour suivre ses connexions, ou explorez le diagramme complet.

Composants du système Contexte
Mermaid Diagramme interactif

Vue générale des composants et des échanges vérifiés dans le dépôt.

Vue statique de l’architecture de ipc-toolkit
Aperçu statique. Le diagramme interactif le remplace après le chargement de Mermaid.
flowchart LR
  n0["Simulation externe"]
  n1["Maillage et déplacement des sommets"]
  n2["Candidats de phase large"]
  n3["Détection continue précise"]
  n4["Résultat de collision"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
Version texte du diagramme
  • Simulation externe → Maillage et déplacement des sommets
  • Maillage et déplacement des sommets → Candidats de phase large
  • Candidats de phase large → Détection continue précise
  • Détection continue précise → Résultat de collision
  • Résultat de collision → Simulation externe
Suivre un parcours dans le code

Suivez is_step_collision_free depuis sa déclaration. Le résultat répond à une requête géométrique pour un déplacement proposé. L’appelant décide comment cela change son pas, sa recherche linéaire ou sa résolution de contact.

7. Dossier technique

Établi à partir du code au commit 4d9e47e (473 fichiers). Chaque élément vient d’une correspondance de motif dans le code: ouvrez le fichier lié avant de vous y fier.

7.1. Couches et modules

Les dossiers sont classés par couche selon leur nom, de l’interface utilisateur jusqu’à l’accès aux données. Comme le classement repose sur les noms seulement, le diagramme ne dit rien des appels entre couches.

Mermaid Vue en couches
flowchart TB
  subgraph L_domain["Domaine et règles métier"]
    direction TB
    domain_0["ipc/geometry<br/>8 fichiers"]
    domain_1["ipc/math<br/>5 fichiers"]
    domain_2["python/geometry<br/>5 fichiers"]
    domain_3["ipc/distance<br/>2 fichiers"]
    domain_more["+3"]
  end
  subgraph L_infrastructure["Données et infrastructure"]
    direction TB
    infrastructure_0["ipc/utils<br/>2 fichiers"]
  end
  subgraph L_core["Source principale"]
    direction TB
    core_0["ipc/smooth_contact<br/>32 fichiers"]
    core_1["ipc/collisions<br/>26 fichiers"]
    core_2["ipc/distance<br/>22 fichiers"]
    core_3["ipc/broad_phase<br/>21 fichiers"]
    core_more["+29"]
  end
  subgraph L_tests["Tests"]
    direction TB
    tests_0["tests<br/>71 fichiers"]
    tests_1["python<br/>9 fichiers"]
  end
  subgraph L_hosting["Build, CI et hébergement"]
    direction TB
    hosting_0["ipc<br/>22 fichiers"]
    hosting_1["python<br/>18 fichiers"]
    hosting_2[".github<br/>12 fichiers"]
    hosting_3[".devcontainer<br/>2 fichiers"]
    hosting_more["+2"]
  end
  L_domain ~~~ L_infrastructure
  L_infrastructure ~~~ L_core
  L_core ~~~ L_tests
  L_core ~~~ L_hosting
Modules et couche principale
ModuleCoucheFichiersTypesExtensions
ipc/smooth_contactSource principale3227.hpp .cpp
ipc/collisionsSource principale2615.hpp .cpp
ipc/distanceSource principale240.cpp .hpp
ipc/broad_phaseSource principale2115.hpp .cpp
ipc/candidatesSource principale189.cpp .hpp
ipc/ccdSource principale187.hpp .cpp
ipc/utilsSource principale1813.hpp .cpp
python/collisionsSource principale170.cpp .hpp
ipc/potentialsSource principale147.cpp .hpp
python/distanceSource principale110.cpp .hpp
python/broad_phaseSource principale101.cpp .hpp
python/candidatesSource principale100.cpp .hpp
python/ccdSource principale103.cpp .hpp
ipc/geometryDomaine et règles métier80.cpp .hpp

23 modules plus petits ne sont pas affichés.

7.2. Modèle C4

Du contexte du système aux déclarations du code. Chaque niveau conserve les limites des sources disponibles.

UML 1 · Contexte du système
1 · Contexte du système

La vue C4 la plus large : qui utilise le projet et sur quels systèmes et stockages externes il s’appuie. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Context>
LAYOUT_LEFT_RIGHT()
Person(P_cli, "Utilisateur CLI")
System(SYS, "ipc-toolkit", "ipc-toolkit fournit des composants géométriques pour la simulation av…")
Rel(P_cli, SYS, "Utilise")
@enduml
UML 2 · Conteneurs
2 · Conteneurs

Un niveau plus près : les parties qui s’exécutent séparément dans le projet, leur langage principal et le chemin des appels entre elles. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Container>
LAYOUT_LEFT_RIGHT()
Person(P_cli, "Utilisateur CLI")
System_Boundary(SYS, "ipc-toolkit") {
  Container(APP, "ipc-toolkit", "C++")
}
Rel(P_cli, APP, "Utilise")
@enduml
UML 3 · Composants et couches
3 · Composants et couches

Modules regroupés par couche du code. Les limites indiquent l’organisation, sans affirmer une isolation à l’exécution ni des appels. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Component>
LAYOUT_TOP_DOWN()
System_Boundary(SYS, "ipc-toolkit") {
Boundary(L0, "Présentation", "layer") {
Component(M0_0, "docs/_static", ".css, HTML", "2 fichiers")
Component(M0_1, "docs/_templates", "HTML", "1 fichiers")
}
Boundary(L1, "Domaine et règles métier", "layer") {
Component(M1_0, "ipc/geometry", "C++", "8 fichiers")
Component(M1_1, "ipc/math", "C++", "5 fichiers")
Component(M1_2, "python/geometry", "C++", "5 fichiers")
Component(M1_3, "ipc/distance", "C++", "2 fichiers")
Component(M1_4, "python/math", "C++", "2 fichiers")
Component(M1_5, "ipc/utils", "C++", "1 fichiers")
Component(M1_6, "python/distance", "C++", "1 fichiers")
}
Boundary(L2, "Données et infrastructure", "layer") {
Component(M2_0, "ipc/utils", "C++", "2 fichiers")
}
Boundary(L3, "Source principale", "layer") {
Component(M3_0, "ipc/smooth_contact", "C++", "32 fichiers")
Component(M3_1, "ipc/collisions", "C++", "26 fichiers")
Component(M3_2, "ipc/distance", "C++", "22 fichiers")
Component(M3_3, "ipc/broad_phase", "C++", "21 fichiers")
Component(M3_4, "ipc/candidates", "C++", "18 fichiers")
Component(M3_5, "ipc/ccd", "C++", "18 fichiers")
Component(M3_6, "python/collisions", "C++", "17 fichiers")
Component(M3_7, "ipc/utils", "C++", "15 fichiers")
Component(M3_more, "+25 modules", "", "")
}
Boundary(L4, "Tests", "layer") {
Component(M4_0, "tests", "C++", "71 fichiers")
Component(M4_1, "python", "Python", "9 fichiers")
}
Boundary(L5, "Build, CI et hébergement", "layer") {
Component(M5_0, "ipc", ".txt", "22 fichiers")
Component(M5_1, "python", ".txt", "18 fichiers")
Component(M5_2, ".github", ".yml, .md", "12 fichiers")
Component(M5_3, ".devcontainer", "Dockerfile, .json", "2 fichiers")
Component(M5_4, "(root)", ".txt", "1 fichiers")
Component(M5_5, "docs", "Makefile", "1 fichiers")
}
}
@enduml
UML 4 · Code
4 · Code

Déclarations, champs et méthodes sélectionnés, regroupés par fichier source. Aucun héritage ni appel n’est déduit. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
top to bottom direction
hide empty members
package "ipc-toolkit" {
package "src/ipc/collision_mesh.hpp" as F0 {
class "CollisionMesh" as T0_0 {
  build_from_full_mesh()
  init_adjacencies()
  init_area_jacobians()
  num_vertices()
  num_codim_vertices()
  num_codim_edges()
}
}
package "src/ipc/math/math.hpp" as F1 {
class "Math" as T1_0 {
  sign()
  abs()
  sqr()
  cubic()
  cubic_spline()
  cubic_spline_grad()
}
}
package "src/ipc/candidates/collision_stencil.hpp" as F2 {
class "CollisionStencil" as T2_0 {
  num_vertices()
  dim()
  vertex_ids()
  vertices()
  dof()
  compute_distance()
}
}
package "src/ipc/collisions/normal/normal_collisions.hpp" as F3 {
class "NormalCollisions" as T3_0 {
  build()
  compute_minimum_distance()
  size()
  empty()
  clear()
  is_vertex_vertex()
}
}
package "src/ipc/broad_phase/lbvh.hpp" as F4 {
class "LBVH" as T4_0 {
  name()
  clear()
  detect_vertex_vertex_candidates()
  detect_edge_vertex_candidates()
  detect_edge_edge_candidates()
  detect_face_vertex_candidates()
}
class "MortonCodeElement" as T4_1 {
  morton_code
  box_id
  std
  parent
}
class "ConstructionInfo" as T4_2 {
  parent
  std
}
}
package "src/ipc/broad_phase/broad_phase.hpp" as F5 {
class "BroadPhase" as T5_0 {
  name()
  build()
  clear()
  detect_collision_candidates()
  detect_vertex_vertex_candidates()
  detect_edge_vertex_candidates()
}
}
package "src/ipc/candidates/candidates.hpp" as F6 {
class "Candidates" as T6_0 {
  build()
  size()
  empty()
  clear()
  is_step_collision_free()
  compute_collision_free_stepsize()
}
}
package "src/ipc/broad_phase/hash_grid.hpp" as F7 {
class "HashGrid" as T7_0 {
  name()
  clear()
  detect_vertex_vertex_candidates()
  detect_edge_vertex_candidates()
  detect_edge_edge_candidates()
  detect_face_vertex_candidates()
}
}
package "src/ipc/broad_phase/sweep_and_prune.hpp" as F8 {
class "SweepAndPrune" as T8_0 {
  name()
  build()
  clear()
  detect_vertex_vertex_candidates()
  detect_edge_vertex_candidates()
  detect_edge_edge_candidates()
}
}
package "src/ipc/smooth_contact/primitives/edge3.hpp" as F9 {
class "Edge3" as T9_0 {
  n_vertices()
  n_dofs()
  n_face_neighbors()
  potential()
  grad()
  hessian()
}
}
package "src/ipc/broad_phase/sweep_and_prune.cpp" as F10 {
class "Boxes" as T10_0 {
  std
  SweepAndPrune
}
}
package "src/ipc/broad_phase/broad_phase.cpp" as F11 {
class "MeshDomain" as T11_0 {
  Eigen
  tbb
}
}
package "src/ipc/smooth_contact/distance/primitive_distance.hpp" as F12 {
class "PrimitiveDistType" as T12_0 {
  PrimitiveA
  Eigen
}
}
package "src/ipc/math/interval.hpp" as F13 {
class "ScalarBinaryOpTraits" as T13_0 {
  ReturnType
}
class "formatter" as T13_1 {
  filib
}
}
package "python/src/collision_mesh.cpp" as F14 {
class "PairHash" as T14_0 {
  std
}
}
package "src/ipc/utils/default_init_allocator.hpp" as F15 {
class "rebind" as T15_0 {
  a_t
}
}
package "src/ipc/utils/autodiff_types.hpp" as F16 {
class "IsADGrad" as T16_0 {
}
class "IsADHessian" as T16_1 {
}
}
}
@enduml

7.3. Interface publique

Du code extérieur peut utiliser tout ce qui est listé ici. Le projet déclare aussi 122 types publics.

Ligne de commande 1

7.4. Interface privée

Ces noms sont internes selon les conventions du langage: tiret bas initial, private, static ou pub(crate).

Espace de noms anonyme
25

Modules privés

python/_find_ipctk.py

7.5. Entités et modèle de données 12

Mermaid Diagramme de classes des entités
classDiagram
  direction LR
  class E0["MortonCodeElement"] {
    +uint64_t morton_code
    +size_t box_id
    +:string std
    +int parent
  }
  class E1["Boxes"] {
    +:vector std
    +:SweepAndPrune SweepAndPrune
  }
  class E2["ConstructionInfo"] {
    +int parent
    +:vector std
  }
  class E3["MeshDomain"] {
    +Constant Eigen
    +:blocked_range tbb
  }
  class E4["PrimitiveDistType"] {
    +:N_CORE_POINTS PrimitiveA
  }
  class E5["ScalarBinaryOpTraits"] {
    +typedef ReturnType
  }
  class E6["formatter"] {
    +:Interval filib
  }
  class E7["PairHash"] {
    +:size_t std
  }
  class E8["rebind"] {
    +:construct a_t
  }
  class E9["IsADGrad"] {
  }

Une flèche relie un champ à l’entité que son type nomme.

EntitéNaturePremiers champs
MortonCodeElementStructure de donnéesmorton_code, box_id, std, parent
BoxesStructure de donnéesstd, SweepAndPrune
ConstructionInfoStructure de donnéesparent, std
MeshDomainStructure de donnéesEigen, tbb
PrimitiveDistTypeStructure de donnéesPrimitiveA, Eigen
ScalarBinaryOpTraitsStructure de donnéesReturnType
formatterStructure de donnéesfilib
PairHashStructure de donnéesstd
Afficher 4 entités de plus
PrimitiveDistTypeStructure de donnéesPrimitiveA
rebindStructure de donnéesa_t
IsADGradStructure de données
IsADHessianStructure de données

7.6. Logique métier

Une fois écartés le code d’interface et les services et entités ci-dessus, ces classes ont le plus de méthodes.

CollisionMesh Source principale, 36 méthodes
build_from_full_mesh, init_adjacencies, init_area_jacobians, num_vertices, num_codim_vertices, num_codim_edges
Math Domaine et règles métier, 19 méthodes
sign, abs, sqr, cubic, cubic_spline, cubic_spline_grad
CollisionStencil Source principale, 19 méthodes
num_vertices, dim, vertex_ids, vertices, dof, compute_distance
NormalCollisions Source principale, 19 méthodes
build, compute_minimum_distance, size, empty, clear, is_vertex_vertex
LBVH Source principale, 18 méthodes
name, clear, detect_vertex_vertex_candidates, detect_edge_vertex_candidates, detect_edge_edge_candidates, detect_face_vertex_candidates
BroadPhase Source principale, 17 méthodes
name, build, clear, detect_collision_candidates, detect_vertex_vertex_candidates, detect_edge_vertex_candidates
Candidates Source principale, 15 méthodes
build, size, empty, clear, is_step_collision_free, compute_collision_free_stepsize
HashGrid Source principale, 14 méthodes
name, clear, detect_vertex_vertex_candidates, detect_edge_vertex_candidates, detect_edge_edge_candidates, detect_face_vertex_candidates
SweepAndPrune Source principale, 14 méthodes
name, build, clear, detect_vertex_vertex_candidates, detect_edge_vertex_candidates, detect_edge_edge_candidates
Edge3 Source principale, 13 méthodes
n_vertices, n_dofs, n_face_neighbors, potential, grad, hessian

7.7. Stack et dépendances

C/C++ (CMake) CMakeLists.txt 1 à l’exécution

C++17

Ouvrir le manifeste

Python pyproject.toml 2 à l’exécution

Python >=3.6

Ouvrir le manifeste

Dépendances externes

3 paquets déclarés (3 à l’exécution, 0 pour le développement) dans CMakeLists.txt, pyproject.toml.

Tableau des paquets 3
Dépendances externes
PaquetVersionUsageRôleRegistre
SIMD—exécution—C/C++ (CMake)
numpy—exécutionAnalyse de donnéespypi.org
scipy—exécutionAnalyse de donnéespypi.org

7.8. Pipeline CI/CD

8 workflows GitHub Actions, 10 tâches. Chaque boîte est une tâche ; les boîtes à double bord publient ou déploient, et les flèches suivent les dépendances needs.

Mermaid Déroulement du pipeline
flowchart LR
  subgraph wf0["clang-format Check"]
    direction LR
    wf0_formatting_check["Formatting Check<br/>ubuntu-latest"]
  end
  subgraph wf1["Clang-Tidy Check"]
    direction LR
    wf1_clang_tidy["Run Clang-Tidy<br/>ubuntu-latest"]
  end
  subgraph wf2["Build"]
    direction LR
    wf2_Build["Build<br/>matrix"]
  end
  subgraph wf3["Coverage"]
    direction LR
    wf3_Coverage["Code Coverage<br/>ubuntu-latest"]
  end
  subgraph wf4["CUDA"]
    direction LR
    wf4_Build["CUDA<br/>ubuntu-latest"]
  end
  subgraph wf5["Docs"]
    direction LR
    wf5_Docs[["Docs<br/>ubuntu-latest"]]
  end
  t0(["push · demande de fusion"])
  t1(["lancement manuel · push"])
  d0[("GitHub Pages")]
  t0 --> wf0_formatting_check
  t0 --> wf1_clang_tidy
  t0 --> wf2_Build
  t0 --> wf3_Coverage
  t0 --> wf4_Build
  t1 --> wf5_Docs
  wf5_Docs -.-> d0
Workflows, déclencheurs, tâches et cibles
WorkflowDéclencheursTâchesPublie vers
clang-format Check
.github/workflows/clang-format-check.yml
push, demande de fusion
  • Formatting Check ubuntu-latest
    actions/checkout · clang-format style check
—
Clang-Tidy Check
.github/workflows/clang-tidy-check.yml
push, demande de fusion
  • Run Clang-Tidy ubuntu-latest
    Checkout code · Install dependencies · Get number of CPU cores · Configure CMake · Run Clang-Tidy
—
Build
.github/workflows/continuous.yml
push, demande de fusion
  • Build matrix
    Checkout repository · Dependencies (Linux) · Dependencies (macOS) · Dependencies (Windows) · Install Ninja · Get number of CPU cores
—
Coverage
.github/workflows/coverage.yml
push, demande de fusion
  • Code Coverage ubuntu-latest
    Checkout Repository · Dependencies · Get number of CPU cores · Cache Build · Prepare ccache · Configure
—
CUDA
.github/workflows/cuda.yml
push, demande de fusion
  • CUDA ubuntu-latest
    Checkout repository · Dependencies · cuda-toolkit · Get number of CPU cores · Cache Build · Prepare ccache
—
Docs
.github/workflows/docs.yml
lancement manuel, push
  • Docs ubuntu-latest
    Checkout repository · Set up Python · Requirements · Cache Build · Prepare Ccache · Copy release docs
GitHub Pages
PyPi Release
.github/workflows/pypi.yml
lancement manuel
  • build_wheels matrix
    actions/checkout · Build wheels · actions/upload-artifact
  • Build source distribution ubuntu-latest
    actions/checkout · Build sdist · actions/upload-artifact
  • Upload to PyPI ← build_wheels, build_sdist ubuntu-latest
    Download wheels · Download source distribution · pypa/gh-action-pypi-publish
PyPI
Python
.github/workflows/python.yml
push, demande de fusion
  • Build matrix
    Checkout Repository · Install Ccache (Linux) · Install Ccache (macOS) · Install Ccache (Windows) · Cache Build · Prepare Ccache
—

7.9. Déploiement

Mermaid Schéma de déploiement
flowchart LR
  repo[("Dépôt GitHub")]
  ci[["GitHub Actions<br/>8 workflows"]]
  image["Image Docker"]
  pub_GitHub_Pages[("GitHub Pages")]
  pub_PyPI[("PyPI")]
  repo -->|"push ou demande de fusion"| ci
  ci -->|"docker build"| image
  ci -->|"publie"| pub_GitHub_Pages
  ci -->|"publie"| pub_PyPI
UML Déploiement
Déploiement

Le nœud extérieur est l’endroit où le code s’exécute. Chaque image de base pointe vers ce qu’elle construit, les flèches pleines mènent aux bases de données et les pointillées aux services externes. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
node "Image Docker" as H {
  artifact "ipc-toolkit" as APP
}
artifact "FROM ubuntu:22.04" as IMG0
IMG0 ..> APP : construit
@enduml

Où il s’exécute

Publié vers

Images Docker de base

ubuntu:22.04

7.10. Supervision

Ce que le code consigne, mesure et expose pour savoir s’il fonctionne.

7.11. Sécurité

Chaîne d’approvisionnement

Variables d’environnement 4

La page reprend les noms sans leurs valeurs et souligne ceux qui ressemblent à des secrets.

ARCHFLAGS CMAKE_ARGS CMAKE_GENERATOR DEBUG

7.12. Tests automatisés

Fichiers de test
80
Fichiers source
324
Cas de test, environ
275
Tests unitaires
76
Tests performance
4

Couverture de code

Aucun rapport chiffré de couverture dans les sources analysées.

Où sont les tests

tests/src/tests/ccd 11 tests/src/tests/distance 10 python/tests 9 tests/src/tests 9 tests/src/tests/broad_phase 9 tests/src/tests/friction 7

Intégration continue

Build
ctest
UML Pipeline CI
Pipeline CI

Le workflow GitHub Actions principal suit ces étapes. Les tâches lancées en parallèle sont côte à côte. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
title Build
start
partition "Build" {
  :Checkout repository;
  :Dependencies (Linux);
  :Dependencies (macOS);
  :Dependencies (Windows);
  :Install Ninja;
  :Get number of CPU cores;
  :Cache Build;
  :Prepare ccache;
}
stop
@enduml

Rien trouvé pour: Services, Base de données, Intégrations externes.

8. Algorithme

8.1. Problème

Décider si un CollisionMesh aux positions de sommets données s’intersecte, ou si un déplacement proposé reste sans collision, pour qu’un simulateur avec contacts interroge la géométrie sans posséder toute la boucle temporelle.

8.2. Entrées

Un CollisionMesh plus les positions de sommets courantes (et éventuellement proposées) ; les stratégies CCD large et étroite sont des paramètres explicites avec valeurs par défaut.

8.3. Sorties

Réponses d’intersection ou de pas sans collision, plus des quantités de contact (distances, barrières, aides de friction) consommées par l’objectif de l’appelant — pas une résolution de scène complète.

8.4. Pseudocode (source)

given mesh M, positions x, optional next positions x'
if has_intersections(M, x): report contact candidates
if not is_step_collision_free(M, x, x'): reject or shorten step
else: assemble contact energies/derivatives for the caller’s solver
  1. 1. Construire ou accepter un maillage de collision

    La bibliothèque attend un CollisionMesh qui sépare la géométrie de l’état de simulation de l’appelant.

  2. 2. Candidats en phase large

    Les paires candidates sont découvertes avec une stratégie de phase large explicite avant les tests étroits coûteux.

  3. 3. CCD / intersection en phase étroite

    Les points d’entrée de ipc.hpp testent les intersections à une configuration ou si un déplacement reste sans collision.

  4. 4. Quantités de contact pour le solveur

    Les modules distance, barrière, friction et associés fournissent valeurs et dérivées ; la simulation externe conserve la gestion du temps.

Aucune complexité asymptotique n’est publiée dans les en-têtes inspectés de ce fork ; le coût dépend de la taille du maillage, de la phase large et des réglages CCD choisis par l’appelant.

Implémentation consultée

9. Types et structure des fichiers

140 types déclarés, dont 12 dans l’aperçu des relations de base.

Diagramme des types
classDiagram
direction TB
class ta4ad2d054a1a["CXXFunctionGenerator"] {
  __init__()
  signature()
  __call__()
}
class t0935cb7a441b["CXXGradientGenerator"] {
  __init__()
}
class t1aec9e647746["CXXJacobianGenerator"] {
  __init__()
}
class t6c43b7865a81["CXXHessianGenerator"] {
  __init__()
}
class t05fe515aed0d["Inertia"] {
  __init__()
  __call__()
  gradient()
  hessian()
}
class tcb5b8ab75455["PyBarrier"] {
  first_derivative()
  second_derivative()
  units()
}
class te947d03a9485["PyBroadPhase"] {
  name()
  build()
  clear()
  detect_vertex_vertex_candidates()
}
class ta8c42662e683["PyNarrowPhaseCCD"] {
  point_point_ccd()
  point_edge_ccd()
  point_triangle_ccd()
  edge_edge_ccd()
}
class tb0adabdf7fe2["PyNonlinearTrajectory"] {
  max_distance_from_linear()
}
class tc83b025ce434["PyIntervalNonlinearTrajectory"] {
  max_distance_from_linear()
}
class t9ee9c14a4b05["PairHash"] {
  <<struct>>
}
class t5a3d1613cb4b["SparseCanCollide"] {
  SparseCanCollide()
}
ta4ad2d054a1a <|-- t0935cb7a441b
ta4ad2d054a1a <|-- t1aec9e647746
t1aec9e647746 <|-- t6c43b7865a81
class b7bd3eedf5849["Barrier"] {
  <<unresolved_base>>
}
b7bd3eedf5849 <|-- tcb5b8ab75455
class b80b43ba1bca8["BroadPhase"] {
  <<unresolved_base>>
}
b80b43ba1bca8 <|-- te947d03a9485
class b1ced31ba20e0["NarrowPhaseCCD"] {
  <<unresolved_base>>
}
b1ced31ba20e0 <|-- ta8c42662e683
class b9fe354f68d01["NonlinearTrajectory"] {
  <<unresolved_base>>
}
b9fe354f68d01 <|-- tb0adabdf7fe2
class b28bdf016fc91["IntervalNonlinearTrajectory"] {
  <<unresolved_base>>
}
b28bdf016fc91 <|-- tc83b025ce434

Les bases non résolues restent identifiées; les signatures complètes ne sont pas reconstruites.

10. Référence

463 / 463 fichiers admissibles lus (646 dans l’arbre); 0 trop volumineux, 0 échec de lecture et 74 diagnostic de syntaxe.

Ce que couvre l’analyse

Les dossiers connus de dépendances et de compilation, les fichiers d’identifiants et les binaires sont exclus. La collecte couvre les README, les manifestes reconnus et les fichiers source pris en charge.

Les statistiques Linguist couvrent l’ensemble du dépôt et peuvent inclure d’autres langages.

12. Fichiers à lire 3

13. Glossaire

Dépôt

Les fichiers source, la configuration et l’historique versionné d’un projet.

README

Le document d’entrée du dépôt, qui présente généralement son rôle et son installation.

Dépendance

Une bibliothèque, un outil ou un service nécessaire à la compilation ou à l’exécution d’un composant.

Conteneur

Un environnement de processus isolé créé à partir d’une image. Les données persistantes nécessitent un stockage hors de son système de fichiers temporaire.

Port publié

Un port de l’hôte associé au port d’un service dans un conteneur. Sa publication peut rendre le service accessible hors du réseau des conteneurs.

Compilation

Les étapes qui transforment les sources et dépendances en programme exécutable ou en livrable distribuable.

Intégration continue

Des vérifications automatiques lors des changements de source, comme la compilation, les tests et l’analyse statique. Elles ne couvrent que ce qu’elles vérifient.

GPU

Un processeur conçu pour les calculs parallèles, dont le rendu graphique et de nombreuses opérations numériques.

Maillage

Une surface représentée par des sommets et des éléments reliés, souvent des triangles. Sa géométrie est distincte de son matériau ou de sa texture.

Détection continue des collisions

Une recherche de contact pendant le mouvement entre deux états, au lieu de tester seulement ses extrémités.

Fork

Un dépôt distinct dérivé d’un autre projet. Une modification du fork ne devient pas automatiquement une modification du projet amont.

14. Références

  1. antoinebou12. (2026, 5 novembre). ipc-toolkit. [Software repository] github.com.
  2. antoinebou12. (2026, 5 novembre). ipc-toolkit: README. [Repository documentation] github.com.
  3. antoinebou12. (2026, 5 novembre). src/ipc/ipc.hpp. [Source file] github.com.
  4. antoinebou12. (2026, 5 novembre). src/ipc/ipc.cpp. [Source file] github.com.
  5. antoinebou12. (2026, 5 novembre). CMakeLists.txt. [Source file] github.com.
  6. Boucher, A. (2026, 24 octobre). IPC Toolkit : collisions et friction dans une simulation. [Project article] antoineboucher.info.
  7. Boucher, A. (2026, 23 octobre). ipc-toolkit : Les requêtes de collision comme frontière de bibliothèque. [Project article] antoineboucher.info.

Les sources sans date de publication indiquent la date de leur dernière vérification, le 5 novembre 2026. Les liens des fichiers conservent la révision inspectée lorsqu’elle est disponible.

Article associé : IPC Toolkit : une bibliothèque de contacts pour les simulations.