The Problem

This repository is a collection of 7 self-contained projects without a unifying architecture, and no CI/CD pipeline gates commits. Across 20,185 files and 7542 tests, changes merge without automated build or test execution, and dependency declarations in pyproject.toml lack a lockfile, making builds non-reproducible and ship artifacts potentially different from tested ones.

What This Does

The repository spans 7 distinct projects: source (7110 files, 255 C/C++ code), scripts (826 files, 803 Python), extern (1660 files, 445 C/C++/other), intern (1529 files, 322 code + 2 data), tools (116 files, 96 code), build_files (336 files, 10 CMake), and release (1292 files, 9 code + 3 data). The substantial ones are source (core 3D pipeline—modeling, rigging, simulation, rendering), scripts (Python bpy API and add-on development), and extern (third-party libraries bundled under CMake). Entry points include extern/quadriflow/src/main.cpp, scripts/modules/_bpy_internal/addons/cli.py, and scripts/modules/_bpy_internal/assets/remote_library_listing/cli.py. source/ implements the C++ core; scripts/ exposes the Python automation layer via bpy; extern/ manages external deps like Bullet and Audaspace through build_files/build_environment/CMakeLists.txt.

How It Is Wired

Execution starts at the compiled binary built from CMakeLists.txt roots, which orchestrates source/ C++ code and links extern/ libraries. The scripts/modules/_bpy_internal/ Python module exposes the bpy API; cli.py files handle command-line add-on operations. extern/quadriflow/src/main.cpp is a standalone compute pipeline entry. The Python pyproject.toml declares 9 dependencies including sphinx==8.2.3. No centralized call graph is mapped by this analysis; the source/ to scripts/ boundary is mediated by the bpy C/Python bridge, and changes to extern/ CMake configs affect the full build. The widest blast radius is through source/CMakeLists.txt and pyproject.toml, each touched by every build or dependency update.

How To Use It

Setup: Clone with GIT_LFS_SKIP_SMUDGE=1 as the README warns (https://github.com/moses-y/blender). Build: cd blender && cmake -S source -B build && cmake --build build (inferred from CMakeLists.txt presence). Python API: pip install -r doc/python_api/requirements.conf or use the pyproject.toml manifest; sphinx==8.2.3 is pinned but current is 9.1.0. Running it: blender --background --python scripts/modules/_bpy_internal/addons/cli.py or invoke the built binary. No Dockerfile or committed Makefile targets beyond CMake are present.

Real-World Use

A technical artist writes a Python script using bpy.ops.mesh.primitive_cube_add() from scripts/modules/_bpy_internal/ to batch-generate assets. The script runs via blender --python script.py, touching the bpy bridge into source/ C++ core for mesh data. Alternatively, a compile job targeting extern/quadriflow/src/main.cpp paths can produce headless physics previews without the full UI build.

Code Health & Issues

[MEASURED ANALYSIS] This repository is a collection of 7 self-contained projects, not one codebase.

  • scripts - 826 files, 803 code files
  • extern - 1660 files, 445 code files
  • intern - 1529 files, 322 code files, 2 data files
  • source - 7110 files, 255 code files
  • tools - 116 files, 96 code files
  • build_files - 336 files, 10 code files
  • release - 1292 files, 9 code files, 3 data files

Repository hygiene: tests present: yes | CI: no | Dockerfile: no | licence: yes | lockfile: no | committed secrets: none found.

[Code Health Audit]

  • HIGH - Commit a lockfile beside the manifest - pyproject.toml: manifest with no lockfile in scope; unlocked range means the artifact tested and shipped can contain different transitive code.
  • HIGH - Add a workflow that builds and tests this repository: 2262+ source files, no CI configuration; every change merges with nobody having run the build.
  • MEDIUM - Enable Dependabot or Renovate: 3 manifest(s), no update bot configured; published advisories sit unpatched until manual audit.

The Bottom Line

This is a massive, well-organized 3D suite split across 7 independently versioned projects with solid C/C++ and Python foundations, but it ships without CI, lockfiles, or automated dependency updates, making every merge a manual build risk. Teams needing stable, reproducible pipelines should add a CI workflow and lockfile immediately; others can use it for source inspection or custom Python pipeline building with the bpy API, provided they manage builds and deps manually.