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.
- Langages
- 5Répartition du code
- 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.
| Langage | % | Octets |
|---|---|---|
| C++ | 2 400 346 | |
| CMake | 75 800 | |
| Python | 53 463 | |
| Cuda | 9 561 | |
| Dockerfile | 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.
- 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
- Installer les liaisons avec pip install ipctk, ou ajouter la bibliothèque à un projet CMake.
- Créer un CollisionMesh à partir des sommets, arêtes et faces de la scène.
- Construire les NormalCollisions avec dhat = 1e-3 pour les positions actuelles.
- Ajouter l’énergie, le gradient et la hessienne de BarrierPotential au système de Newton du solveur.
- 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.
pip install ipctkpip install git+https://github.com/ipc-sim/ipc-toolkitpip install .python -c "import ipctk"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
4.2. Installation
python/README.md
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
4.4. Contributing (CONTRIBUTING.md)
docs/CONTRIBUTING.md
Documentation source
README.mdpython/README.mddocs/PYPI_README.mddocs/CONTRIBUTING.mddocs/source/developers/contributing.rstdocs/source/tutorials/getting_started.rst
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.
Simulation externe
Maillage et déplacement des sommets
- Depuis Simulation externe
- Vers Candidats de phase large
Candidats de phase large
Détection continue précise
- Depuis Candidats de phase large
- Vers Résultat de collision
Résultat de collision
- Depuis Détection continue précise
- Vers Simulation externe
Mermaid Diagramme interactif
Vue générale des composants et des échanges vérifiés dans le dépôt.

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
| Module | Couche | Fichiers | Types | Extensions |
|---|---|---|---|---|
ipc/smooth_contact | Source principale | 32 | 27 | .hpp .cpp |
ipc/collisions | Source principale | 26 | 15 | .hpp .cpp |
ipc/distance | Source principale | 24 | 0 | .cpp .hpp |
ipc/broad_phase | Source principale | 21 | 15 | .hpp .cpp |
ipc/candidates | Source principale | 18 | 9 | .cpp .hpp |
ipc/ccd | Source principale | 18 | 7 | .hpp .cpp |
ipc/utils | Source principale | 18 | 13 | .hpp .cpp |
python/collisions | Source principale | 17 | 0 | .cpp .hpp |
ipc/potentials | Source principale | 14 | 7 | .cpp .hpp |
python/distance | Source principale | 11 | 0 | .cpp .hpp |
python/broad_phase | Source principale | 10 | 1 | .cpp .hpp |
python/candidates | Source principale | 10 | 0 | .cpp .hpp |
python/ccd | Source principale | 10 | 3 | .cpp .hpp |
ipc/geometry | Domaine et règles métier | 8 | 0 | .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
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
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
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
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
namespace { }python/src/collision_mesh.cpp:7namespace { }src/ipc/broad_phase/lbvh.cpp:25namespace { }src/ipc/broad_phase/lbvh.cpp:104
Modules privés
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é | Nature | Premiers champs |
|---|---|---|
MortonCodeElement | Structure de données | morton_code, box_id, std, parent |
Boxes | Structure de données | std, SweepAndPrune |
ConstructionInfo | Structure de données | parent, std |
MeshDomain | Structure de données | Eigen, tbb |
PrimitiveDistType | Structure de données | PrimitiveA, Eigen |
ScalarBinaryOpTraits | Structure de données | ReturnType |
formatter | Structure de données | filib |
PairHash | Structure de données | std |
Afficher 4 entités de plus
PrimitiveDistType | Structure de données | PrimitiveA |
|---|---|---|
rebind | Structure de données | a_t |
IsADGrad | Structure de données | |
IsADHessian | Structure 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.
CollisionMeshSource principale, 36 méthodesbuild_from_full_mesh, init_adjacencies, init_area_jacobians, num_vertices, num_codim_vertices, num_codim_edgesMathDomaine et règles métier, 19 méthodessign, abs, sqr, cubic, cubic_spline, cubic_spline_gradCollisionStencilSource principale, 19 méthodesnum_vertices, dim, vertex_ids, vertices, dof, compute_distanceNormalCollisionsSource principale, 19 méthodesbuild, compute_minimum_distance, size, empty, clear, is_vertex_vertexLBVHSource principale, 18 méthodesname, clear, detect_vertex_vertex_candidates, detect_edge_vertex_candidates, detect_edge_edge_candidates, detect_face_vertex_candidatesBroadPhaseSource principale, 17 méthodesname, build, clear, detect_collision_candidates, detect_vertex_vertex_candidates, detect_edge_vertex_candidatesCandidatesSource principale, 15 méthodesbuild, size, empty, clear, is_step_collision_free, compute_collision_free_stepsizeHashGridSource principale, 14 méthodesname, clear, detect_vertex_vertex_candidates, detect_edge_vertex_candidates, detect_edge_edge_candidates, detect_face_vertex_candidatesSweepAndPruneSource principale, 14 méthodesname, build, clear, detect_vertex_vertex_candidates, detect_edge_vertex_candidates, detect_edge_edge_candidatesEdge3Source principale, 13 méthodesn_vertices, n_dofs, n_face_neighbors, potential, grad, hessian
7.7. Stack et dépendances
Dépendances externes
3 paquets déclarés (3 à l’exécution, 0 pour le développement) dans CMakeLists.txt, pyproject.toml.
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
| Workflow | Déclencheurs | Tâches | Publie vers |
|---|---|---|---|
clang-format Check.github/workflows/clang-format-check.yml | push, demande de fusion |
| — |
Clang-Tidy Check.github/workflows/clang-tidy-check.yml | push, demande de fusion |
| — |
Build.github/workflows/continuous.yml | push, demande de fusion |
| — |
Coverage.github/workflows/coverage.yml | push, demande de fusion |
| — |
CUDA.github/workflows/cuda.yml | push, demande de fusion |
| — |
Docs.github/workflows/docs.yml | lancement manuel, push |
| GitHub Pages |
PyPi Release.github/workflows/pypi.yml | lancement manuel |
| PyPI |
Python.github/workflows/python.yml | push, demande de fusion |
| — |
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
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
- Image Docker
- Build natif (Make)
- Build CMake ×57
- Conteneur de développement ×2
- Workflow de déploiement CI ×5
Publié vers
Images Docker de base
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.
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
UML 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. 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. 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. 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. 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.
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
- antoinebou12. (2026, 5 novembre). ipc-toolkit. [Software repository] github.com.
- antoinebou12. (2026, 5 novembre). ipc-toolkit: README. [Repository documentation] github.com.
- antoinebou12. (2026, 5 novembre). src/ipc/ipc.hpp. [Source file] github.com.
- antoinebou12. (2026, 5 novembre). src/ipc/ipc.cpp. [Source file] github.com.
- antoinebou12. (2026, 5 novembre). CMakeLists.txt. [Source file] github.com.
- Boucher, A. (2026, 24 octobre). IPC Toolkit : collisions et friction dans une simulation. [Project article] antoineboucher.info.
- 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.
Fiche projet
Article associé : IPC Toolkit : une bibliothèque de contacts pour les simulations.