About

Nori 2 is a minimalistic ray tracer written in C++. It runs on Windows, Linux, and Mac OS and provides a foundation for the homework assignments in the course Computer Graphics taught at ETH Zürich.

While Nori provides much support code to simplify your development work as much as possible, the code that you will initially receive from us does very little: it loads a scene and saves a rendered image as an OpenEXR image—but the actual rendering code is missing, hence the output image just consists of black pixels. Your task will be to extend this system to a full-fledged physically-based renderer as part of programming assignments and your final project.

Core features

The Nori base code provides many features that would be tedious to implement from scratch. The following are included:
  • A simple GUI to watch images as they render
  • An XML-based scene file loader
  • Basic point/vector/normal/ray/bounding box classes
  • A pseudorandom number generator (PCG32)
  • Support for saving output as OpenEXR files
  • A loader for Wavefront OBJ files
  • An optimized bounding volume hierarchy builder
  • Ray-triangle intersection
  • Code for multi-threaded rendering
  • Image reconstruction filters
  • Statistical \(\chi^2\)- and \(t\)-tests to verify sampling code

Guidelines

Permissible sources of information

Feel free to consult additional references when completing projects, but remember cite them in your writeup.

When asked to implement feature \(X\), we request that you don't go and read the source code of the implementation of \(X\) in some other renderer, because you will likely not learn much in the process. The PBRT book is excluded from this rule. If in doubt, get in touch with the course staff.

References

You may find the following general references useful:

  • "Physically Based Rendering, Third Edition: From Theory To Implementation" by Matt Pharr, Wenzel Jakob and Greg Humphreys. Available Online, October 2018.
  • "Advanced Global Illumination" by Philip Dutré, Philippe Bekaert, and Kavita Bala. AK Peters, 2nd edition, August 2006.
  • "Robust Monte Carlo Methods for Light Transport Simulation ", PhD Thesis by Eric Veach, Stanford University, December 1997.

Instructions

The assignments have to be solved and submitted individually. The final project will be done in groups. More information about the final project and the rendering competition will come later in the semester. The deadlines are specified for each assignment. These are the dates to submit your exercises (code and report). The gradings are done until one week later to give us time to look at your reports. To get graded you need to submit on time.

The goal of these exercises is to help you create the foundation of a good renderer for subsequent assignments and the final projects. It is your job to convince us that you have implemented the assignments correctly, through the information provided in your reports and the quality/readability of your code. We will deduct points for poorly written code or inconclusive comparisons/validations in your report. Make sure to start working on the homework as early as possible. Building your own advanced renderer is a lot of fun. Use this great opportunity, and don’t forget to have fun!

Submissions

We will be using Moodle to gather your submissions. Every time there is something to submit, we provide you with a link to the assigment submission. Make sure to zip the submission files! There is a limit of 20MB per submission.

  • Include all source files, or instructions how to obtain them, that are necessary to compile your solution, except for the provided external dependencies (i.e nori/ext)
  • Include only ONE copy of the code and report
  • Name your submission file {familyname}-{firstname}.zip
  • Do not nest ZIP files
  • For each of the tasks, provide a list of files that were modified to implement the feature

Late policy

Please submit your report on time and follow the respective instructions.
Late submissions can be accepted and graded without penalties only for valid reasons (e.g. military service or hospitalization) with written proof prior to the deadline.
Otherwise, the submission will be graded with penalties. More specifically, we multiply the grades with a scale factor that depends on the submission time.

The submission time is defined as the time point when the last submission is made on Moodle. The scale factor is defined as follows, depending on how long the submission is overdue.

  • Less than 1h: 100% (no penalty)
  • 1h - 6h: 90%
  • 6h - 12h: 80%
  • 12h - 24h: 60%
  • 24h - 36h: 40%
  • 36h - 48h: 20%
  • More than 48h: 0% (the submission is likely not graded)