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 to 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 can be done in groups of two.
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).
To get graded you need to submit on time according to the late policy.
We aim to complete grading until one week after the deadline.
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!
Use of AI tools in this Course:
AI tools are allowed for the programming assignments and the final project. They are not permitted during the interim or session examinations, where no aids of any kind are allowed.
-
Take responsibility for your code. Everything you hand in is yours to explain and to stand behind. "The agent wrote it" is not an acceptable answer, not for a question regarding a bug, a failed test, or explaining your submitted code. Implementing the algorithms and concepts taught in the lectures is essential to understanding them. AI tools can help you understand them, but they can just as easily do the opposite: code that just appears and works can leave you knowing less than when you started. How to use them is your responsibility.
-
Do not submit other people's code. That is plagiarism, whether it came from a classmate, an earlier year, or a public solution repository.
-
Declare your AI use. One line in your report, for each assignment and for the project: which tools you used, and roughly where. Everyone writes this line in their report, even if you used nothing.
By turning in an assignment, you are declaring that the work is your own, on the terms above.
Submissions
We will be using GitLab with a commit hash submission on Moodle to gather your submissions.
Every time there is something to submit, you will be provided a link to the assignment submission.
Continuous Integration (CI) testing
Your GitLab repositories are CI-enabled and, once triggered, a
Pipeline will be created
that first compiles your code and then optionally runs the tests for the selected assignment.
The pipeline can be triggered in one of these ways:
-
By pushing a commit with a message that contains "[PA#]",
e.g. "[PA1] Implementing average visibility". A tag
of [PA{1,2,3,4}] will run the respective tests, while
[PA0] will only compile the code.
-
Manually through the web interface (Build > Pipelines > Run Pipeline) to
run the compile job. You can also choose to run assignment tests from there.
We will run the pipeline on your submission commit after every assignment.
It is important that you are able to run and pass the pipeline!
The jobs are run by shared runners hosted by
D-INFK ISG.
They are a shared resource so please use them responsibly,
e.g. do not use the CI as a replacement for
local testing. There is a possibility that other users slow down or even block the whole build process,
especially near the assignment deadlines.