Hi @beltegeuse,
Thanks for your effort to bring PBRT inside the Rust ecosystem 
Thanks. Good to know that some people like that. I spend far too much time on it, but I think it’s at a point where I do not want to drop it, rather find some people who want to work together to make it more complete.
Regarding the parser: I have an experimental implementation of a parser which can read Arnold’s scene description and use the (PBRT) render API to create images from it. It was meant to give me access to production scenes (@ The Mill, where I work), but I stopped working on it end of August because I got busy with other stuff. I think the parser part is already well separated. I do use the pest crate for parsers (at that time the C++ code used bison and flex), but in theory the .pbrt file format is so easy to parse that it also could be hand-coded (that’s what they decided to do with the original C++ code to get rid of further dependencies).
So, yes, I agree, parsing the scene description could be separated into a library which would be beneficial for a lot of people who do not want to deal with that part, but work e.g. on their own renderer. I would like to see a system where several parsers can read several scene descriptions (geometry should be relative easy). Materials are most of the time already renderer dependent. So, yes, would be nice to separate materials from the scene, just have somehow a binding which part of the geometry should use which material (however that will be defined). I think that’s part of the idea what they want to achieve with MaterialX.
I found the second paper you mention about denoising already, but I didn’t know (read) the paper from Benedikt Bitterli et al. There is also a working implementation for Blender’s Cycles renderer, where you could take the C++ code and turn it into a Rust variant to use.
Thanks for the link to the Mitsuba integration.
