Journal of Computer Graphics Techniques Review Form

Reviewer Instructions: Complete this form and return it to Marc Olano
at editor-in-chief@jcgt.org as an e-mail or e-mail attachment in plain
text form. Please do not convert it to PDF.

Please phrase your comments to preserve your anonymity.

We invite you to diverge from the format here if there is a better way
to organize your feedback on this paper.

A member of the editorial board will read this form and then either
shepherd the paper through publication (possibly with another round of
review), or reject the paper (with later resubmission allowed).



A JCGT paper should provide a concrete technique with sufficient
information to allow the reader to:

* Understand how it differs from alternatives
* Know the advantages AND limitations that will likely be encountered
  in practice
* Immediately integrate it into a production workflow

While not every acceptable paper must have this form, a great example
of a JCGT paper would be a technique that addresses a common graphics
problem, has been used in production, can be well-summarized in a few
pages with a complete implementation in a popular language and full
performance or accuracy evaluation.

As an example, SIGGRAPH paper on a new stable physics algorithm would
have a philosophical introduction, extensive related work, a
derivation section, and attractive result images for some common
benchmark scenes. A JCGT physics paper might instead begin by
sketching available physics libraries, have a minimal related work
section on current research, give a derivation augmented with complete
source code (maybe as supplemental files), and replace the results
section with timing on various architectures, extensive discussion of
stability and limitations, and a table of results on real-world test
cases.


_____________________________________________________________________________
Paper Title:
Paper Authors:


> *  What kind of paper is this?
>       Novel Research/Algorithm/System
>       Survey
>       Experience/Advice/Case Study
>       Production/Implementation Notes
>       Tutorial
>       Data Set



> *  Is this a paper that others should read?
>
>    If this paper answered a question that you have, made more clear
>    how to implement something, changed the way that you think about
>    a problem, enabled further work, or worked out the details of
>    something that you've thought of before, then it probably is
>    interesting to JCGT, regardless of the magnitude of the
>    contribution. If it re-covers old ground or doesn't distinguish
>    itself along at least one axis like clarity, reliability, or
>    quality, then this may not be the right venue.



> *  What is the concrete contribution ("technique") of this paper? 
>
>    This should be an algorithm, piece of code, workflow pattern,
>    data set, proof, equation, circuit, system, or survey that the
>    readers can directly apply to their own work.



> *  How does this technique improve on the existing literature for the
>    topic?
>
>    For example, it may offer better performance, fewer limitations,
>    make the implementation clearer, provide better evaluation, etc.
>    An idea need not be novel, but it must offer improvement.
>    Likewise, a technique need not be better in all dimensions--a
>    slower method that saves space or is easier to implement may be
>    of value. Sometimes there is significant related work that the
>    author may be unaware of that alters the value of the
>    contribution. If that is the case, please give a citation and
>    explain the significance.



> *  Is this paper topical? 
>
>    If this is something that you want to try, tell your colleagues
>    about, or wish you had known earlier, it is sufficiently topical.
>    Do you want to see a paper on this topic or technique published?



> *  Does the paper provide sufficient information for you to deploy
>    the technique?
>
>    It should prevent you from going down false paths, avoid having
>    the implementer reconstruct tedious details, generally speed
>    integration, and indicate strategies for verifying correctness.
>
>    List any additional elements required to deploy it that are not
>    provided. 



> *  How has the technique been proven or battle-tested? 
>
>    Some ways to demonstrate this include: use in production, formal
>    mathematical proof, and extensive accuracy and performance tests
>    on real-world data. "Production" need not be commercial, e.g.,
>    widely-adopted open source applications and libraries, and
>    teaching and research infrastructure used for several years
>    contain techniques that are useful, well-understood by their
>    authors, and reliable. (An idea may be worthy as research, but
>    not mature enough to be considered a graphics technique.)
>
>    List additional information, tests, data, or experiments required
>    to achieve this threshold.



> *  Evaluate the title and abstract.  How can they be improved to better 
>    explain the take-home contribution of the paper?



> *  Rate the quality and level of detail of the exposition as a whole.
>
>    A JCGT paper need not have explicit "related work", "results",
>    and "conclusions" sections. It should offer extensive
>    verification. The text should be to the point, limit itself to a
>    single topic, and be supported by lists, equations, tables, and
>    figures as needed.
>
>    Note typos, confusing sections, figures, or ambiguous text. Also
>    note exemplary text and diagrams. Suggest material that could be
>    cut to tighten the focus on the core contribution of the paper.



> *  List objective factual errors or overstatements in the technical
>    content of the paper. Please suggest corrections where possible.



> *  Is the bibliography adequate (not too little or too much)?  
>
>    JCGT papers should only cite directly relevant work that is
>    discussed in the text, and should not cite early papers on topics
>    that are so commonly known as to appear in textbooks. Often three
>    citations are sufficient. Primary, archival, and peer-reviewed
>    sources are strongly preferred because they stand the test of
>    time. Please suggest specific references that might be
>    eliminated, for example, ones that nod to previous work but which
>    you don't realistically see a reader seeking out in response to
>    this paper.



> *  Is the paper ready for shepherding by an editor to incorporate
>    changes requested in this review?
>
>    If you could imagine making the edits and additional experiments
>    in a week if working on it full-time, then it is probably close
>    enough to start shepherding instead of asking the author to
>    revise independently.



> *  Additional comments are welcome here.