After writing some product code which is serving hundreds of millions of people everyday, I have realized that these industry coding practices are also very useful for most research projects. Below are some most important tips I have been using for my research projects based on revision control via GitHub.

Using Pull Requests (PRs)

  • Always develop on your own development branches and create pull requests to push changes into the master/release branch, even if you are the only one who writes code for the project.
  • When to create a PR? In most cases, each PR should contain a small group of commits that have reached a certain milestone, such as adding a new algorithmic component or fixing a serious bug.
  • What to write in a PR? In each PR, provide some brief information about the background/context and the changes. Add some experimental results if possible. See a simple example here.
  • When to merge a PR? A PR is ready to be merged when the PR has been approved by reviewers, the changes have been verified via experiments, and/or the code has passed build test.
  • How to merge a PR? When merge a PR, use the “Squash and merge” option to keep a clean history of commits in the base branch.

Some Additional Notes

  • Do not put large data assets such as image sequences or videos under git. Use Git LFS if necessary.
  • Do not merge temporary code (e.g., for debug purpose) into the master branch.
  • Open issues to track major bugs and to-do items.
  • Commit frequently just in case…

My de facto PhD supervisor, Dr. Li-Yi Wei, has also written a blog post on the same topic with many useful tips.

Improve your game

In order to improve your game, you must study the endgame before everything else, for whereas the endings can be studied and mastered by themselves, the middle game and the opening must be studied in relation to the endgame.

–José Raúl Capablanca

(This post is mainly for those junior students who are leading their research projects. If disagree, please read the disclaimer.)

Be polite.
When you disagree with anybody, no matter how stupid you think others’ ideas are, always express your opinions in a respectful way, because it is necessary to maintain a good team relationship and sometimes you are actually the one who is wrong. For example, instead of saying “I don’t believe it will work” or “I don’t want to do this”, it is much better to say “I’m afraid it will have some problems like …” or “I think it may be better to do …”. Also, don’t ignore any explicit question from your collaborators, regardless of how simple it may be to yourself. When they ask, it is a real question and they are seeking answers (or at least some thoughts) from you.

Start from the big picture.
When begin a discussion or a meeting, always try to start from the big picture, e.g., the high level goal of the ongoing test/experiment, before jump into technical details at the very beginning. Furthermore, when communicate with those who are busy with multiple tasks, it usually helps to remind of the context, such as the conclusions in the last meeting.

Provide reasons whenever possible.
I find it very useful to provide reasons together with the conclusions, especially for offline communication like emails. It will significantly reduce the chance of potential misunderstanding/confusion and thus improve the efficiency of the communication. Different people think about the same problem in different ways, even for those who have worked together for a long time. So it might be better not to take it for granted that your collaborators will understand your opinions.

How to read papers

Before trying to answer the question about how to read papers, I would like to share my experience about which papers to read. My general suggestion is to read as much as possible. The goal of reading papers is pretty simple: you should get a comprehensive understanding of the entire field you are working on, so that to prevent yourself from reinventing the wheels, and to draw inspirations from previous work, especially state of the art.

Every student/researcher in computer graphics may pay special attention to Ke-Sen Huang’s Home Page, which covers almost all the top conferences about computer graphics. I check the update of this page frequently and follow all the latest change there. But just following Ke-Sen’s page is not enough, there are also several major journals (such as TOG, TVCG, CG&A and CGF). Fortunately you can subscribe to the publishers of those journals and get notifications about the latest publications promptly via any RSS reader. Furthermore, for some important papers, it is worth taking a look at the reference lists in those papers as well as all the follow-up work by searching later publications that have cited them.

To read a paper, I think the key point is to get the big picture. Specifically, it’s much more important to figure out what the authors did and why they did this, compared to how they did. I would also suggest to be positive when reading a paper. Every paper got published for certain good reasons. Instead of thinking as “how they can publish such a bad paper”, it would be more helpful trying to find those good reasons.


I have just realized that to be successful in computer graphics research (and maybe in other fields as well), you should have a strong personality, which is much more important than any technical skills such as coding and writing. To have a strong personality does not mean you should create your own style other than anybody else, but I think in general you should be tough.

I learned this not from my own experience (I don’t consider myself very successful yet), but based on my observation as well as what I’ve heard about some really successful researchers.

The computer graphics community is becoming more and more competitive, in both industry and academia. There are about 200 SIGGRAPH/SIGGRAPH Asia/TOG papers each year, plus hundreds of good publications on other top venues. So to survive this community you have to put dedicated effort into your research for years. It is very inspiring to see so many people who are smarter yet work harder than me all the time.

I feel extremely lucky to collaborate with many great researchers who all have strong personality but work in totally different ways. Some of them can communicate with me on a daily base for years via writing like a robot, while some of them are invisible most of time but will suddenly appear before the submission deadline and clean up all the bugs in my code while I’m near a break point at midnight.


Recently I have been advised to share my experience about doing computer graphics research via public blog. I have decided to follow the suggestion so this blog may become more active from now on.

But first of all, I would like to put a disclaimer here. All the opinions to appear in this blog will be based on my personal experience, which may not work for anybody else due to the biodiversity of human beings (including the strong personality of myself as well as my collaborators). So please consider the future posts at your own risk.


I have finished my PhD for more than one year. Here are my random thoughts about doing a PhD based on my own experience as well as my recent observations.

  • This competitive world is producing PhDs much more than necessary. Many graduated PhDs take job offers which do not require a doctor degree.
  • In most cases doing a PhD is very tough, if you want to graduate within a decent amount of time, seriously.


I feel extremely lucky to spend about 4 years in MSRA and take part in a very special meeting on the very last day…

It turns out that Microsoft Visual Studio 2010 stores the StartUp Project information in the *.suo file associated with the entire solution. But usually this *.suo file is not kept for code release or revision control. Notice that by default VS2010 considers the first project in the *.sln file as the StartUp Project, so one dirty hack to keep the StartUp Project information without the *.suo file is to edit the *.sln file in Notepad and make the desired project appear first.


Just follow the steps below:

  1. Take a photo with a camera or cell phone;
  2. Crop it with a large aspect ratio;
  3. Change the tone style (optional);
  4. Letterbox the picture and add subtitle.

Original photo:

Final result: