ORRC - Own-Renderer Render Competition

Contents

News - Overview - Community - Current round - Previous rounds - Rules - Rendering resources

News

Overview

This is the Own-Renderer Render Competition. Write a 3D renderer, use it to render the best image, and win eternal glory!

ORRC is a recurring on-line competition for 3D rendered images produced by the pariticpants' own custom renderers. Each round lasts one month, in which you can write a 3D renderer from scratch, or continue working on your existing renderer, and have it render an image that incorporates some element of the theme provided for that round.

To ensure that the renderer used is a reasonably active current project, you need to add at least one new feature or improvement to your renderer, that is used in the rendering for that round. It can be a new feature, a performance improvement, or something else, but you have to demonstrate how it's utilized by the render for that round.

Submissions will include the output image, the renderer itself, any assets needed for the render, and a readme file with all the relevant information. See the rules for details.

The idea originated as a more interesting take (for graphics programmers) on traditional ray tracing competitions, but feel free to use any rendering algorithm you like: ray-tracing, radiosity, reyes, splatting, rasterization, or any combination that makes sense for what you want to achieve. Using 3rd party renderers, or 3rd party game engines is not allowed. You have to write it yourself. Also not allowed are vibe-coded renderers generated by LLMs. You can use LLMs to find bugs, or gather information, but not to generate your code.

For more details see the list of rules at the bottom.

Organizer: John Tsiombikas (Nuclear / Mindlapse)

Community

IRC

Join us on IRC to discuss anything related to the competition, or writing a renderer for it: channel #orrc on libera.chat.

Discord

You can also find us in the Graphics Programming discord, at the ORRC chat in the community projects section.

Current round

Round 1 has started!

Voting will open shortly after the end of the round, and will remain open for a week. The results will be announced after the voting period ends.

Previous rounds

None yet.

Rules

Here's the full list of rules:

  1. Write your own renderer using any rendering algorithm you like. It can be a new renderer from scratch, or an existing active project, with at least one new feature used in the entry.
  2. You can't use a 3rd party renderer, 3rd party game engine, or a renderer generated by an LLM. It must be your own code.
  3. Each round of the competition will have one or more themes, announced when the round starts. Make sure to use at least one of the themes in your entry.
  4. Each round will run for 1 month. You may submit multiple times during that period. Anything other than your last submission will be ignored.
  5. Submit an archive (gzipped tar or zip) containing:
    • The final rendered image.
    • The program itself with any libraries and assets necessary to run it, excluding standard system libraries, or libraries that can be installed easily with simple package manager command (specify the command in your readme file).
    • A readme file containing:
      • Name of the submitter: can be anything you want to be shown next to the entry as attribution
      • Name of the renderer (optional).
      • Title of the entry.
      • Contact information (at least an email address).
      • Instructions on how to run the renderer in order to produce the same image you included. Include an estimate of how long it takes to render the image.
      • A declaration of whether it's a new renderer or a pre-existing project. If it's a pre-existing renderer, also point out the new feature you added and how it was used in the image. For example this could be a statment like: Added procedural textures, used for the tree bark and clouds.
      • Any other information you want to provide about the renderer or the image.
  6. The renderer can either open a window and show the rendered image, with some clear indication of when it's done, or it can just output an image file in the current directory when it's done. Progress bars are appreciated but not required.
  7. The renderer can be written in any language, for any operating system or computer you like. If it's doesn't run on a common PC running GNU/Linux or Windows, include a video capture of the renderer being executed and the image being displayed, even if it means a video showing a terminal with a blinking cursor for half an hour. You can include the video in the archive, or provide a youtube link in the readme file.
  8. Participating as a group is allowed. Make a note of it and identify all members that worked on it in your readme file. A group can include multiple programmers working on the renderer, artists working on assets for the rendering, or anything else.
  9. Multiple submissions from the same person or group are allowed, as long as they are materially different and distinct from each other. You can't submit the same scene, rendered the same way, from different viewpoints or under different lighting conditions, but you can submit entirely different scenes, or distinctively different rendering styles. The organizers maintain the right to ask you to pick one of your submissions, if they're not deemed different enough.
  10. Releasing your renderer as free/open source software is not required, but very much recommended and highly appreciated. If you decide to do so, include the corresponding source code in your submission archive, don't forget a license file or statement, and if applicable provide the link to a public repository in your readme file.

Submission methods

You can submit your entry in several different ways:

Rendering Resources

For those not already intimately familiar with off-line rendering algorithms, here are some resources you can use to learn how to write your renderer.

Online

Books

Papers