I joined the Stanford computer graphics lab in 1996 summer after passing the entrance test of porting the light field viewer from SGI to PC. When Pat Hanrahan gave his (last ?) SIGGRAPH talk, I was hiding on stage behind him, doing some live demos while trying not to screw up.
After that, I had no idea what I was supposed to do, so I attempted at least 20 different projects. At some point I almost dropped out to join a certain startup (well if I did I probably could retire by now, but who knows). Fortunately, my advisor, Marc Levoy, was very supportive. Eventually I took courses taught by Robert Gray and David Heeger, whose TSVQ and texture synthesis works inspired me to do a course project. I wrote it up and submitted my first single-authored paper to SIGGRAPH 1999, with scathing reviews, mostly because I did not know how to write yet. I took a writing class, and with the help of my adviser, submitted it again next year which eventually became my first SIGGRAPH paper, in 2000, 4 years after I started my PhD program.
For PhD candidates concerned about not publishing enough in their first, second, or even third year, I hope my experience can help you chill out.
I doubt how many of you could have done worse than I did during the initial period.
Granted, your situation might be different from mine (e.g. some degree program is only 4 years and your adviser might not be as cool as mine), but I want to let you know that your PhD study is likely the only period in your life that you can literally try anything you like without the real consequences of failure. So have fun, and you can learn something from everything you have tried, as I did from these 20+ projects.
This post is meant for newbies.
Basically, your code should be highly modular, consisting of well-designed classes and functions. Then, unit test each module. This is much easier than trying to debug a large system, or a monolithic piece of code.
I debug almost entirely based on intuition, and never relied on any low level tools like tracers, even when I was a beginner.
For the ray tracing exercise, if you start with the Shirley series, the code should already be modular and incremental. After you finish that, you should have better foundation to design modular code for the ray tracing book by Glassner et al.
Feel free to ask specific questions (e.g. via the comments field of this post), and I will answer by updating and improving this post.
The obsession with paper length is a legacy of printed proceedings.
What matters most is readability.
I would rather spend 1 hour reading a 20-page paper than 2 hours reading a 10-page paper.
Then follows file size: the smaller the better for storage and transmission.
Recently, a student told me that he is not all that motivated for his own first-authored project. And yet he asked to help other projects because he could get extra papers without doing much work.
If I am not sufficiently motivated in a project, I am unlikely to contribute enough to help my team succeed. Even if it does, other team members will remember me as a free rider. I might as well do something else.
Overall, I like to help you as much as possible.
If you are applying for a MS/course program, the reference letters probably are not very important, as the top US schools (to my knowledge) mainly look at your statistics, like GPA, ranking, GRE, etc.
To put it more bluntly, MS program is a source of revenue for them.
For this, all you need is to have obtained top grades in the courses I have taught.
However, I can only comment your specific course performance but not extrapolate, e.g. from basic programming (a class you took with me) to machine learning (a class you did not take with me).
If you are applying for a PhD/research program, you need to have at least some good publications. Any decent professors/researchers know that good grades do not imply good research potential. (I am not aware of any rigorous study, but I think the two are weakly positively correlated at best). Thus, I will write letters only for those who have published top research papers or built good industry products with me, as otherwise the recommendation is likely moot.
When they just arrived they thought it tough to publish at least one first-authored SIGGRAPH paper before graduation.
Now they are hitting the job market and found out that some topic research lab (not to be named but this is no secret) requires at least 5 first-authored SIGGRAPH papers.
Birds of a feather flock together.
Your opinions of others often reflect more of who you are than who they are.
I would like to thank those who (unintentionally) help me filtering away unqualified candidates; you might be even more effective than what the good folks could do.
When I was a PhD student, having 1 SIGGRAPH paper meant graduation, and 2+ for a top research job.
Now, having 1 SIGGRAPH paper meant admission into a top PhD program, 2+ for graduation, and 3+ for a top research job.
(20+ for a tenured professor or partner researcher, but few of you need to worry about this yet.)
Anyone who (still) thinks my standard is too high: feel free talk to Jun Xing, my first HKU advisee, about his current experiences in internship and job hunting.
Hi Jun, Qi, and mamba:
You know what kinds of students I am looking for.
Some of the applicants might contact you about my advising style.
Please help me screen away those who are not suitable (e.g. sharing your painful SIGGRAPH experiences should be a good start).
They trust your words more than mine.
It is to your advantage to be surrounded by top players.
And the fewer students I have, the more time I can spend on each of you.
Nowadays a quick way to filter a job/school application is to see whether and how it says the candidate wants to do machine learning.
(Some neural network probably already existed precisely for this.)
Machine learning by itself is not the problem (quite on the contrary).
The problem is whether you can even form your own independent opinions.
When something (investment, technology, or research field) becomes hot it is already too late to bandwagon.
Those pioneers you see today started (and stuck to) their stuff when it is not yet hot.
Stick with your passion, belief, and opinion might not lead to success, but at least you can have fun, face less competition, and success/fail in your own style.
And if you are smart and creative enough you can have the cake and eat it.
Say your expertise and/or interests are about user interface design. But you also want to do some machine learning like everyone else.
You can switch field, and compete with a lot of smart people who have more passion and knowledge.
Or you can stick with user interfaces, and use machine learning to make them better. You can pick up something new without ditching what you already have.
One common advice on research is to have a coherent theme among our papers. I heard this from a bigwig around 2003 after getting my PhD.
This is one of these advices that I agree in principle but have violated in practice.
Yes, coherence can help recognition from the community, especially when one enters a new field.
However, I am not sure if this should be intentionally aimed for. Unless you are extremely smart and versatile, you are likely end up doing related stuff without even trying.
There is this implicit force that drags us towards similar, and thus incremental, ideas. We should fight against this force, not follow it.
So, just do whatever you like. You will have more fun and more likely to produce novel stuff which, even if lacks coherence, beats being incremental.