Principe de fonctionnement

Le projet ldraw‑mecha (version v0.5.0) accepte un fichier .mpd LDraw comme entrée et délivre un script Python capable d’animer le modèle dans Blender. Le processus repose sur un agent d’intelligence artificielle – par exemple Claude Sonnet 5.5 ou Claude Opus 5.5 – qui analyse le code source du modèle, infère les mécanismes (axes, engrenages, pistons) et élabore un plan d’interaction entre les composants mécaniques. Ce plan est ensuite traduit en code Python qui crée les rigs nécessaires dans Blender et orchestre les mouvements.

git clone https://github.com/anteloc/ldraw-mecha.git
cd ldraw-mecha
./setup-macos.sh    # ou ./setup-linux.sh, ./setup-win-wsl.sh

Architecture du pipeline

Le pipeline se compose de quatre étapes distinctes. Premièrement, le parser LDraw lit le fichier .mpd et extrait la hiérarchie des pièces. Deuxièmement, l’agent IA reçoit cette description structurée et applique un raisonnement de type « reverse‑engineering » pour identifier les joints mobiles, en s’appuyant sur les métadonnées du répertoire data/ldraw. Troisièmement, le plan d’animation – séquence de rotations, translations et contraintes – est sérialisé sous forme de script Python compatible avec l’API de Blender 3.x. Enfin, le script est exécuté par le binaire Blender indiqué par la variable d’environnement BLENDER_BIN, qui génère les rigs et calcule les keyframes.

Le projet isole toutes les dépendances (Blender, LeoCAD, bases SQLite) dans le répertoire du dépôt, évitant ainsi toute contamination du système hôte. Les chemins d’accès sont injectés via des variables d’environnement définies lors du script d’installation :

# >>> ldraw-mecha (from setup-macos.sh) >>>
export LDRAW_DIR="/Users/me/ldraw-mecha/data/ldraw"
export BLENDER_BIN="/Users/me/ldraw-mecha/bin/Blender.app/Contents/MacOS/Blender"
export LEOCAD="/Users/me/ldraw-mecha/bin/LeoCAD.app/Contents/MacOS/LeoCAD"
# <<< ldraw-mecha <<<

Analyse des limites et perspectives

Le système dépend fortement de la capacité du modèle d’IA à interpréter correctement la géométrie LDraw. Dans les démonstrations, le modèle 42043-1_Flatbed‑Trailer.mpd a été jugé trop volumineux ; l’agent a donc limité l’animation au seul bras de grue, illustrant une contrainte de complexité algorithmique. De même, le modèle 3625-1.mpd a nécessité une animation « in‑place » pour éviter le déplacement du fuselage, ce qui montre que le planificateur ne gère pas automatiquement les déplacements globaux du modèle.

Sur le plan technique, l’exigence d’une version Python 3.12+ et d’un binaire Blender local impose une barrière d’entrée pour les utilisateurs dont l’environnement ne supporte pas ces versions. Le processus d’ajout manuel des variables d’environnement dans .bashrc ou .zshrc peut entraîner des erreurs de configuration, notamment si plusieurs projets utilisent des chemins conflictuels. Enfin, le recours à un service externe (Claude) implique une dépendance réseau et potentiellement des coûts d’API, bien que le projet propose une option « Jev semantic search » via une clé API facultative.

Malgré ces limites, l’approche démontre la faisabilité d’une chaîne automatisée de génération d’animation à partir de modèles de construction physique. Les futures itérations pourraient intégrer un moteur de simulation physique pour valider les contraintes mécaniques avant la génération du script, ou proposer un mode hors‑ligne en embarquant un modèle de langage local.