Rendering multiple camera views into one set of render/denoiser buffers


I need my OptiX renderer to be able to render multiple viewports from the front-end app in one pass. My plan is to allocate a big enough screen/denoiser buffers to fit all the viewports and then in the render pass, just render each viewport into own region of the bigger buffer. I was wondering if I do this and the final render has all the different viewport renders in it, will the denoiser still work properly on the whole image ?

Seems to me like that idea should work just fine, but may depend on any specific goals or requirements you might have. Are you thinking of doing one optixLaunch and one optixDenoiserInvoke per sub-view, or are you considering doing everything in one pass with a single render launch and single denoiser launch? I think whether you use one pass or multiple passes, and whether you use one buffer or multiple buffers, are completely separate and independent ideas. It is possible to use either choice in both cases.

You probably have more options available if you do it in multiple passes (for example rendering sub-views with different pipelines and/or different denoising options), and it might not be noticeably slower to do it in multiple passes. If you denoise the entire buffer in one pass, but you have several separate sub-views, then the denoiser might blur across the boundaries or seams between views that border each other, since it will have no idea about your sub-window views. To guarantee that you don’t get sub-view boundary artifacts, it’s best to denoise each sub-view separately, which you can do on a large buffer.

It may or may not help to look at the denoiser tiling class in optix_denoiser_tiling.h which does multi-pass denoising on sub-tiles – but keep in mind this class has the opposite goal from yours; the tiling denoiser wants to make sure the sub-tiles are seamless and have no tile boundaries visible in the output, so it adds overlap gutters around each tile to try to ensure the border pixels are identical once the tiles are stitched together into the final image. This class is also intended to be used to control memory usage, e.g., enable denoising of a large buffer that perhaps doesn’t fit within a fixed memory budget. In your case the tile sizes might be irregular, you don’t want gutters or seamless overlap, and you probably don’t care about the memory budget, so you would want to tailor a helper class like this to your specific needs.


David.