Brush Codebase Workflow: A Step-by-Step Guide to Contributing

The typical Brush codebase workflow involves setting up a Rust 1.88+ environment, modifying the appropriate workspace crate, validating changes with cargo test --all, and submitting a pull request after passing strict linting and formatting checks.

The Brush repository is a multi-crate, multi-platform Rust workspace maintained by ArthurBrussee that builds both native binaries and WebAssembly targets for 3D Gaussian splatting. Following the correct Brush codebase workflow ensures your contributions to the training pipeline, rendering backend, or UI components compile cleanly across CLI, desktop, Android, and browser platforms.

Workspace Setup and Prerequisites

Before modifying any code, clone the repository and verify you have Rust ≥ 1.88 and the Node toolchain installed for the Web UI components. The top-level Cargo.toml defines the workspace members, shared dependencies, and patch overrides for wgpu and cubecl that affect all crates.

The workspace is organized into two primary categories:

• crates/ – Core libraries including brush-train (training pipeline), brush-render (GPU rasterization), and brush-process (message passing)
• apps/ – Executable targets including brush-cli (headless training), brush-app (desktop UI), and brush-js (WebAssembly demo)

Selecting Your Target Crate

Identify which component needs modification before creating your feature branch. Each crate is self-contained but shares dependencies like glam, burn, and wgpu as defined in the workspace Cargo.toml.

Common modification targets include:

• crates/brush-train – Dataset loading and training loop logic in src/lib.rs
• crates/brush-render – GPU rendering pipeline using wgpu
• apps/brush-cli – CLI argument parsing and headless execution in src/lib.rs
• apps/brush-app – Desktop UI implementation
• apps/brush-js – WebAssembly bindings and browser demo

Create an isolated feature branch for your work:

git checkout -b feat/my-change

Implementation and Local Verification

Edit the source files within your chosen crate. For example, the CLI argument parsing lives in apps/brush-cli/src/lib.rs, while the training loop resides in crates/brush-train/src/lib.rs. Keeping changes localized ensures the workspace compiles cleanly for all targets.

Verify your changes locally using platform-specific commands:

Native CLI testing:

cargo run --release -p brush-cli -- \
    --source path/to/colmap \
    --with-viewer \
    --train-config epochs=100

Web development server:

cd apps/brush-js/web
npm install
npm run dev  # Launches localhost:5173 via Vite (see vite.config.ts)

Android native library:

cargo ndk -t arm64-v8a -o crates/brush-app/app/src/main/jniLibs/ build --release

Testing and Code Quality

Run the comprehensive test suite to prevent regressions:

cargo test --all

The repository includes crates/brush-bench-test for performance validation and unit tests in each crate's tests/ directory. Add or adjust tests for new functionality to guarantee regression-free evolution.

Enforce code quality using the workspace-defined lint rules:

cargo fmt
cargo clippy --workspace -- -D warnings

The [workspace.lints] table in Cargo.toml defines strict rules that apply across all crates, ensuring consistent code style.

Update documentation by modifying README files (such as crates/brush-train/README.md) or inline documentation to explain architectural changes for future contributors.

Submitting Your Contribution

Commit your changes with a descriptive message and push to your remote branch:

git add .
git commit -m "feat: descriptive change summary"
git push origin feat/my-change

Open a Pull Request targeting the main branch via the GitHub UI. Reviewers will examine the modified workspace configuration, source files, and CI results. The PR template requires describing the architectural impact on cross-platform targets.

Once CI passes and approvals are obtained, merge the commit. The version field in Cargo.toml indicates the release cycle for your merged contribution.

Summary

• Brush uses a multi-crate workspace defined in Cargo.toml with patches for wgpu and cubecl
• Target the correct crate: crates/brush-train for training logic, apps/brush-cli for command-line features, or apps/brush-js for web support
• Validate changes using cargo test --all and platform-specific builds (native, WASM, Android)
• Follow [workspace.lints] rules by running cargo fmt and cargo clippy before submission
• Reference specific files like apps/brush-cli/src/lib.rs and crates/brush-process/src/message.rs when modifying UI loops or inter-process communication

Frequently Asked Questions

What Rust version is required to build Brush?

You need Rust ≥ 1.88 to compile the workspace. The Cargo.toml specifies edition 2021 with specific patch overrides for graphics dependencies that require recent compiler features.

How do I test WebAssembly-specific changes?

Navigate to apps/brush-js/web and run npm run dev to start the Vite development server. The configuration in apps/brush-js/web/vite.config.ts handles WASM bundling. Ensure your changes compile with wasm32-unknown-unknown target before testing in the browser.

Which crate contains the training loop implementation?

The core training logic resides in crates/brush-train/src/lib.rs, which handles dataset loading, optimization steps, and integration with the brush-process messaging system used by both the CLI and desktop app.

How are consistent code standards enforced across the workspace?

The root Cargo.toml defines a [workspace.lints] section that applies to all member crates. Running cargo clippy --workspace -- -D warnings treats all lint violations as errors, preventing non-compliant code from entering the main branch.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}