Final Report
Real-Time Non-Photorealistic Architectural Rendering

Introduction
An architect designing a bulding or building complex uses several methods to try and convey his concept to others. Two commonly used methods are building a small scale model and making architectural drawings. A model allows people to see the design from a 3D perspective. Drawings can convey information that is hard to demonstrate with a model alone, such as mood. They also make it easier to envision what the building would look like with different materials or objects. Today 3D computer animated walkthroughs combine the two perspectives. However, most current systems aim towards photorealism. While this approach works well for existing places, it is less than ideal for portraying a design in progress. A photorealistic environment leaves little room in the viewer's mind for seeing the possibilities that lie within a design. Non-photorealism solves this problem by making things seem less concrete, more flexible. In addition, the major features of the design can be emphasized, while the less important details fade into the background.

The goal of our project is to simulate the feel of architectural drawings in a real-time immersive environment. Using a non-photorealistic style is one key factor in attaining that goal. The other main ingredient is using entourage. Entourage is defined as one's environment or surroundings. A building's surroundings - the people, plants, animals, and objects around it - are what give the building a sense of life and scale. Architects routinely use entourage in their drawings to give the building a certain purpose and feel. Combining non-photorealism and entourage allows us to meet our goal. The Olympic Village on the University of Utah campus was chosen as the area of focus for this project.

Entourage: My Work
My part in this project was to create the entourage by making animations to be placed in the Olympic Village environment. The first thing I did was to figure out what kind of people should go into the scene and what they should be doing. Since it is the Olympic Vilage, I decided to put athletic looking people in there. Originally I had planned to give the people props like skis and gym bags. However, these props did not already exist in the program, they were not easy to create myself, and I could not find them on the internet. So I had to give up on that idea. As for what the people should be doing, I decided on normal everyday activities like walking and talking. The Olympic Village is where the athletes stay when they are not out and about, so I figured they would not be out skiing and ice skating on the sidewalks!

The next thing I did was to create the animations and some still images. For accomplishing this task, I used a figure animation software named Poser. During this stage of the project, I learned about keyframe animation. While making the animations, I made several preliminary movies to make sure that the characters' motions looked natural. For the most part, the controls for each body part were easy to use. There were some special cases where they became difficult, though. For example, in one of my still images a woman is supposed to be crossing her arms. This simple task in real life is nearly impossible to model in Poser, because at certain joint angles the controls start moving the body parts in unintuitive and unresponsive ways. Two special considerations that I had to adhere to when making my animations are that my animations will loop in the finished project and that my animations must not distract from the architecture, which is the main feature of the project. For both of these reasons I had make sure that the character movements were not so large as to be obvious, yet not so small as to become invisible.

Once my animations and still images were done, I had to decide where to place them. I used a layout of the scene created previously to note where the people should go. Then I decided where the main light source, the sun, would be coming from. After that I had to go back and fix the lighting on my characters to adhere with their orientations and the position of the sun in the scene. After all that was done, I was able to output the final animations.

Importing Animation: My Other Work
While the animations were created in Poser, the actual walkthrough of the village is done using a program called World Tool Kit (WTK). Thus we were faced with the problem of getting the animations from Poser to WTK. Some work had already been done with importing animations as a series of 2D images. I set about investigating whether we could import the animations as 3D. The obvious advantage of keeping the animations three dimensional is that the viewer can see them from any angle, near or far, and the perspective will be correct. With the two dimensional animations, which are created by projecting a series of images frame by frame onto a polygon, if the viewer walks to the side of the polygon, the animation will look very thin and strange because it is being seen from an angle.

From the beginning, the main problem with using 3D animation was memory. The people in Poser are made up of tens of thousands of polygons. To use any 3D animation method in WTK, the geometry of the figures would have to be simplified immensely. Most of my time investigating the animation problem was spent trying to find a suitable simplification algorithm for my figures. Though an abundance of research has been done on mesh simplification, there are very few readily available algorithms. In fact I found only one, and it did not accept the file format we were using. In the end I had to give up and concede that importing 2D animations would work best for our project. In any case, we hope to avoid the problem mentioned above by keeping the animations away from the viewer.

My final contribution to the project was to write a program that makes it easier to import 2D animations into WTK. Creating an environment with WTK requires some programming. Since our project has multiple animations, I decided it would be nice to have some predefined functions for the task. So I wrote functions to load the animation, switch frames, and delete the animation. It took a long time because I had to deal with pointers and dynamic memory allocation in C. When it was done I made it into a header file. Then I tested all of the functions out in a sample program, and they work beautifully.

What's Left
The bulk of remaining work consists of integrating the various parts of the project. A preliminary version of the Olympic Village scene already exists. My animations must be imported into the scene. Then the whole thing must be rendered in a non-photorealistic style. This non-photorealistic rendering is what will take the most time for the rest of the project. The other people on the project have been working on various non-photorealistic styles. Integrating and implementing these styles while making sure they exhibit temporal coherence is one of the challenges they face in completing the project.

What I Learned
I learned a great deal this summer. Before coming here, I knew very little about computer graphics other than I was interested in it. Now I know about some things like Bezier curves, B-splines (and non-uniform rational B-splines, or NURBS), vertex normals, various types of shading, and more. Some of these things I learned while working on my project. Others I learned by reading research papers or looking them up so I could understand a research paper. Reading research papers was interesting. Some of them were easy to understand, some took a little work, and some were just beyond me. It is fascinating to see all the areas of research that are being investigated. It is also interesting how many variations along the same line of work there are. Some of the papers I read this summer are as follows:

Computer Modelling of Fallen Snow
Out-of-Core Simplification of Large Polygonal Models
Surface Simplification Using Quadric Error Metrics
Real-Time Hatching

Aside from concrete computer graphics knowledge, I also learned some things about research and graduate school. I learned that you have to be self-motivated. When you are doing research, there are deadlines, but they are not the kind where someone is standing over your shoulder telling you, "You have to have this done by this date, and that done by that date." Sometimes deadlines are not defined for you, and you have to set your own. Then you have to make sure that you adhere to them. I learned that it helps to ask questions a lot. If the people in your lab are helpful, it is a big plus. Or if you read a research paper and you don't understand a part of it, you can e-mail the author, and they are usually helpful, too. I learned that research can be hard and frustrating. It can be hard to find background work on what you're you're doing, especially if what you are doing is new. Also, even though your research may build on or use what others have already done, it can be hard to find that work to use in your program. Then you just have to code everything from scratch. That being said, I learned that if you go into research in computer graphics then your programming skills will get plenty of use. When you get a part of your project done, though, it feels really good. Especially when it is a part that has been giving you trouble for a while. Finally, I learned that it feels good to be a part of a team. To feel like you are actually contributing to something significant. That is a good feeling.

Acknowledgements
I would like to thank all of the people in the lab who helped me have a successful research experience this summer. Without you all I would never have learned as much or accomplished as much as I did. Thanks for putting up with my incessant questions, and answering them so that I could understand. I would like to thank, in no particular order:
Dr. Elaine Cohen
Bruce
Amy
Shaun
Kristi
Bill
Mark
Rose
anyone else I may have forgotten, but still appreciate very much