2017 March 3,

CS 311: Project

Introduction

The last part of our course consists of student projects. Some projects add major new features to our current graphics engine, while other projects explore entirely different algorithms for rendering. Here are some rules.

  1. You have about three weeks to work on the project. In three regular weeks of this course, we would undertake nine regular assignments, collected at three benchmarks. Your work during the project period should reflect a similar amount of effort.
  2. You are expected to work with one (and only one) partner. If you strongly prefer to work alone, then you may. However, your solo project is expected to achieve a similar level of difficulty and accomplishment as a pair project. If you want me to suggest a partner for you, then ask me.
  3. This is a computer science project, not an art project. I understand wanting to make decent models and textures, to improve the appearance of an application. But do not spend more than, say, 25% of your time on artwork.
  4. We frequently spend class meetings on project work. During these meetings, check in with me and explain your progress.
  5. In the last two days of class, students give 5-minute progress reports to the class. Your project does not have to be complete at that time, but you need to convey its key ideas and difficulties to your classmates.
  6. Your project is due Wednesday 2017 March 15 at 5:00 PM, which is the end of the last day of final exams.

Suggested topics

You may choose a topic other than these, but it should be comparable to these, and I must approve it.

Cubic splines, typefaces, their rasterization

In this course we have rasterized only one kind of 2D primitive: triangles. But in 2D graphics a wide variety of primitives are used. For example, typography (the drawing of characters) is frequently expressed in terms of cubic splines, which describe curves much more efficiently than triangles ever could.

Study the algorithms and data structures of splines and font technology. Write a fast rasterizer for cubic splines. Write an interactive spline visualizer, so that your classmates can learn how splines work.

Voxels and volume rendering

Just as pixels are squares in a 2D raster image, so voxels are cubes in a 3D raster image. Voxels are used to represent complicated 3D data sets, such as medical imaging of the human body. Voxels are rendered using volume rendering and other techniques, some of which are quite different from triangle rasterization.

Study the theory of voxel data and their rendering. Implement a renderer using some technique compatible with common hardware. Explain why this approach might out-perform rasterization of triangle meshes in some applications.

Physics engines

In computer games and simulations, physics is a catch-all category for tasks such as collision detection, computing ricochets, computing how bodies fall under gravity, etc. When multiple bodies are linked together — for example, limbs in a human figures — the computations can become quite difficult.

Study the theory of such dynamical calculations. Learn a free physics package such as Open Dynamics Engine. Integrate it into our graphics engine, explaining how it changes our notion of scene graph. (Some training in physics is helpful for this project.)

Non-basic scene graphs

The scene graphs used in our course are rigid and basic. Each node consists of a rotation, translation, mesh, and the uniforms and textures needed to render that mesh. But real-world scene graphs are much more varied and flexible.

Study common approaches to scene graphs. Replace our scene graph system with a more flexible and feature-rich one. (But if you find yourself doing physics on the scene graph, then you are not doing this project, but rather the "Physics engines" project.)

Ray tracing

Ray tracing is a 3D rendering technique that is quite different from triangle rasterization — much slower and much higher-quality.

Study the theory of ray tracing, including its algorithms, data structures, and time complexity. Illustrate the theory in either code (your own basic, slow ray tracer) or a detailed paper (with images made by free ray-tracing software such as POV-Ray).

Constructive solid geometry

Constructive solid geometry is a way of describing solids, not as boundary surfaces made of triangles, but as unions, intersections, and complements of simple primitive solids. For some applications, this approach provides a convenient and efficient way of representing complicated shapes.

Study the algorithms and data structures used in constructive solid geometry. Illustrate the theory in either code (your own modeler) or a detailed paper (with images made by other people's constructive solid geometry software).

Geometry and tesselation shaders

Because of the switch from the fixed-function rendering pipeline to shaders, OpenGL 2.0 is a more significant upgrade to OpenGL than are OpenGL 3.0 or 4.0. However, 3.0 and 4.0 do add various new features, including two new kinds of shader: geometry and tesselation.

Study the theory, implementation, and application of these shaders. Demonstrate your insights using OpenGL, and add a geometry shader to our software engine.

Vulkan

Vulkan is as fundamental a revision to OpenGL as was OpenGL 2.0. It provides a much lower-level API than previous versions of OpenGL. The user carries much more responsibility for managing the hardware.

Study the motivation, design, and application of Vulkan. Write tutorials, from which your classmates can learn Vulkan. (Background in computer organization, operating systems, and C++ is helpful for this project.)

Outroduction

Depending on the specific nature of your project, its products may take many forms: a paper or readme files (PDF, plain text), source code (C, scripts), executable files, videos, etc. Do not give me any Microsoft Word files or any links to files "in the cloud". Except for executables, I should be able to use any of your files, on any mainstream computer, ten years from now, without an Internet connection.

You should probably have a readme file, giving an overview of your project and its file organization. Your readme file is your chance to "frame" the project before I grade it. You don't want me to misunderstand your project. If your products include a paper, then part of the paper could serve this purpose.

You must not pass off someone else's work as your own. For example, if your project makes heavy use of mimicking other people's examples, then your readme should mention where you found those examples.

Your project will be graded on a macOS machine similar to the lab machines. If your project requires special software, which may or may not be installed on the grading machine, then you should include instructions for installing that software. You should also include a video or some other documentation of what your project does, which I can view if I can't install the software.

Your products should demonstrate that you understand the project. If your project involves writing lots of source code, then that is probably your demonstration. If your project involves using someone else's software, then perhaps you should write a paper explaining how that software works. A project that amounts to "We used X software, and we gave it input Y, and it made an image like Z" is not a good project. This is a CS course, not an art course.

One student submits the project to a clearly marked folder in the handin folder on the COURSES file server. Include all files needed (except for third-party software — for that instead give installation instructions).

In non-solo projects, each student also sends me a brief e-mail, without CCing the teammate. The e-mail gives the student's evaluation of how the work was divided. In addition to listing who did which tasks, the e-mail gives a numeric proportion such as "Overall, I did 60% of the work and she did 40%." The numeric proportion is not allowed to be 50%-50%; it must break the symmetry one way or the other. Your project is not considered submitted until I receive both e-mails.