Confessions of a researchaholic

Every research paper has to cite and describe relevant previous works, often in a dedicated previous work section, or sometimes as part of the introduction.
Trying to write a previous work section can be an excellent mirror exercise for reading papers. The quality of the former can be a good indication of how much you really understand from the latter.

First of all, spend enough time reading how other people write previous work sections. Pay particular attention to those you find educational, from which you can actually learn something, as well as those you find unhelpful, from which you feel only confusion and frustration.

A good previous work section contains multiple layers of information with different resolutions of details.

• At the bottom level (highest resolution), you describe in one or a few sentences about the gist and merits of each paper.

• At the middle level (medium resolution), you organize related papers into paragraphs, each contains information about the gist and merits of the group.

• At the top level (lowest resolution), you relate every citation with your paper, in particular, how yours stands on the shoulders of previous giants: commonalities, inheritances, and mostly importantly, innovations.

After you have a draft, show it to your adviser or other experienced researchers, ask for advice, and iteratively improve it. It will be an excellent exercise for both reading and writing papers.

Many mentors have their own favorite entry level project for both training and sieving purposes. And mine is ray tracing.

Read + code

Read the following books and implement your own ray tracer from scratch.
Yes, I mean writing every single line of the code yourself, except for standard libraries like iostream and cmath. And yes, I recommend c++ as the programming language.

Ray tracing in one weekend, by Peter Shirley.
Path tracing with soft phenomena. Very short and cute introduction to ray tracing in particular and computer graphics in general. Full of hidden gems and wisdom, but beginners might not appreciate all the nuances.

An introduction to ray tracing, by Eric Haines, Pat Hanrahan, Rob Cook, Jim Arvo, David Kirk, Paul Heckbert, and (edited by) Andrew Glassner.
Whitted-style ray tracing with hard phenomena. More comprehensive than the book above.

You should read the books (especially the first one) on a computer and code along. Do not just read; it is less fun and less effective.
Software engineer your code from the very beginning; ray tracing is nicely object oriented with natural object-like components such as rays, shapes, materials, colors, motions, and cameras.

Demo

Produce your own ray traced images. Start with something simple, like mirrors and glasses for basic reflections and refractions. Ultimately, I want to see 2 things:

• Produce ray traced animations from the BART benchmark. (If you can reach this stage, I consider your training complete. If you cannot even get to this point for whatever reason, you have no chance to survive in our future projects.)
• Design your own favorite scene, and ray trace it. Show me your creativity and artistic + scientific blend. You can find examples from prior Stanford cs348b rendering competitions.
  (This part can be good for a group project, even though I expect everyone to complete everything else individually.)

Why

I did ray tracing as part of Stanford CS348b image synthesis, and I would say this is perhaps the class that I have learned the most from.
First, ray tracing is a superb training for coding and software engineering; it is inherently modular and suitable for object oriented programming, and the amount of coding is non-trivial (actually, quite hefty for new-comers, especially if you code from scratch).
Second, ray tracing is a superb introduction to image formation, and you will learn the fundamentals of physics, computer graphics, computer vision, and image processing.
Third, and perhaps most importantly, it is heck of fun. It is beyond words for me to describe the satisfaction I (and many people I heard from) derived from producing my first ray traced image. I am not an artist, but I can paint with algorithms.

P.S.

There is another excellent book for ray tracing: Physically based rendering, by Matt Pharr and Greg Humphreys, but I personal opinion is that you should read it as your second, not first, ray tracing book.

Sylvain Lefebvre has a nice post about how to structure code for producing research results; see here. (Full disclosure: Sylvain is my collaborator, but he is a superb researcher and coder, as evident from his resume.)

Congratulations that your paper has been accepted to the most prestigious conference in your academic field. You can have a sigh of relief and take a vacation. You deserve it.

But your job is not over yet. You still have to present the paper.

It is important
The presentation is essentially a promo for your paper, and to some degree, for yourself. So it is to your advantage to give a good talk. And if you are relatively junior in the field, you should do it yourself (instead of your adviser or another co-author). This will give you the necessary exposure and recognition.

It is a sales pitch
This can be a personal preference, but for me, a conference talk is more of an advertisement than an education. A very common mistake is trying to cram in all the information into a presentation, hoping that the audience will understand everything. Unfortunately, the talk slots are usually too short and the audience too distracted for this to happen.

Instead, consider the conference as a social event, and your talk a sales pitch. Your goal is to attract people to get interested in your paper, so that they will later spend time reading it. And if you can give a good talk, it also helps sell you as a good researcher. This can translate into long term benefits, like job offers.

Content
The content of your talk should be mainly about the following: (1) why people should care about your paper, (2) why they should read it after your talk, and (3) what are the key points of your paper. Remember, it is more of an advertisement (1 and 2) than education (3).

Actually, there is one more: (4) what a cool and smart guy you are. But you really need to know what you are doing. And if you do, you are beyond this post already.

Practice
Finally, practice your talk, both with yourself and in front of an audience. If you are relatively inexperienced or have a certain degree of glossophobia (most people do), practice enough times so that you can give the talk while sleeping. I practiced at least 20 times for my first SIGGRAPH talk, even though nowadays I usually do just once or twice to avoid cruising through my talk with a too rigid or scripted performance.