| name | siggraph-author-response |
| description | Use when writing the SIGGRAPH / SIGGRAPH Asia Technical Papers rebuttal, the single 1000-word text-only author response uploaded during the rebuttal window to correct factual errors and answer specific reviewer questions before the Technical Papers Committee meeting, and when planning the change list for a conditionally accepted paper's second-stage revision. |
SIGGRAPH Author Response
SIGGRAPH gives you exactly one written turn before the decision — the rebuttal — and, if the
paper is conditionally accepted, a second-stage revision handled through the camera-ready. These
are different instruments; do not treat the rebuttal like a journal response letter. Facts below
were read from the SIGGRAPH 2026 reviewer-instructions/ethics page on 2026-07-09
(resources/official-source-map.md); reconfirm the length and window on the live call.
The rebuttal: a hard 1000-word, text-only turn
- Length: up to 1000 words of text only — no images, no video, no URLs to external
pages. Everything you say must be self-contained in prose. (SIGGRAPH 2026 window: 5-12 March
2026; upload before 22:00 UTC/GMT on the close date.)
- Timing: you see the complete set of reviews when the window opens; the rebuttal is read by
the referees and factored into the Technical Papers Committee discussion that produces the
decision.
- Purpose (narrow): correct factual errors in the reviews and answer specific
questions. It is not a channel for new results, revised text, or a redesigned evaluation that
does not directly answer a reviewer's question. Promising a new experiment rarely moves a score;
correcting a reviewer's factual misreading can.
Triage the reviews before writing a word
- Separate factual errors from judgments. "The method cannot handle X" when your Section 4
shows X is a factual error you can flip; "the contribution is incremental" is a judgment you can
only reframe. Spend words where they change a number.
- Find the pivotal reviewer. With a small committee and a single score scale (Strong
Reject ... Strong Accept), the borderline reviewer whose vote decides the paper is your
audience. Answer the objection that is actually holding the score down, not the easiest one.
- Cluster shared concerns. If two reviewers doubt the same comparison, answer it once, well,
and cross-reference — you cannot afford to repeat yourself inside 1000 words.
- Concede cheaply, defend precisely. Acknowledge real limitations in one clause and move on;
spend the saved words on the one or two objections that decide acceptance.
What actually persuades a graphics committee
- Point to evidence already in the submission. "Fig. 7 (row 3) and the supplemental video at
0:45 already show the failure case the reviewer asks for" beats "we will add this." You cannot
attach new media, but you can direct referees to what you submitted.
- Quantify a correction. If a reviewer misread a timing, state the correct number and where it
appears. Numbers close factual gaps that adjectives cannot.
- Name the comparison honestly. If a reviewer wants a baseline you did not run, say whether it
is applicable, what it would likely show, and why your existing comparisons already bound the
claim — do not bluff a result.
- Protect the results video. Many graphics rejections turn on artifacts a reviewer saw in
motion. If the criticism is about a visual artifact, address the specific shot and timestamp; if
it is a genuine limitation, say so and scope the claim.
Draft structure (fits 1000 words)
[Opening 1-2 sentences] Thank reviewers; state the 2-3 decisions your response will address.
[R-common] The shared concern (e.g., missing comparison / validation), answered once with evidence.
[R1 / R2 / R3 specific] Only the factual errors and specific questions that affect the score.
[Limitations] One honest paragraph: what you concede and how you will scope claims in revision.
[Close] One sentence on the concrete change the camera-ready will make if conditionally accepted.
The second stage: conditional acceptance is a revision, not a formality
If the committee conditionally accepts the paper, a Technical Papers Committee member verifies
the final version in a second reviewing process — required changes must actually be made. Treat
the conditions as a checklist:
- Map each required change to a specific edit, figure, or added result and track it.
- Deliver every promised revision; the second-stage reviewer can withhold final acceptance if
conditions are unmet.
- Keep the supplemental video and code in sync with the revised claims — a fixed artifact must be
re-rendered, not just described.
See siggraph-camera-ready for the mechanics of the conditionally-accepted final version.
Anti-patterns
- Spending words re-explaining the method instead of answering the objection.
- Promising experiments you cannot run, or implying media you cannot attach.
- Arguing with a judgment ("this is novel") rather than supplying the missing fact.
- Ignoring the pivotal reviewer to score easy points off a lenient one.
- Exceeding 1000 words or embedding a link/figure — mechanically stripped or penalized.
Output format
[Rebuttal plan] pivotal reviewer + the 2-3 decisions to address
[Factual corrections] <review claim -> correct fact -> where it already appears>
[Concessions] <limitation conceded -> how claims will be scoped>
[Word budget] running count against 1000, text-only confirmed
[If conditionally accepted] <required change -> planned edit -> owner>
