This post is part of a series of guides on how to write your first ACM SIGGRAPH / TOG paper. You can find the other articles here.
How do I structure a paper? There is no right answer or silver bullet method when writing a paper, as with most other things about doing research. Some great papers are actually written by deviating from typical forms. But if you write your first paper, it would be good to see how the other people typically structure a paper. The typical structure would also make people also feel comfortable when reading or reviewing your paper. Here, I describe the typical way (that I think) to structure a SIGGRAPH/SIGGRAPH Asia (collectively “SIGGRAPH” below) paper. Basically, most SIGGRAPH papers organize sections in the order of introduction, related work, method, experimental results, and conclusion (the exact section names may not be the same, though). Let’s see them one by one.
Introduction
Craig Reynolds wrote a great article about how to write an impressive introduction, so I’ll not go into it. But in a nutshell, the rule of thumb is that the introduction is a summary of the whole paper, the abstract is also a shorter version of the summary, and the title is a one-phrase summary of the entire paper. Hence, it would be good to write the introduction after writing all the other sections, then the abstract, and then the title. While you would have an original goal of the project, you may find you adjust the narrative of the paper while you write the method and experimental results sections — it’s common that people realize what they wanted to say after writing the paper. Thus, you can better see how the introduction should be written after making at least a draft of all other sections.
Related Work
Related work is a relatively independent section from the others. While the related work section will also need to be tuned with the exact narrative of the paper, you can easily put a draft before working on the other sections. My typical strategy for writing the related work section is to
- first list up all the related papers,
- write a tl;dr-like a few sentences for each of them,
- classify them into some categories, and
- write a couple of paragraphs for each category based on the tl;drs.
(1) and (2) are the jobs you can do any time while you work on your project. 2-4 categories are generally ok. For the categorization, think about the literature on the problem you’re solving, and also the literature on the other techniques relevant to your algorithm. For instance, if you see CLIPasso [1], one of the Best papers at SIGGRAPH 2022, it’s about converting an image into a sketch using the CLIP model. Hence, the authors added paragraphs about “Photo-Sketch Synthesis” and “Sketches Abstraction”, “Vector Graphics” since the output is a vector presentation, and “CLIP-based Image Abstraction” since the method leverages CLIP. You’ll also be able to come up with more related papers after deciding on the categorization.
When you summarize the related work in each paragraph, do not just introduce each work but focus on delivering a summary of the whole literature and, more importantly, describe how your work is different from/related to the other work. Does yours solve a different problem? Does yours propose a different approach and achieve the SotA performance? Does yours leverage some ideas in the related work? Make a concise argument about the differences or relevances to the related work. Don’t forget that the goal of the related work section is not just to introduce the literature but to argue why your work is novel compared with previous work.
A couple of tips: If there is a series of work solving similar problems, and if there are some aspects you want to emphasize as advantages of your method, consider adding a comparison table with check marks. Table 1 in CLIPasso [1] shows a good example. Also, if there are a few previous works that are especially close to your work or the main competitors of your work, it’s worth making a separate paragraph for them and emphasizing the differences or advantages of your work.
Method
The method section does not need to be a single section; background, problem definition, overview, implementation details, etc can be separate sections, and even the method itself can be explained in multiple sections. Also, the title of the method section doesn’t need to be “Method”. Use the method name or the most effective keywords to describe the main ideas of the method.
Background. First of all, your paper should be self-contained, meaning that the readers should be able to understand the method without reading the other papers. Research papers target researchers as readers, and thus in a SIGGRAPH paper, you don’t need to describe any basic background of graphics. But if you think the readers need to know prior work to understand yours, it’s good to start the method section(s) with a background. You can also add the background in the related work section; see InstantNGP [2] and Spelunking the Deep [3], the other two Best papers at SIGGRAPH 2022, starting the related work section with background about positional encoding and neural fields.
Problem Definition or Overview. Before you get into the details of the method, first describe which exact problem you solve. What are the inputs and expected outputs? What are the assumptions? How exactly the inputs and outputs are represented? What is the given information? While defining the problem, you can also introduce some terms and math notations you’ll use over the rest of the paper. If your paper is also a system paper introducing a big framework with multiple components, start the method section with an overview depicting the big picture and a pipeline figure. Once you describe the whole framework, you can briefly mention how each specific component will be explained below.
Exposition. Do not write the method section like a cooking recipe or the readme file in your GitHub repository. Describe your algorithm, not the code. The readers want to see what are the key ideas of your algorithm. The implementation details can be added at the end of the method section, in the results section, or in the supplementary if you have a space limit. You don’t even need to explain your algorithm in the order of the pipeline. Explain the key components first. If you didn’t add an overview at the beginning, you can consider adding pseudocode at the end while describing how all the key components are integrated into the framework. Spelunking the Deep [3] shows a good example; see the pseudocode above Section 3.6 Implementation.
Figures and Equations. Utilize figures and equations as much as possible to explain your method more effectively and concisely. A figure can compress lots of words in the text, and an equation can also clearly state what you mean. Think about how you will place figures and equations while you write a draft. Note that equations need delicate design in math notations, like defining variables in coding. Before writing equations, draw the whole picture of your method in your mind, define all the math notations first, and think about how you’ll introduce the notation in the problem definition or the overview.
Experimental Results
Experiment Setup. First describe the dataset and the other experimental setups. There can be popular benchmarks for some well-known problems, and you’ll need not to miss them in your experiments.
Evaluations and Comparisons. Add figures and tables for qualitative and quantitative evaluation results. These are one of the most important parts in the paper review process, so take special care of them and make the best version through multiple iterations of polishing. Think about how you will order the results based on their importance and impressiveness; the most impressive results should go to the teaser by the way (the first figure right below the title and the author list). In comparisons, introduce proper baseline methods to be compared with your method and quantitative evaluation metrics. Analyze the qualitative and quantitative results in the text and highlight in which aspect your method is better than the baselines.
Ablation Study. Especially many neural-network-based approaches these days combine multiple novel components in the pipeline. Analyze the effect of each component while ablating one by one in the experiments.
User study. Using human perception is sometimes the only way to properly evaluate the performance of your method. Bylinskii et al. [4] provide an excellent guide about conducting user studies for computer graphic research in their article.
mturk-2afc [5] repository from Brown University is also helpful for some basic user study tasks.
Applications. It would be a big plus if you can showcase downstream applications based on your method. For instance, in my paper, ComplementMe [6], I showed an interactive modeling tool based on an iterative part assembly method. You can put the applications at the beginning or at the end, depending on whether you want to emphasize the applications or the outperformance of your method compared with baselines.
Conclusion
The conclusion is not just another summary of the paper. Don’t forget to discuss the limitations of your method and future directions. The conclusion is typically written at the very end of the writing; it’ll be definitely easy to conclude your paper after writing all the other sections.
Page Limit for Conference Track
This year, SIGGRAPH introduced the conference track that has a 7-page limit except for the references. Even when you prepare a conference track submission, I recommend not to consider the page limit when you write a draft. Make a submittable paper while putting all the content, prioritize the content, and then cut out from the least important one (actually, don’t cut out but move things to the supplementary). Also note that small adjustments in the size and margin of figures, tables, and equations can make a big space. Your job right before the submission after all the polishing steps would be to play with the space and make an exact 7-page paper.
Final Remark
There is no rule in paper writing. See that the submission guidelines in SIGGRAPH homepages do not describe anything about the paper structure. The above is just an example, and also different venues have different typical forms. For instance, in machine learning conferences (e.g., ICML and NeurIPS), the related work section sometimes goes after the experimental results. I hope this blog helps you to prepare your first SIGGRAPH submission and eventually find your own way to write a paper.
This post is part of a series of guides on how to write your first ACM SIGGRAPH / TOG paper. You can find the other articles here.
We thank Mazdak Abulnaga for proofreading.