**Graphics Programming Projects** by Morgan McGuire Introduction ========================================================================= The best way to learn 3D computational graphics is to combine a good textbook with hands-on programming projects. The projects on this page are designed to accompany the [_Graphics Codex_](http://graphicscodex.com), the interactive and comprehensive graphics book that costs US$10. I designed these projects based on experience teaching graphics at Williams College, Brown, and MIT. They work equally well in a formal college course as assignments and for self learning. These projects teach a number of different 3D graphics skills: - Physically-based, photorealistic rendering ![
[Cloud Ten](https://www.shadertoy.com/view/XtS3DD) ©2015 NMZ
](cloud10.jpg width=300 border=1) - Monte Carlo ray tracing - Computational solid geometry - Procedural 3D modeling - GPU real-time rendering - Game engine programming They also teach some software engineering skills: - Program design - C++ programming - Version control - High-performance CPU and GPU programming If you already have experience with some of these topics, then you can of course skip that material. I assume that you already know calculus, how to program well in some language, and common computer science data structures and algorithms. The readings and projects will teach you the rest of the math and computer science needed as you progress. Projects ========================================================================= The projects are linked below. In the spirit of the _Graphics Codex_ and open source, I'm making them available as I create them and will update these based on reader feedback. New GPU-based projects will continue to appear through March 2017. [Cubes](../cubes/index.html)
:
Learn the development framework, 3D coordinate systems, and scene format, and then make your own scene.
_50 lines, 5 hours_ [Meshes](../meshes/index.html)
:
Generate new 3D models as indexed triangle meshes for mathematical shapes, glasses, and procedural terrain.
_100 lines, 5 hours_ [Geometry Design](../geo-design/index.html)
:
Design-intensive exercise to extend Meshes to voxels, L-systems, terrain, model instancing, or hex-grid planets.
_250 lines, 20 hours_ [Rays](../rays/index.html)
:
Implement your own renderer with ray intersection, primary and shadow rays, materials, and direct light.
_100 lines, 11 hours_ [Paths](../paths/index.html)
:
Write a photorealistic path tracer with Monte Carlo integration, importance sampling, and high-throughput CPU programming.
_100 lines, 9 hours_ [Renderer Design](../render-design/index.html)
:
Extend Paths with participating media, depth of field, motion blur, chromatic abberation, adaptive sampling, or your own BVH.
_100-300 lines, 20 hours_ [GPU](../gpu/index.html)
:
Write a _real-time_ GPU ray tracer in GLSL using sphere tracing, signed-distance functions, and computational solid geometry.
_65 lines, 6 hours_ _Coming soon:_ Isosurfaces : Marching cubes, isosurfaces, splines, L-systems, emergent systems Advanced Modeling : Noise, fluids, errosion, subdivision surfaces, voxels Hardware APIs : Rasterization, vertex buffers, pixel and vertex shaders Deferred Shading : Direct evaluation of microfacet models, shadow maps, particle systems Interaction : Collision detection and response, physics integration, decals, gameplay, UI "Lines" of code refers to statements in the main implementation file (≈ semicolon count), ignoring relatively boilerplate GUI and header code and code imported from a previous project. Time estimates are in person hours based on averages from 140 college students. Projects longer than 6 hours could be done by pairs or small teams, or by an individual over multiple weeks. Some projects also must be run for significant unattended time to produce results. The "Design" projects are capstone projects for individual topics. They emphasize designing the structure of your own solution to a problem and can be completed my an individual over a month or by a small team in two or more weeks. Each project describes its own dependencies on other projects and reading chapters. They are designed to work well in the order listed, but there's a lot of freedom to jump around. Platform and Support Code ========================================================================= The [Recommended Tools](../tools/) document explains how to set up a development environment for these projects. The projects provide explicit implementation advice for *C++* 11, [*OpenGL*](https://www.opengl.org/) 4.1, *GLSL* 410 and [*G3D*](https://g3d.cs.williams.edu) 10 (or later versions). Because it combines good development tools and OpenGL drivers, I also recommend [*Microsoft Visual Studio*](https://www.visualstudio.com/en-us/products/free-developer-offers-vs.aspx) 2015 on *Windows* 10. Graphics developers should use discrete GPUs instead of the embedded Intel ones in low-end laptops. I use [*NVIDIA GeForce*](http://amzn.to/2anp4dj) 960 GPUs in my course. Those give the best ratio of performance to cost for a full-featured GPUs with stable drivers, but I test the projects regularly on a wide range of GPUs from many vendors, including the AMD mobile GPU in the current Macbook Pro. However, these projects can be completed using any programming language, operating system, support code, and GPU. Those include Java, Linux, DirectX, WebGL, Mitsuba, and three.js. The largest challenges in using another framework are replacing G3D's model loader and fast, multithreaded bounding volume hierarchy. The primary support code for the projects is the open source [G3D Innovation Engine](https://g3d.cs.williams.edu) for Windows, Linux, and OS X. Its built-in 3D math, modeling, rendering, and GUI features are similar to those in game engines. But unlike a game engine, G3D allows you to easily override all aspects of the pipeline and provides extensive support for debugging your own program. Nobody implements high-level graphics directly on OpenGL, Vulkan, Metal, or DirectX today. Those APIs change frequently and vary too much across GPUs. G3D abstracts the GPU and OS windowing API while still teaching you how they work. Dependencies ===================================================================== The projects work well in the order listed above, but need not be completed in that order. The graph below shows the possible paths to each project based on their dependencies. The gray rectangles are design projects. I teach all of these project in my courses, but only assign half of them per semester. ![](http://g.gravizo.com/g? digraph G { node [width=1.5]; { Geometry [shape=box,style=filled]; Renderer [shape=box,style=filled]; Modeling [shape=box,style=filled]; Game [shape=box,style=filled]; } Cubes -> Meshes; Meshes -> Geometry; Cubes -> Rays; Rays -> Paths; Paths -> Renderer; Rays -> GPU; Meshes -> Isosurfaces; GPU -> Isosurfaces; Isosurfaces -> Modeling; GPU -> Rasterization; Rasterization -> Deferred; Rasterization -> Interaction; Meshes -> Interaction; Interaction -> Game; Interaction -> VirtualReality; {rank=same; Rasterization Modeling} {rank=same; Meshes Rays} } )