Visualization research opportunities are always available! The process we typically follow at the lab requires first producing a proposal for a project that would interest you. Look for ideas on the iVRL lab site; for ongoing projects, make sure their status is 'Active' and not 'Completed'; although if you have specific ideas about extending a completed project, that's also an option; and also check out potential projects here: project ideas; or tell me a bit about your background and interests and I might suggest a project. You might have an idea for a project that's not listed on either selection. That's fine also, but in general, keep in mind that the project area needs to match my own interests, or, to quote my wise alma mater advisor, "I won't be able to be an effective advisor on it" :-).
Then, put together a preliminary semester research proposal/plan (see 2. How do I write a semester research plan/proposal? below.)
When you have some thoughts on your goals and some ideas for projects, come talk to me. We'll likely converge on something that we both find exciting.
Here's what I expect to see in a semester research plan:
0) Your name, some title, and the semester you plan to do the research in.
1) Your goals for a project and for the semester. Initially, your goals will probably be unrelated to a specific research project. They might include things like "find out what it's like to work in the vis lab," "put my classroom math skills to work on a research project," "figure out if ____ research is something I want to do," or "combine astronomy and visualization somehow." As you develop the proposal, these goals will refine and likely become more specific. You'll also add some more research-related ones (e.g, "Design, implement and test a sub-voxel accurate algorithm for tracking bone motion from CT and X-ray images".)
2) A research project or area to work on. In general, this needs to align with my own interests. The exact project might be vague in the beginning of the term, but should become clearer after a few weeks.
3) A work plan that describes the things that you will do to address your goals and the research problem/area.
4) A schedule, with concrete, quantifiable milestones every 1-2 weeks. Such a milestone might be "finish first draft of the related work section of final report." In contrast, an item such as "read some papers" is not a milestone and is not particularly concrete (although "read two papers a week" might make it quantifiable.)
At the end of the term we will look back together at the proposal and determine what worked and what didn't in the context of your goals.
The proposal is usually about 2 pages long -- short and pithy preferred :-). Expect to iterate on it a few times before we're both happy with it.
There are lots of books and articles out there about the nuts and bolts of scientific writing. If I were allowed to keep only one book, it would be Mimi Zeiger's "Essentials of writing biomedical research papers" ISBN 0-07-134544-2. Don't let "biomedical" mislead you: it's just as relevant to computer science research. Let's say it's the only book I've seen to explain the structure of a Discussion section, or what should go into an Abstract.
There's two more books I keep handy: Miller, Dowrick, and Swift's "Handbook of Non-Sexist Writing for Writers, Editors, and Speakers" and Lyn Dupre's "Bugs in Writing: A Guide to Debugging Your Prose".
Pitt offers several classes on composition and creative writing. You
can look them up on the
English Department's homepage
under Writing, or at the Registrar's under ENGCMP-English Composition
and ENGWRT-English Writing. You might want to read the course
description and contact the instructor first, to make sure the course
syllabus will meet your expectations.
Pitt runs a Writing Center staffed by experienced consultants who have been trained to help others with their writing. They will help students learn to identify their patterns of error and correct them on their own, but if you'd rather figure out first the principles of scientific writing, see the resources above.
The Sheridan Center for Teaching at Brown University has published an excellent booklet on Persuasive Communication (go on, read it; it lays out the basic organization of a talk, among other things).
John Hughes gives a set of excellent presentation tips; check out the section on thesis proposal talks as opposed to thesis defenses. I can't find it on is webpage, but he said on multiple occasions that talks should start with a teaser (a glimpse at what we'll know by the end of the talk); here's a more formal version (with Simon L Peyton Jones and John Launchbury): How to give a good research talk.
John Pinto of Stanford University lists a few Do's and Don'ts for Brief Research Talks (from Gordon H. Bower). You may agree or not with Bower's observations; they're still interesting.
I like these two sources on effective poster presentations:
Dina Mandoli's How to make a great poster (what is a great poster, how do you make a poster, how to plan poster organization etc.) and
Kathryn Tosney's How to create a poster that graphically communicates your message, with many positive and negative graphical examples.
The most sensible thing to do is print a real-size draft of your poster (A4 sheets taped together), put it up on a lobby wall with a stack of post-it-notes and pencils next to it, and ask your friends to mark their comments directly on the poster draft.
A 'technical review' is a review we do for a conference or a journal. In many ways, a technical review is more challenging than the paper reviews we write routinely for class. First, remember to begin your review with a one or two sentence summary of the paper (conference chairs and journal editors *will* sometimes mistakenly send your comments to the wrong authors; the summary helps disambiguate such situations). Second, the tone of your review is very important. Third, as a colleague, you can (and should) help the authors improve their work. Below follows Greg Turk's excellent advice on writing technical reviews.
Writing Technical Reviews
In many professions, people give back to their community by doing volunteer work. In technical fields such as computer science, we volunteer our time by reviewing papers that are written by other researchers in our field. I recommend that you approach your reviews in this spirit of volunteerism. Sure, your reviews make you a gatekeeper in helping decide which papers are ready for publication. Just as important, however, is to provide feedback to the authors so that they may improve their work. Try to write your review in a way that the authors can benefit from your review.
I like reading a paper and then thinking about it over the course of several days before I write my review. "Living" with a paper for a few days gives you time to make thoughtful decisions about it. This is the best way to come up with helpful suggestions for improving the paper. To do this, you need to carve out some time in your day to think about the paper that you are reviewing.
The tone of your review is important. A harshly written review will be disregarded by the authors, regardless of whether your criticisms are true. If you take care, it is always possible to word your review diplomatically while staying true to your thoughts about the paper. Put yourself in the mindset of writing to someone you wish to help, such as a respected colleague who wants your opinion on a concept or a project.
Here are some specific issues to keep in mind as you write your reviews:
* Short reviews are unhelpful to the authors and to other reviewers. If you have agreed to review a paper, you should take enough time to write a thoughtful and detailed review.
* Be specific when you suggest that the writing needs to be improved. If there is a particular section that is unclear, point it out and give suggestions for how it can be clarified.
* Don't give away your identity by asking the authors to cite several of your own papers.
* If you don't think the paper is right for [...this particular venue], suggest other publication possibilities (journals, conferences, workshops) that would be a better match for the paper.
* Avoid referring to the authors by using the phrase "you" or "the authors." These phrases should be replaced by "the paper." Directly talking about the authors can be perceived as being confrontational, even though you do not mean it this way.
* Be generous about giving the authors new ideas for how they can improve their work. Your suggestions may be very specific (for example, "this numerical solver would be better for your application") or may be more general in nature. You might suggest a new dataset that could be tried, or a new application area that might benefit from their tool. You may tell them how their idea can be generalized beyond what they have already considered.
A thoughtful review not only benefits the authors, but may well
benefit you, too. Remember that your reviews are read by other
reviewers, including several who know your identity. Being a helpful
reviewer will generate good will toward you in the research
Greg Turk, March 2008
We are going to assume here that you have covered at Pitt or elsewhere the material we cover in CS1566 Introduction to Graphics. The next steps are CS2620 Interdisciplinary Modeling and Visualization and CS3610 Advanced Topics in Computer Graphics (you can take either cs2620 or cs3610 first, they're not a sequence). There are more graphics classes at CMU that you can register for, see: http://graphics.cs.cmu.edu/courses/ . I think Physically-based Computer Animation is a good choice.
Outside of class, short-term, you can play a bit with the advanced features of OpenGL -- topics like volume rendering, animated textures, constructive solid geometry etc. Here's the tutorial examples I'd recommend: Siggraph 1997 OpenGL Advanced Rendering examples, and the corresponding notes.
In terms of physically-based animation, check out the Baraff and Witkin online course and slides on Physically Based Modeling (SIGGRAPH 2001) -- see also the older version Physically-Based Modeling: Principles and Practice (SIGGRAPH 1997).
The ACM SIGGRAPH and IEEE Visualization proceedings are available locally, come talk to me if you're interested.
That's a tough one. I like this short chapter on time management from "Making the Right Moves" by the Howard Hughes Medical Institute and the Burroughs Wellcome Fund: Ch6: Time Management. Then, check out Randy Pausch's lecture on time management (good investment of 1 hour and 15 minutes of your time). Then, if it turns out your problem is procrastination rather than less-than-stellar time management, I highly recommend Kate Lorenz's tips: Procrastination: Work's Silent Killer (the original link seems to be gone). The NIH Chapter on time management is short and to the point. Randy Paush's video talk is a bit long, but it gets very relevant around minute 20 ("eat the ugliest frog first") and stays so through the end. The procrastination list is both an excellent diagnostic tool ("are you a dreamer or a dreader?") and an awesome collection of advice. Hope this helps!