Confessions of a researchaholic

July 27, 2017


Filed under: Real — liyiwei @ 9:06 am
Tags: ,

Looking at the paper titles for HPG 2017, I wonder if it can be renamed to HPRT (similar to how CVPR can be renamed to CVML).

When we have real-time ray tracing on mobile devices (the day will come), all the legacy graphics algorithms (i.e. tricks) will become obsolete.
I believe real-time RT, instead of machine learning, will be the end of traditional rendering tricks.

April 10, 2017

Open source texture synthesis

Filed under: Real — liyiwei @ 6:00 pm
Tags: , , ,

Well I guess this is long overdue; knock yourself out here.

Open source facilitates collaboration and code reuse, and propels our progress forward. I shall participate more in the future.

April 5, 2015

Furious 7

Filed under: Real — liyiwei @ 10:40 am
Tags: ,

They actually parachuted the cars for real instead of CG 🙂

October 13, 2014

How to make a SIGGRAPH paper

Filed under: Real — liyiwei @ 11:08 pm
Tags: , ,

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 31, 2012

How to design demos

Filed under: Real — liyiwei @ 9:51 pm
Tags: , , , ,

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.

March 26, 2012

Another data point

Filed under: Real — liyiwei @ 1:49 am
Tags: , , ,

In responding to my earlier post, a very talented graphics researcher has shared with me his statistics, as shown below.

As you can see, his has much better success rate than me, especially considering that he has been doing rendering, a tough field for SIGGRAPH. 🙂

November 20, 2011

Ray tracing

Filed under: Real — liyiwei @ 6:43 pm
Tags: , ,

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.


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.)


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.


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.

September 17, 2011

Producing research results

Filed under: Real — liyiwei @ 4:06 pm
Tags: , , ,

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.)

December 20, 2010

How to use the papers committee list

Filed under: Real — liyiwei @ 11:49 am
Tags: , , ,

SIGGRAPH now publishes the technical papers committee list a few weeks prior to the submission deadline. Here is my suggestion on how to take this information to your advantage.

First, let me tell you what NOT to do. It is very common for people to try to guess who is likely to review your papers, but this is entirely useless and counterproductive. In general, there is indeed a positive correlation between the committee member expertise and your paper subject, but it is not a very strong correlation and there is a non-trivial chance that a paper will be assigned to an unexpected committee member. (This is mainly due to how the paper sorting and assignment process goes but I am not going to elaborate on this here because I do not think it is necessary for authoring a good paper.)

So my personal strategy is to make sure the paper will survive *any* committee member. This is the safest bet and you cannot go wrong with that. (But do check the committee member list constantly though as sometimes it may change prior to the deadline.) Specifically, you should write your paper (especially the title and abstract) in a way so that it is as clear as possible on what it is all about to minimize the chance of misunderstanding. (If the paper sorters misunderstand your paper, they are more likely to assign your paper to the wrong committee member. And if the senior reviewers misunderstand your paper, they are more likely to assign your paper to the wrong tertiaries. And if reviewers misunderstand your paper they are more likely to score it lowly.)

It also helps to read and cite papers from the committee members for two reasons. The first reason is that the background and expertise of a committee member will obviously have a huge influence on how she is going to review a paper, so if you understand her, you stand a better chance of appreciating how she might approach a paper. The second reason is that psychological studies indicate that it is almost never too much to flatter, and people are usually happy to see their own papers cited and attributed in a positive manner.

If you want to push this further, my personal philosophy is to assume that my paper will be reviewed by the worst possible reviewers and prepare for that. Like Andy Grove said, only the paranoid survive.

November 6, 2010

Looking for intern: somatic computing in MSR SF

Filed under: Real — liyiwei @ 10:52 am
Tags: , , ,

Jaron Lanier and I recently started a new project termed “somatic computing” in Microsoft Research San Francisco. We are looking for an intern who would be interested in working with us. For more information, please take a look at our project page.

Next Page »

Theme: Rubric. Get a free blog at