Scotty3D is the course skeleton Carnegie Mellon students build a renderer into

A skeleton with assignments, not a finished renderer

Scotty3D is the 3D modeling, rendering and animation package that students complete as part of the 15-462 and 15-662 Computer Graphics course at Carnegie Mellon University. That framing matters more than any feature list. The repository is base code, the assignments/ directory is where the work lives, and the tests/ directory is the grader. A user who expects a turnkey renderer will be disappointed, and a student or instructor expecting a structured course skeleton will find exactly what they need. The project page is the course site at 15462.courses.cs.cmu.edu, and user documentation with example works is published separately at the Scotty3D docs site. The top level layout is the giveaway about how the thing is put together. There is Maekfile.js at the root as the build description, plus src/ for the code, tests/ for the test cases, assignments/ for the coursework, deps/ and media/ for supporting content, and a.gitignore. The project is MIT licensed, and the last push to the repository was on 2026-10-21, with the repository not archived, so the skeleton is refreshed between terms.

The private mirror setup exists so solutions stay private

The most distinctive part of the project documentation is not about graphics at all. It is a warning against making a public fork, because the project does not want solutions to be public, and the instruction is to work in your own private repository instead. The recommended approach is a mirrored private repository with multiple remotes, and the documentation walks through it in detail. Clone Scotty3D normally, create a new empty private repository such as MyScotty3D, and do not initialise it. Then the origin remote of the local clone is pointed at the private copy while a second remote named sourcerepo keeps the public repository. The commands are given as part of the walkthrough:

    - `git clone https://github.com/CMU-Graphics/Scotty3D.git`

        - `git remote rename origin sourcerepo`

        - `git remote add origin https://github.com/your_id/MyScotty3D.git`

        - `git push origin -u main`

The documentation is explicit that the default remote on a clone is named origin, and that you should check with git remote -v to see the current value, which is expected to be the public repository URL. Once the remotes are in place, the update cycle is two commands. When the course staff push new changes to the skeleton, you commit your local work and run git pull sourcerepo main, resolve any conflicts by hand if there are any, and then push the merged result to your private origin with git push origin main. The alternative the project rejects, downloading a zip and merging by hand on every update, is described as a pain, and the point of the remote arrangement is that git handles it.

Building it needs a compiler, node, and prebuilt dependency archives

The general setup has four steps and one of them is a download you should not skip. You install a C++ compiler, Visual Studio 2022 on Windows, the latest XCode on macOS or the latest g++ on Linux. You install node, and the reason given is that the build system is written in command line javascript. You clone the repository. And you download and extract the nest-libs as a child of the repository folder, with separate archives for the three platforms:

  - Linux: https://github.com/15-466/nest-libs/releases/download/v0.10/nest-libs-linux-v0.10.tar.gz
  - MacOS: https://github.com/15-466/nest-libs/releases/download/v0.10/nest-libs-macos-v0.10.tar.gz
  - Windows: https://github.com/15-466/nest-libs/releases/download/v0.10/nest-libs-windows-v0.10.zip

The dependency archives are versioned and pinned to v0.10, which tells you the third party libraries the project expects are fixed rather than resolved at build time. The nest-libs placement matters, they are children of the repository folder rather than installed system wide, which keeps the dependency set per checkout and makes the build reproducible across machines. The build itself is driven by the JavaScript file at the root:

#change to the directory with the repository:
$ cd Scotty3D
#use Maek to build the code:
Scotty3D$ node Maekfile.js
#run the UI:
Scotty3D$ ./Scotty3D
#run the tests:
Scotty3D$ ./Scotty3D --run-tests

Note the build tool's name, Maek, and the fact that the project documentation insists you read Maekfile.js for the available command line options and for how to configure your own build, and states that all the code is nicely documented to help you understand the building process.

The test runner is a filter over the whole test directory

The test harness is simple and worth understanding before you write any assignment code. The --run-tests option runs every test file under the tests directory, and you can narrow the set by giving a substring that the desired test cases include in their test function name. The example given is running the binary with the A0 substring, which runs all test cases whose test function name contains A0. The naming scheme is therefore load bearing rather than decorative, because your filter depends on it. For a student this matters, since the standard way to check that an assignment is done is to run the filtered subset rather than the whole suite. The design also suits the instructor, since the same filtering mechanism can drive a per assignment grading pass. What the harness does not appear to include is a coverage report or a parallel test runner, which for a course sized project is a reasonable simplification. There is a .gitignore at the root and the objs/ and maek-cache.json artefacts referenced in the troubleshooting notes are the build outputs you can delete when a build goes wrong.

Troubleshooting notes that tell you what the environment assumes

The documentation ends with a list of common build issues and their fixes, and the three that are documented are revealing. On macOS, an unknown warning option for unused but set variables appears when your Clang is older than 13.0.0, since the flag was introduced in Clang 13, and the fix is to check that your macOS version is Monterey or above, upgrade Xcode to at least version 13.0, set the Command Line Tools location in the Xcode preferences to your latest Xcode version, and verify with clang -v in the terminal. The last resort, if the error persists, is to go into Maekfile.js and comment out the line where the flag is located, with the project noting that the flag was included because it is beneficial to learning and omitting it may cause a build failure on other computers. On Linux, a linker error about not finding the sound library means a package is missing, and the fix is to install it with apt-get install libasound2-dev. On Windows, a library machine type conflict between x64 and x86 usually means the build is being run from a shell whose developer tools target x86. The general advice for any remaining problem is to delete objs/ and maek-cache.json and rebuild with node Maekfile.js.

Why this codebase is not a general rendering library

The limitation is the same as the strength, and stating it plainly avoids a wrong adoption. Scotty3D exists to be completed, so a checkout with the assignments untouched is not a working renderer, and the value of the repository is in the structure of the work rather than in the code you can call today. The C++ code is there as a starting point with documented build process, the tests are there to be made to pass, and the assignments directory is there to be worked through. The audience is therefore a specific pair, students on the 15-462 or 15-662 sequence and the instructors who assign it. The mirror setup makes the intended usage even clearer, because the course staff push changes to the skeleton and expect students to pull them in. A second constraint follows from the dependency arrangement. The nest-libs archives are pinned to v0.10 and are expected as children of the repository folder, so the project is not designed to consume a system wide library set, and a deployment that needs a different third party configuration will be modifying the build rather than configuring it. The alternative approaches differ in kind here rather than in features. A general purpose rendering library gives you a working engine and none of the course structure, and a from scratch implementation gives you the same learning and none of the harness, tests and build system that the coursework assumes. For anything outside the course, the honest answer is that this repository is the wrong shape of tool.

Editorial conclusion

Adopt Scotty3D if you are taking or teaching a graphics course built on the Carnegie Mellon 15-462 and 15-662 sequence, because the assignments, the build and the test harness all assume this exact skeleton. Do not adopt it as a general purpose rendering library, since the assignment structure is the point and the codebase is deliberately incomplete. Before you start, set up the private mirrored repository rather than forking publicly, because the project asks that solutions not be published, and read Maekfile.js before you change any build option.

Frequently asked questions

Official sources

1. CMU-Graphics/Scotty3D on GitHub
2. Issues
3. License: MIT
4. Project website
5. README