As in the title, what would the acceptance criteria be for an initial version of spectrally calculated light transport in cycles?
What I can think of immediately are these:
- Similar noise per sample in a majority of scenes (benchmark scenes maybe) - this might favour one or the other depending on the specifics of the scene
- Only a minor performance hit for calculating samples on both CPU and GPU (not sure what can be considered acceptable here)
- No feature regression from master (bake, render passes, denoiser etc still work)
- Colour science is sound (colours come out as expected for simple examples such as white light on a diffuse coloured object)
- Code quality up to standard and code style following the styleguide. (Missed this one)
Are there any other requirements which would need to be met before such a patch would be considered to be merged?
That seems like a good list, not sure there is anything to add, perhaps good code quality.
In terms of performance hit, I guess we can accept a few % slowdown. More samples needed due to noise increase will probably be a more significant factor though.
Depending on the numbers, we might want to keep support for rendering without spectral, where conversion between RGB and spectral would basically be a no-op.
I took that one as a given I’m new to C and C++ so I might need a few rounds on cleaning things up, I suspect.
I’m hopeful we might actually get slightly better noise per sample in a majority of scenes, especially if I can get 4 wavelength hero wavelength sampling working alongside a wavelength PDF. There will of course be scenes which end up with more noise in spectral, but I will do what I can to minimise that.
This is pretty straight-forward to implement if we’re happy to accept spectral ‘primaries’ such as the ones from BT.2020, since we can just use the same 3 wavelengths for every sample. If we want to keep things exactly how they are now, that’s substantially harder, since it’ll mean a bunch of branching or duplication if I understand correctly.