STL vers GLB
Ce script Python convertit un fichier STL en un fichier GLB. Il utilise la bibliothèque trimesh pour lire et exporter les fichiers.
Ce script prend en charge le traitement par lots, il conserve le nom de fichier et la structure de répertoire d’origine.
Installation
Python 3 est requis pour exécuter ce script.
Il est recommandé d’utiliser un environnement virtuel pour installer les bibliothèques requises.
python -m venv venv
source venv/bin/activate
Vous pouvez installer les bibliothèques requises avec la commande suivante:
pip install -r requirements.txt
Usage
Pour convertir un fichier spécifique, vous pouvez lancer le script avec la commande suivante:
python ./stl2glb.py -i ./input_path/file.stl -o ./output_path/
Pour traiter plusieurs fichiers à la fois, vous pouvez lancer le script avec la commande suivante:
python ./stl2glb.py -i ./input_path/ -o ./output_path/
Arguments
-iou--input: Chemin du fichier ou du répertoire d’entrée.-oou--output: Chemin du répertoire de sortie.--log-level(optionnel): Niveau de log pour le script. La valeur par défaut estWARNING. Les valeurs possibles sontDEBUG,INFO,WARNING,ERROR,CRITICAL.-tou--threads(optionnel): Nombre de processus à utiliser. La valeur par défaut est 0 (mode automatique).
Avertissement
Performance
Ces tests ont été réalisés par curiosité pour explorer le comportement de différentes façons de gérer le parallélisme en Python. Les premiers tests utilisent Thread de concurrent.futures pour obtenir du parallélisme, tandis que les seconds utilisent Process.
Ordinateur
- CPU: Intel(R) Core(TM) i7-10875H (8c-16t) CPU @ 2.30GHz
- RAM: 2x8GB DDR4-3200
- OS: Ubuntu 24.04.1 LTS (6.8.0-52-generic)
- Python: 3.12.3
Bibliothèques:
- numpy: 2.2.2
- trimesh: 4.6.1
Mesures
Les tests ont été effectués avec 10001, 1001 et 101 fichiers. Le modèle utilisé est RPI_3bplus_enclosure_upper_2.0.STL de mon projet de boitier Raspberry PI 1-3, il contient 6 572 triangles et pèse 321 ko.
Le temps d’exécution est mesuré en utilisant la commande time en zsh.
Les données brutes sont disponibles ici
Nous pouvons voir que pour ce script, utiliser des processus est plus efficace que d’utiliser des threads. Évidemment, plus il y a de fichiers, plus le parallélisme est utile. Pour une petite charge de travail (101 fichiers), la différence est négligeable. Mais pour une grande charge de travail (10001 fichiers), la différence est significative.
Pour les threads, le nombre optimal est autour de 8 threads, en en utilisant plus la performance diminue. Cela peut être dû au GIL qui limite les performances des threads.
Pour les processus, le nombre optimal est autour de 16 processus. Cela peut être dû au nombre de cœurs disponibles sur la machine. La différence entre 16 et 8 est négligeable, cela peut être dû aux limites d’E/S mais aussi au Turbo Boost. Car plus de cœurs sont utilisés, plus la fréquence de chaque cœur est basse. Pour une charge de travail importante (10001 fichiers), nous pouvons voir que l’utilisation de 32 processus est un peu plus rapide que l’utilisation de 16 processus. Cela peut être dû à la concurrence pour le temps CPU entre les autres processus s’exécutant sur la machine.
Conclusion
J’ai écrit ce script pour convertir mes fichiers STL en fichiers GLB pour mon site web. La charge de travail typique est d’environ 100 fichiers à la fois lorsque je mets à jour mon site web. Cela a pris environ 1 seconde, donc le parallélisme n’est pas vraiment utile. Mais comme nous pouvons le voir, les processus sont toujours plus rapides que les threads, même pour une petite charge de travail. C’est pourquoi je garde le parallélisme avec les processus comme option dans le script.
Par défaut, le script essaiera d’utiliser un nombre optimal de processus en fonction du nombre de cœurs disponibles sur la machine. Mais vous pouvez toujours spécifier le nombre de processus à utiliser.