Final formatted length for accepted papers will be eight double column pages, which corresponds to approximately 20 double-spaced typed pages unformatted. Authors are encouraged to consult the Communications of the ACM information for authors, published twice a year (most recently in the January 1986 CACM) for a description of ACM standard format.

The format of the papers submitted in January should be adequate for the review process. It is, of course, to the author's advantage to make the reviewer's job as easy as possible. A well-written paper, double-spaced, printed with a high quality printer or typewriter, with useful illustrations (photographs are preferable to slides) will appeal to reviewers. Given the visual nature of most of the papers presented at SIGGRAPH, it is surprising how many papers are presented for review without pictures or a videotape to support the ideas presented. It is not necessary to have the ultimate picture or the final, polished version of the videotape for review. However, the reviewers are much more likely to accept papers containing some indication that the authors' claims of generating great pictures or producing easy-to-use systems are supported over those that leave the final results to the reviewer's imagination.

The authors of each accepted paper are expected to give a presentation lasting approximately 20 minutes at the conference. Authors should include a note with their submission if they are planning anything for the presentation that is not obvious from the paper; for example, an author may point out that he/she will have a videotape or live demonstration at the conference showing the results of the paper. Authors of accepted papers are sent detailed instructions for preparing for the conference presentation.

The authors, other than employees of the U.S. government and their employers must be prepared to sign a copyright transfer form before the paper is published. ``It is a policy of ACM to own the copyrights on its technical publications to protect the interests of ACM, its authors, their employers and at the same time to facilitate the appropriate reuse of this material by others'' (extracted from ACM copyright procedures).

There is no point in publishing a paper unless it presents a solution to a problem. Try to state all your constraints and assumptions. This is an area where it can be invaluable to have someone not intimately familiar with your work read the paper. Include a crisp description of the problem in the abstract and try to suggest it in the title. The choice of senior reviewer for the paper is based almost entirely on the answer to this question.

What are the relevant published works in your problem area? What deficiencies in their solutions are you trying to overcome? How does the new solution differ from previously published results? Don't expect the reviewers to automatically know this information as they are unlikely to have read precisely the relevant literature recently. Make specific comparisons to your references; don't just compile a list of vaguely related papers.

Based on your problem statement, what did you accomplish? The author is responsible for proving that the problem is solved. Include pictures, statistics or whatever is required to make your case. If you find this part of the paper difficult to write, perhaps the work is not yet finished and the paper should be deferred until next year.

What are your new ideas? If you don't have at least one new idea, you don't have a publishable paper. Can your results be applied anywhere outside of your project? If not, the paper is probably too specific for SIGGRAPH. Beware also of trying to write a paper with too large a scope. A short conference paper can only present a few, concise ideas. Trying to turn a 100 page thesis into an eight page paper will produce a result that is either too vague to be believable or too terse to be understandable. Either isolate a small, self-contained set of ideas or write a journal article.

The question that generates the most discussion at the program committee meeting is whether a paper is complete. If the paper presents an algorithm or technique, an experienced practitioner in the field should be able to implement it using the paper and its references. If the paper claims to present a faster or more efficient way of implementing an established technique, it must contain enough detail to redo the experiment on competing implementations. When you quote numbers be sure that they do not lie; state clearly whether they were measured, simulated or derived and how you did the measurements, simulations or derivations.

Many large, poorly written papers contain a good paper trying to get out. It is the author's responsibility, not the reviewer's, to discover this paper. If you have solved a single practical problem, don't try to generalize it for the purposes of publication. If you have a formal theory or mathematical formulation, don't include all the vagaries of the implementation unless they are critical to the utility of the theory. Don't include the contents of your user's manual; try to describe the model or functionality achieved. You should assume your audience has a working knowledge of the contents of a good computer graphics text and access to the major journals in computer science and electrical engineering.

While SIGGRAPH papers are judged primarily as technical papers, consideration is also given to how suitable the topic is for a conference presentation. Think of how you would present your ideas and how big the audience is likely to be. Papers that have a small number of concisely stated new ideas, can appeal to a large audience and are visually interesting tend to be easy to present well. As recent conferences clearly show, this criteria does not eliminate papers that have mathematics, theory or are specialized if they contain significant new ideas.

A systems paper may present a real system, either by a global survey of an entire system or by selective examination of specific themes embodied in the system. Or, it may present the design for a system that includes ideas or techniques you feel are important to present to the technical community, even without an implementation. Make it obvious from the abstract which category applies to your paper.

If a system has been implemented, include information about how it has been used and what this usage shows about the practical importance of the system. Do the users include anyone other than the authors? Do they depend on it for their work or do they just play with it? If the system is still in the design phase, it is most important to state the design criteria and constraints. Back up your decisions with references to similar systems that are already implemented, stating what problems you are solving or what solutions you are including in your design. Reviewers tend to be very skeptical of design-only papers unless there are new ideas of obviously high quality.

The paper should emphasize the novel aspects of the system, what underlying themes are present, what problems were anticipated/encountered in building the system and how the structure presented provides solutions to these problems. In general, avoid details that are only of interest to users of the system and concentrate on those that would be interesting to someone building a similar system. Avoid sweeping claims, especially for paper designs. Levin and Redell's article ``An Evaluation of the Ninth SOSP Submissions, or How (and How Not) to Write a Good Systems Paper'' [1], while oriented towards operating systems, is highly recommended for further guidelines on writing systems papers.

An application paper presents an application area and a problem in that area that was solved using computer graphics. The techniques used don't have to be unique, but the use must not be completely obvious. The author should concentrate on what was learned by using graphics in this manner and how well the use of graphics worked compared to previous techniques for solving the same problem. As in a systems paper, the audience should be other applications programmers, not the end user. Successful applications papers provide some general insight into the use of computer graphics and interactive techniques to solve problems.