gs playground

The Problem Robotics researchers need a simulator that can generate photorealistic visual observations at the scale required for modern vision‑based reinforcement learning. Existing pipelines either sacrifice visual fidelity or run far too slowly for large‑batch training, creating a bottleneck when moving from simulation to real‑world deployment.

What This Does gs_playground delivers a lightweight preview of the full system described in the RSS 2026 paper. It couples a parallel robot physics engine with a batched 3D‑Gaussian‑Splatting (3DGS) renderer, producing RGB/depth frames at up to 10⁴ FPS for 640 × 480 images. The repository contains:

• Core Python modules (8 files) under demo/navigation/utils/ that implement the policy, controller, robot abstraction and a small navigation demo.
• A benchmark script benchmark/scripts/prune_gaussians.py that illustrates how to trim 3DGS assets for memory‑efficient rendering.
• A collection of pre‑built 3DGS assets (≈2 k files) used by the demos and benchmarks.

Key entry points:

How It Is Wired

Execution flow – The benchmark starts at main → drain_capture_tasks (creates capture_dir.mkdir). The demo starts with configure_torch_cuda_arch_list → set_asset_root → class Replay __init__ → add → report, ultimately calling VideoWriter to persist video.

Call‑graph hot spots – resolve_demo_path is invoked from four places, making it the most widely referenced utility. Functions step, get_observation, and apply_action each appear in three distinct call sites, forming the core simulation loop (policy → observation → action → physics step).

External impact – Only two distinct filesystem writes are observed: the benchmark’s prune_file writes a trimmed .ply, and the demo’s VideoWriter creates a video file. No network or database calls are present.

Complexity – Three files (demo/live_demo/replay.py, demo/navigation/nav_collect_common.py, demo/navigation/robot_locomotion.py) contain nesting depths of six levels, making the control flow harder to follow and increasing the risk of bugs when extending the logic.

How To Use It

# Clone the repo (exact URL required by the brief)
git clone https://github.com/moses-y/gs_playground
cd gs_playground

# Install dependencies with uv (the README’s recommended tool)
uv sync        # reads pyproject.toml, creates a virtualenv and installs packages

# Run the pruning benchmark (example)
python -m benchmark.scripts.prune_gaussians \
    --input-dir benchmark/assets/franka_emika_panda_robotiq/3dgs \
    --output-dir benchmark/assets/pruned

# Launch the live‑replay demo (requires a CUDA‑capable GPU)
python -m demo.live_demo.replay \
    --scene demo/live_demo/assets/models/robots/manipulation/franka_emika_panda_robotiq/3dgs

The --input-dir/--output-dir flags are inferred from the script’s argparse definitions; if they are missing, the script falls back to the hard‑coded asset paths under benchmark/assets/ and demo/live_demo/assets/.

Real‑World Use A research team can integrate the policy module (demo/navigation/utils/policy.py) into an existing RL training loop. The loop calls step → get_observation → compute_action → apply_action. By swapping the policy class with a learned network, the same high‑throughput visual pipeline can be used for curriculum training without changing the rendering backend.

Code Health & Issues

Measured findings

• HIGH – No CI/CD workflow. 8 source files, no .github/workflows/ or other CI config.
• MEDIUM – No dependency lockfile; only pyproject.toml is present, making reproducible builds difficult.
• MEDIUM – Large binary assets (e.g., benchmark/assets/.../background.ply ≈ 14 MB) are stored directly in the repo, inflating clone size.

Additional observations

• Tests: a single test file exists, but test coverage is minimal.
• License: LICENSE present, but no NOTICE or additional compliance docs.
• No Dockerfile, so containerised builds must be added manually.

The Bottom Line gs_playground provides a functional, high‑throughput visual simulator core with clear entry points and a modest Python codebase, making it approachable for robotics research. However, the lack of CI, lockfile, and proper handling of large assets hampers reproducibility and scalability for production use. Teams that need rapid prototyping and are comfortable managing their own CI pipelines will find it useful; larger engineering groups should first address the health issues before adopting it at scale.