Découpage adaptatif pour l'impression 3D à diamètre variable : algorithme, résultats et compromis
Par Jacob Cossette
Un projet spécial réalisé pour Aptus Tech, une startup incubée au Centech, afin de résoudre un problème de découpage qu'aucun logiciel existant ne pouvait gérer : préparer des modèles 3D pour une tête d'impression à diamètre de buse variable.
Le problème
Aptus Tech développait une imprimante 3D dotée d'une tête d'impression à diamètre variable, capable de changer le diamètre de la buse en cours d'impression pour arbitrer entre vitesse et précision au sein d'un même objet. Le volet matériel de cette idée n'est que la moitié du problème. Tous les logiciels de découpage (slicers) du marché supposent un diamètre de buse fixe, aucun ne peut donc générer un chemin d'outil qui varie localement en résolution, imprimant des couches grossières là où la précision importe peu et des couches fines exactement là où elle compte. C'est cet écart que le projet visait à combler : un algorithme de découpage preuve de concept pour l'impression à diamètre variable, ainsi qu'un prototype fonctionnel pour mesurer si l'idée en vaut réellement la peine.
L'idée technique centrale : la cusp height comme signal d'erreur
L'algorithme doit pouvoir décider, pour n'importe quelle région d'un modèle, si l'épaisseur de couche actuelle est suffisante ou doit être affinée. La métrique utilisée pour cela est la cusp height, un concept standard en recherche sur le découpage adaptatif (Mani et al., 1998) : la déviation entre la surface d'une couche imprimée et la surface idéale du modèle 3D, donnée par
h = r · (1 − cos(θ/2))
où r est le rayon local de courbure de la surface et θ l'angle entre deux points adjacents du contour. Une cusp height élevée signifie que la surface courbe rapidement par rapport à l'épaisseur de couche actuelle, ce qui correspond exactement aux endroits où apparaissent des ondulations visibles et des imprécisions.
La cusp height, visualisée : l'écart entre une couche imprimée plate et la surface inclinée du modèle (à gauche) est l'erreur que l'algorithme mesure, réduite à un simple triangle (à droite) pour calculer h.
Le pipeline construit autour de cette métrique fonctionne par étapes : importer le fichier STL (un ensemble de triangles, chacun défini par trois sommets et une normale), calculer l'intersection entre chaque triangle et un plan de coupe horizontal par interpolation linéaire pour construire le contour polygonal de cette couche, puis évaluer la cusp height le long de ce contour afin de signaler les régions où l'erreur dépasse une tolérance définie. Dans les régions signalées, l'algorithme insère des sous-périmètres, essentiellement des couches internes plus fines imbriquées dans la couche grossière, dimensionnées pour que leur épaisseur combinée corresponde toujours à un multiple propre du diamètre de buse de base (une cible de 0,3 mm peut ainsi être atteinte par deux sous-couches de 0,1 mm sans désalignement entre les couches).
Là où l'erreur est signalée, l'algorithme imbrique des sous-périmètres plus fins à l'intérieur de la couche grossière plutôt que d'affiner l'objet entier — la résolution augmente localement, pas globalement.
Choisir ce qu'il faut construire plutôt que réutiliser
Trois approches ont été évaluées avant d'arrêter l'architecture finale, et il vaut la peine d'expliquer pourquoi chacune des options précédentes a été écartée :
OpenGL, pour un visionneur STL et un pipeline de rendu sur mesure. Cette approche offrait un contrôle complet, mais s'est heurtée à une incompatibilité matérielle (une erreur de pilote GLFW/WGL sur le GPU disponible) et, plus important encore, la construction d'un visionneur STL performant à partir de zéro (gestion de gros fichiers, rotation, translation) s'est avérée un chantier bien plus vaste que l'algorithme de découpage lui-même. Abandonnée pour des raisons d'ampleur du projet.
Assimp, une librairie établie pour l'importation de formats 3D, avec des outils géométriques utiles (triangulation, extraction de sommets, gestion des normales). Elle réglait bien le problème d'importation, mais nécessitait quand même de construire toute la logique de génération de chemin d'outil à partir de rien. Conservée en tête pour un futur slicer complet, mais trop incomplète pour l'échéancier de ce projet.
Slic3r, un slicer open source mature avec une génération de chemin d'outil déjà intégrée. L'utiliser aurait signifié travailler à l'intérieur d'une architecture offrant peu de contrôle sur les composantes internes, exactement la couche que l'algorithme devait modifier.
L'approche finalement retenue : partir d'un slicer Python open source beaucoup plus simple et déjà fonctionnel (développé à l'origine par Aaron Schaer et Michelle Ross) et étendre son objet Slice avec de nouveaux attributs de sous-périmètre, plutôt que de construire un slicer à partir de zéro. Cette décision (réutiliser une base de code petite et compréhensible et n'y ajouter que la seule capacité nécessaire) est ce qui a permis d'obtenir des résultats mesurables dans l'échéancier du projet.
Méthodologie de benchmark : isoler l'effet de l'algorithme, pas de l'imprimante
Pour savoir si le découpage adaptatif en valait réellement la peine, la comparaison devait contrôler tout, sauf la stratégie de découpage. Trois géométries (un cube, une sphère et un anneau, choisies pour couvrir des surfaces planes, une courbure continue et une courbure combinée convexe/concave) ont été découpées de trois façons : diamètre constant de 0,5 mm, diamètre constant de 1,0 mm et algorithme adaptatif. Tous les autres paramètres d'impression ont été fixés pour chaque essai : remplissage à 50 %, coût de filament de 0,08 $/gramme, vitesse d'extrusion de 15 mm/s, vitesse de déplacement de 45 mm/s. Pour chacune des neuf impressions résultantes, cinq métriques ont été relevées : temps d'impression, nombre de couches, masse de l'objet, longueur de filament utilisée et coût d'impression.
Une des trois géométries de test : le modèle STL source de la sphère (en haut) et le chemin d'outil généré par l'algorithme adaptatif (en bas) — une courbure continue partout est exactement le cas où la résolution variable a le plus à offrir.
Résultats : un compromis vitesse/précision quantifié
L'algorithme adaptatif s'est systématiquement situé entre les deux références à diamètre constant, ce qui est le résultat attendu, mais l'intérêt réside dans l'ampleur de l'écart. En moyenne sur les trois géométries testées, passer d'un diamètre constant de 1,0 mm à l'algorithme pleinement adaptatif n'a augmenté le temps d'impression que de 18,54 %, tout en atteignant la précision de surface d'une impression à diamètre constant de 0,5 mm, laquelle exige elle-même une augmentation de 147,7 % du temps d'impression par rapport à la référence de 1,0 mm. Autrement dit, l'approche adaptative capture l'essentiel du gain de précision pour environ un huitième du coût en temps. Elle a aussi utilisé le même nombre de couches de base que l'impression grossière à 1,0 mm (20 couches au lieu de 40 pour le cube, 10 au lieu de 20 pour l'anneau), en affinant la résolution seulement dans les régions signalées plutôt qu'en doublant chaque couche sur l'ensemble de l'objet.
L'écart entre les géométries est également révélateur : le coût en temps de la logique de sous-périmètre plus fine augmente avec la complexité de la courbure, du cube (surfaces essentiellement planes, gain le plus faible de la résolution adaptative) à l'anneau (courbure continue partout, gain relatif le plus important). C'est une indication utile de l'endroit où cette technique importe le plus en pratique : les géométries fortement courbées ou organiques, plutôt que les formes prismatiques simples.
Ce qui ne fonctionne pas encore, et pourquoi il vaut la peine de le publier
La preuve de concept a atteint son objectif principal, quantifier si le découpage à diamètre variable vaut la peine d'être développé, mais trois limitations concrètes demeurent non résolues, et chacune a une piste de solution claire :
Chevauchement périmètre/remplissage. Selon la référence de périmètre utilisée par l'algorithme de remplissage, les impressions laissent soit un espace entre la paroi extérieure et le remplissage interne (affaiblissant la structure de la pièce), soit le remplissage chevauche le sous-périmètre (risquant des erreurs d'impression). La piste de solution probable consiste à définir chaque périmètre et sous-périmètre avec sa propre épaisseur explicite plutôt que de les traiter comme des lignes de référence sans épaisseur.
Un mode de défaillance de la référence de périmètre actuelle : un espace s'ouvre entre la paroi extérieure et le remplissage interne (surligné), affaiblissant la pièce. Le rapport documente aussi la défaillance inverse — le remplissage chevauchant le sous-périmètre.
Temps de traitement. La génération du code G pour le cube a pris 32 secondes sur un Intel Core i7-6600U; la sphère, 103 secondes; l'anneau, 1 457 secondes. Cette courbe (environ 45 fois plus lente pour une forme modérément plus complexe) relève davantage d'une limite d'implémentation Python que d'une limite algorithmique, et le rapport recommande lui-même une réécriture du chemin critique en C++.
Optimisation des déplacements. L'implémentation actuelle ne minimise pas les déplacements entre segments, produisant des mouvements de va-et-vient visiblement redondants sur les impressions test de la sphère et du cube. Cela n'affecte pas la précision, mais affecte le temps d'impression réel et l'usure, et il s'agit d'une catégorie de problème connue et abordable (optimisation de chemin de déplacement) qui n'était simplement pas encore dans le périmètre du projet.
Ce qu'il faut en retenir
Évaluer explicitement la décision de construire ou de réutiliser, et documenter pourquoi chaque option écartée l'a été. Ce registre est ce qui a permis à ce projet d'atterrir sur une solution de la bonne taille plutôt que de la redécouvrir par essais et erreurs. Concevoir les benchmarks comme des comparaisons contrôlées, pas de simples démonstrations : fixer toutes les variables sauf celle testée est ce qui a transformé « l'algorithme adaptatif semble meilleur » en un chiffre précis et défendable (18,54 % contre 147,7 %). Et présenter les limitations avec la même rigueur que les résultats. Une preuve de concept qui indique exactement ce qui ne fonctionne pas encore, et pourquoi, est plus utile pour le prochain ingénieur (ou investisseur, ou client) qu'une preuve de concept qui ne montre que les réussites.
Télécharger le rapport complet (PDF) : revue technique complète, dérivation de la cusp height, tableaux de benchmark, diagrammes des limitations et instructions d'installation du prototype de découpage.