---

name: siggraph-reproducibility description: Use when building the reproducibility story for a SIGGRAPH / TOG paper, covering deterministic result regeneration, scene/mesh/weight provenance, hardware and timing disclosure, floating-point and GPU non-determinism, and a code/data release that a reader or a Graphics Replicability Stamp volunteer can actually run.

SIGGRAPH Reproducibility

In computer graphics, reproducibility means a reader can regenerate your figures and timings, not merely re-derive your equations. SIGGRAPH's culture rewards this heavily — the community runs its own replicability stamps (see siggraph-artifact-evaluation) — but the review itself is decided on the paper and its supplemental video, so reproducibility is something you build into the work from the start, not bolt on at camera-ready. Anchor policy to resources/official-source-map.md.

Reproducibility here is result-reproducibility

A graphics result is an image, a mesh, a frame sequence, or a timing on specific hardware. Each class has its own failure mode:

• Rendered images depend on scene assets, sampler seeds, and the renderer's floating-point path — two "correct" runs can differ by pixels.
• Geometry/mesh outputs depend on the exact input mesh and its scale/orientation conventions.
• Simulations depend on time-step, solver tolerances, and RNG seeding.
• Learning-based results depend on released weights and inference data, not just source code.
• Timings — a first-class SIGGRAPH claim — depend on GPU/CPU, driver, and resolution.

If you cannot say exactly what a result depends on, you cannot make it reproducible.

Pin provenance at creation time

These cannot be reconstructed after the fact:

• Scenes and assets: record the source and version of every scene, mesh, texture, and BRDF; ship them or give a stable download. A method evaluated on unshareable assets is unreproducible by construction — say so and provide a shareable proxy scene.
• Seeds and configs: log the seed, sample count, resolution, and every hyperparameter behind each figure. Store the config with the output, not in your memory.
• Hardware and software stack: GPU model, driver, CUDA/compiler versions, OS. Graphics timings are meaningless without them.
• Model artifacts: for learning-based work, pin the training data snapshot, the released weights' hash, and the inference command.

Handle non-determinism honestly

Do not claim bit-exact reproduction you cannot deliver:

• Declare the tolerance. State whether a result is bit-exact, or matched within a metric (PSNR/SSIM/LPIPS/Hausdorff) and threshold, and bundle the reference output to compare against.
• Seed the stochastic path — Monte Carlo integration, stochastic simulation, dropout — and document the residual drift from GPU reductions or non-associative float math.
• Separate deterministic and stochastic figures so a reader knows which they can reproduce exactly and which only in distribution.

The release a reader can run

[README]      what it is; one command to build; one command to reproduce a headline figure;
              expected runtime and hardware
[Build]       pinned (Docker/conda/CMake) with exact GPU/driver/compiler versions
[Assets]      scenes/meshes/textures/weights bundled or stably linked
[repro/]      a script per headline figure: config in, image/metric/frame out, ref bundled
[MAPPING]     paper figure/table -> script -> expected output + tolerance
[LICENSE]     OSI-approved, so results can be reused and stamped

Reproducibility vs. anonymity

SIGGRAPH Technical Papers review has historically been single-blind (reviewers see authors), so the anonymization tax that ML/SE venues pay at review time is usually lighter here — but confirm the current cycle's blinding policy (待核实 for exact 2026 wording). If a cycle does require anonymized review, strip owner strings, lab names, and identifying URLs from the code and supplemental before upload, and swap in a de-anonymized permanent archive at camera-ready.

Anti-patterns

• Reporting a timing with no hardware, or a quality number with no metric and no reference image.
• Shipping code without the scenes/meshes/weights it needs — it compiles but reproduces nothing.
• Claiming reproduction while leaving the sampler unseeded.
• Deferring the whole release to camera-ready, when provenance had to be pinned during the work.
• Treating "available upon request" as a release — it is a scored weakness, not a neutral choice.

Output format

[Result classes] images / meshes / simulation / learned / timings present
[Provenance] scenes+assets pinned? seeds+configs logged? hardware stack recorded? yes/no
[Determinism] tolerance stated + reference outputs bundled? yes/no
[Release] build + repro scripts + figure->script mapping present? yes/no
[Blinding] cycle policy confirmed (single-blind vs anonymized)? action if anonymized
[Gaps] <ordered, with what must be pinned before it is lost>