Coauthors revealed a secret in a recent paper that gave us all street credits.
(It is in plain sight for anyone to see, so I won’t tell.)
December 11, 2014
Coauthors revealed a secret in a recent paper that gave us all street credits.
October 13, 2014
There is a course in the upcoming SIGGRAPH Asia 2014 conference on how to make a SIGGRAPH paper.
The content has not been completed decided. If there is anything particular you like to hear about, feel free to leave a comment below within the next 13 days. You can do so with anonymous or real identity.
Please also help spread and share this.
December 23, 2013
Not having to observe Western holidays is your competitive advantage. Don’t squander it.
July 26, 2013
I did not bring my laptop to SIGGRAPH this year to discourage myself from working inside the convention center or the hotel room.
Experimental results indicated that this motivated me to spend more time hanging out with people, which is supposed to be the main goal for a conference. I can easily schedule all events and meetings via my smart phone and tablet. (Even the tablet is probably not necessary, if I can address a few technical issues of my phone.)
I probably would have had to bring my laptop if I had to give any talks. None of the Android apps I know of can adequately author talk slides. If such apps eventually show up (and I expect they will), I would happily travel with only my phone in the future.
Eventually though, the phones will likely become powerful enough for me to work inside the hotel rooms (again).
July 18, 2013
Most paper committees I have served have purely electronic review processes. These are relatively easy. Those with in-person meetings (e.g. SIGGRAPH) are more challenging as they involve live human interactions in real-time.
Below are some of my personal experiences to make the process more fun and effective.
The most important and yet difficult task is to remain neutral, no matter what happens. It could be quite some experience to see your paper getting rejected and immediately you have to discuss a paper you reviewed.
I have a very simple strategy that works superbly well for me so far: I just assume all my papers are (or will be) rejected, even if they have very high ratings. (Anything could happen, and has happened before.) By assuming the worst case scenario, I can never be disappointed. I also do my best NOT to track my papers; I did not even look at the status on the spreadsheet when I am outside the room. Then it is easier for me to remain cool.
It also helps if you naturally care less.
One possibility is to not have any submission, but this is not common for people who are still productive.
Another possibility is to have enough prior papers so that you care less.
The paper chairs like to recruit more senior people not only for experiences but also for this “care less” factor.
Other things being equal, it is usually better to be positive than negative. My rule of thumb is to accept if unsure. This is better for humanity; a good paper wrongly rejected will not be read by anyone, while a bad paper wrongly accepted will likely be ignored by future research anyway. This is also better for myself; I do not want to leave a reputation for being a paper killer.
It is a lot of work to review 20-something papers. You will look bad if you do not seem to know what each paper is about, especially during the plenary sessions or breakout discussions. So make sure you put in enough efforts.
I also keep enough dark chocolate around to maintain my brain function at the end of the (long) day. (OK this is probably some lame excuses; I overdose cocoa no matter what.)
I am probably lucky (or maybe I am good at requesting papers; dunno yet) in that I usually get good assignments (high quality submission fitting my interests and expertise well), so I usually know each paper well. For those few that are outside my expertise, I just admit it to other committee members and reviewers. Nobody knows everything, so honesty is often the best policy.
Plus, I guess many of you have seen reviewers who clearly have no idea what the f*** they are talking about, so try not to be such jerks.
For those of you who think the committee members have some edges in getting their papers in, you might be disappointed; as far as I can tell, no such advantages exist, and the system has been well designed so that it is very difficult to game.
However, the committee members do have advantages in organizing the paper sessions, which is also the most fun part of the committee service in my opinion. You can influence where and when papers (including yours) go and which sessions you chair. People who do not show up might find papers (they authored or reviewed) going to a strangely titled session with a motley collection of seemingly unrelated papers, or find themselves chairing sessions that are too early for many people to wake up or too late in the last day for many people to remain behind.
June 2, 2013
Giving a good paper presentation is already hard, but at least you have 20 minutes’ worth of wiggle room. Giving a good paper fast-forward is even harder, because you have only 40 seconds. Even one tiny mistake can ruin you.
The most common mistake is trying to explain too much (I like to call it “geek’s asymmetry”). Trust me; almost nobody will care, and certainly nobody will understand, within 40 seconds and among 100+ presentations.
The fast-forward is pure advertisement with one main goal: get people read your paper and attend your talk.
On top of that, if you are really good, show what a cool and interesting guy you are. But do not even try unless you are absolute sure. (A good rule of thumb is this: are you already cool and interesting?)
Write down the script first, so that you know what you want to talk about and you can comfortably utter the sentences within the limited time frame. Practice and rehearse a sufficient number of times, especially if you lack verbal proficiency. Only design your slides after the script is in a stable condition. This is extremely important. If you do it the other way around, and I know this is what most people would do, you are making a grave mistake, because (just like what movie critics would say) you are letting the effects get in the way of the substance.
Do not force people read your slides. Use pictures and animations instead of texts to explain your points.
After having both the script and the slides, practice, until you can do it perfectly during sleep.
March 15, 2013
A recent PhD graduate whom I know well, who has been doing quite well in graphics research, just took a non-research job in a non-graphics position, among several postdoc offers from top research institutions.
The reasons he cited are numerous, but the 2 main ones are:
. He likes graphics research, but he is getting bored and tired of the SIGGRAPH game, including deadline crunch and dealing with reviewers.
. He would like to learn something new and try a different life style.
In a nutshell, I think he is burned out. I hope I have done my best to help him achieve work-life balance (I did that quite well myself, even when I was a grad student), but I guess it is just too hard for normal people to be much disciplined.
Then I realized that I probably also had some kind of burnout around my graduation. I took a non-research position as the first job, even though it was in a graphics company (NVIDIA). I also wanted to try learning new things (hardware architecture) and living a different style (engineer).
So I guess it is probably OK. People are not meant to be doing the same thing all the time. This is also why I like to try different job sectors and geographical locations.
There are two things to watch out, though, all based on my personal experiences: passion, and rust.
I have a very simple rule to choose jobs: do what you really like, and be very good at it.
Sometimes, when people get burned out, they might temporarily settle for something that they neither really like nor really be good at. But eventually, you will know if the job is not for you. I did not realize how much I like doing research until after I was not been able to spend enough time on it for about 3.5 years after my graduation.
The important thing is to get out there as quickly as possible. Otherwise, you will eventually become one of these people who are not really happy or good at their jobs but also cannot quit.
People tend to get rusty for skills that they have not practiced for a while. This is particularly so for advanced skills, like research.
So, make sure you do whatever you can to be active in research during your non-research job. Otherwise, you might not be able to come back, even if you want.
I have been trying my best to be engaged in research during my NVIDIA days. I even managed to publish a single authored graphics hardware paper. But it still took me about 2 to 3 years to get back in shape for SIGGRAPH after joining MSR. The difference between SIGGRAPH and other graphics venue is like the difference between playing professional sports and working out in a gym.
I guess SIGGRAPH is probably an extreme case, but I hope you get what I mean.
January 7, 2013
It is usually a very good idea to share the code and data along with your published papers. This will make it easier for others to reproduce and compare against your methods, which in turn can make you more popular and your papers more widely cited.
As a corollary, it could also a good idea to submit your code and data along with your paper for peer review. Reviewers tend to like your paper more if they can reproduce your results. However, there are a few things to watch for. The first, and the obvious one, is to make sure your code actually works as advertised. Another is author anonymity; for venues that mandate it you will want to make sure your code and data (just like your paper) do not contain any information that can identify the authors. If you have doubts on this, one possibility is to submit your code and data as non-anonymous materials, if the particular venues allow this (e.g. SIGGRAPH). This can reduce the risk of breaching anonymity and yet allows the committee members to back you if the need arises.
December 31, 2012
In a nutshell, a demo should properly demonstrate technical aspects with sufficient artistic appeals.
The technical part is usually more important, and can suffice alone for many science and engineering disciplines. However, the artistic part is also very important for graphics and HCI, or any fields which involve direct human perception and consumption.
Demos usually take a lot of time and efforts, on top of the usual workload in ideation, writing, algorithm, implementation, and experimentation. And whether you like it or not, a solid and novel algorithm cannot be adequately assessed or appreciated by the readers if it is not demonstrated through proper demos.
Thus, designing demos is kind of an art. Below are recent suggestions from Sylvain Lefebvre which I have found to be excellent.
A guideline that worked fine for me is to consider whether 1) the result demonstrates the technique properly and 2) the result looks just good enough that it appears useful; in particular we want to avoid people think that the example is contrived to only show the advantage of our approach.
The problem is that 1) and 2) sometimes compete with each other (e.g. a fantastic rendering possibly making it hard to properly see the motion, etc.). Also we do not want to spend too much time on 2), only enough that people will think that it is convincing.
November 10, 2012
This figure illustrates how I collaborate with each student.
There are several main layers of a research project: idea creation, algorithm design, system implementation, and experimentation + results production. They are all wrapped up and glued together by presentation, which includes paper writing, video production, and (conference) talk.
For a beginner student, I would expect you to completely take charge of the implementation and production (including video), given the main ideas and algorithms as described in a paper draft (as part of the presentation). We could discuss anything you like, but you should be able to handle all the implementation and production details (e.g. I am not supposed to look into your code). Otherwise, you are not ready for research.
As you progress, I would expect you to be able to take charge more tasks at the higher layers. Idea creation is the most difficult and only a few can pull that off, but my experience is that a decent senior student can at least take part in algorithm design and paper writing.