Github

This is a simple Python script that converts an STL file to a GLB file. It uses trimesh library to read and export the files.

This script support batch processing, it keeps the original file name and directory structure.

Installation

You need to have Python 3 installed in your system.

Its recommended to use a virtual environment to install the required libraries.

python -m venv venv
source venv/bin/activate

You can install the required libraries by running:

pip install -r requirements.txt

Usage

For converting a single file, you can run the script with the following command:

python ./stl2glb.py -i ./input_path/file.stl -o ./output_path/

For batch processing, you can run the script with the following command:

python ./stl2glb.py -i ./input_path/ -o ./output_path/

Arguments

  • -i or --input: Path to the input file or directory.
  • -o or --output: Path to the output directory.
  • --log-level (optional): Log level for the script. Default is WARNING. Possible values are DEBUG, INFO, WARNING, ERROR, CRITICAL.
  • -t or --threads (optional): Number of process to use. Default is 0 (auto mode).

Caution

This script will overwrite the output files if they already exist.

Performance

These tests were done out of curiosity to explore the behavior of different ways to handle parallelism in Python. The first tests use Thread from concurrent.futures to achieve parallelism, while the second use Process.

Machine

  • 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

Libraries:

  • numpy: 2.2.2
  • trimesh: 4.6.1

Measurements

The tests were done using 10001, 1001 and 101 files. Model used is RPI_3bplus_enclosure_upper_2.0.STL from my Raspberry PI 1-3 Enclosure project, it contains 6,572 triangles and takes 321 kB.

The time is measured using the time command in zsh.

Raw data are available here

We can see that for this script, using processes is more efficient than using threads. Obviously the more files, the more useful parallelism is. For small workload (101 files), the difference is negligible. But for large workload (10001 files), the difference is significant.

Thread Process comparison for 101 files Thread Process comparison for 10001 files

For threads, the sweet spot is around 8 threads, when using more performance decrease. It can be due to GIL that limit the performance of threads.

For processes, the sweet spot is around 16 processes. It can be due to the number of cores availables on the machine. The difference between 16 and 8 is negligible, it can be due to I/O bounds but also the Turbo Boost. Because the more cores are used, the lower the frequency of each core. For large workload (10001 files) we can see that using 32 processes is a bit faster than using 16 processes. It can be due to the competition for cpu time between other processes running on the machine.

Time decrease (lower is better)

Conclusion

I wrote this script to convert my STL files to GLB files for my website. The typical workload is around 100 files at a time when I update my website. It took around 1 second so parallelism is not really useful. But as we can see process are always faster than thread even for small workload. So I keep the parallelism with process as an option in the script.

By default, the script will try to use an optimal number of processes based on the number of cores available on the machine. But you can always specify the number of processes to use.

Chart for process amount selection in automatic mode
flowchart LR A[Start] --> B{"len(input_files) < MIN_CHUNK_SIZE"} B -->|"True"| C[Single Process] B -->|"False"| D["query_process = len(input_files) // MIN_CHUNK_SIZE"] D --> E{"query_process < available_core"} E -->|"True"| F["query_process"] E -->|"False"| G["available_core"]