[rs-pbrt] Call for Participation

There will be some announcements soon, but here some comments before I start with some more specific calls for participation.

Here some links:

  • Some information about the company (The Mill) I work for as Principal R&D Engineer
  • General information about the rs-pbrt project. Basically a pure Rust implementation of a physically based renderer. Conversion from existing high-performance C++ code to Rust. TODO: Optimize existing Rust code to make it real fast. There are still bits and pieces missing in comparison to the C++ code, but features will be added only on the basis of test scenes, which do render differently or more complete using the C++ code, so it's easy to identify which parts need attention in the Rust code base.
  • I think there is a fourth edition of the book on the horizon, but no source code available yet, so it would be pure speculation what topics will be covered there.
  • So far the renderer is a command-line app (CLI) which matches the existing C++ code closely. Years ago another project (now called LuxCoreRender) spawned from an earlier version of the book to make it more artists friendly and provide a GUI for the renderer. Our approach will be a bit different. Our company is not an open source software company, our mission (We are artists, technologists and makers for all media, working at the frontiers of visual narrative) is to do state-of-the-art film productions (see Mill Film legacy), commercials, music clips, etc. We do use commercial software for our day to day jobs, but there are open source libraries (see e.g. Academy Software Foundation) which we use in our industry in general, not just for research and development, but also as part of our production pipeline. We will spawn branches of the Rust based source code to add features, tighter integration with other scene descriptions (e.g. USD) used in our industry, probably investigate some GPU acceleration, add denoising (e.g. Open Image Denoise), etc. I would like to do this in a way, that the CLI renderer has less dependencies, tighter integrations (e.g. into Blender) are possible (with more dependencies and e.g. view port rendering), and commercial products we use (like Houdini and Autodesk Maya) export to a common scene description, so we can replace renderers easily if there are specific production needs we can not fullfill with traditional production pipelines.

I worked on this project for about 2 1/2 years on my own, there were only two contributors so far. Antoine Büsch (see Release Notes for v0.4.5 and his implementation of a PBRT and Rust based renderer) merged code he had already implemented into the current rs-pbrt code. Daniel Egger recently started to contribute in form of pull requests (PRs). In the future some of my colleagues will start to contribute as well (especially with integration into our production pipeline), but I invite you to participate, so that whatever we will start adding in comparison to the original C++ code, will be usuable for many and not be done in a way which ties you to a certain way of working. All of this will be tricky to do, but I believe in transparency and open source code. So let's make this a success. Ideas are welcome ...


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.