Undersampling? (i.e. samplesperpixel < 0)

[AndrewJDR]

Thanks for the project!

Do ospray's pathtracer and scivis backends support undersampling, that is: sampling at some rate less than one per pixel, such as once per every 4 pixels? This can be useful for faster rendering at times of user camera interaction.

I do see a usage of a negative spp value in OSPApp.cpp, which is promising:

renderer["spp"] = -1;

However, at least in the scenegraph codepath within sg/Renderer.cpp, I see a minmax being set on the spp of 1, 128:

child("spp").setMinMax(1,128);

So I'm not sure a negative spp has any actual effect (And this is also confirmed by trying it). I do note that this can be done by rendering to a smaller framebuffer size and upscaling, but it'd be handy not to have to manage that on the usage-code side.

Overall, would also be great to have an up-to-date listing of setting/value pairs for getting the absolute best render times possible for fast interactions, with a separate list relevant to the pathtracer and scivis renderer. The if (fast) { block within OSPApp.app looks promising. However, it doesn't include any potentially relevant pathtracer-only related settings (rouletteDepth / maxContribution) and it also may have out-of-date information (e.g. the -1 for spp that is probably ultimately clamped by minmax, mentioned above).

[jeffamstutz]

Hi,

We ended up removing negative spp values from the base OSPRay API (in v1.7.0) due to issues with accumulation, especially in distributed rendering cases. Thus you are correct in observing that this should be done by having two different frame buffers at different resolutions. This keeps things easier for renderer implementers to maintain correctness of accumulation across frames.

If you have a look at example viewer, the scene graph does implement the concept of an "interaction resolution" and "resolution", which you can find in the app menu.

[AndrewJDR]

Yeah, rendeirng at lower res and upsampling seems like a fine approach, however it appears that the example viewer just relies upon upsampling via OpenGL by placing the lower resolution framebuffer data onto a texture and pushing that through the gl pipeline to upsample it. On software-only configurations where presumably openswr or llvmpipe is being used for OpenGL under the hood, do you know how well that upscale performs? I've seen naive, unoptimized upscaling implementations perform pretty poorly on larger framebuffers (well over >10ms per frame) which can impact interactivity a lot. I assume openswr and/or llvmpipe have decent implementations, but if you have some numbers offhand I'd be curious.

Given it's software-based, OSPRay may also be used in configurations where OpenGL isn't in the picture at all, so it may not be practical for usage code to rely upon OpenGL for the framebuffer upscaling task -- Mesa+OpenSWR is a big dependency to take on just for upscaling. This could lead the implementor to use a naive upscale algorithm which could be pretty slow and give a bad impression of OSPRay. This is my round-about way of proposing that it may be opportune for some well-optimized undersampling/upscale handling be included in ospray and/or some part of the Intel oneAPI rendering toolkit, rather than asking the library usage code to implement something or relying upon OpenGL. This may be a matter of porting the upscaling code out of OpenSWR into OSPRay, assuming that code is well-optimized.

Please do let me know if I'm not understanding how things are working currently with the implementation (e.g. the OpenGL texture upscale method I believe I've seen) or if I'm not making sense in some other way :) Thanks!

[johguenther]

We didn't notice OpenSWR limiting interactivity when using GL upscaling. And even a huge 10ms time for that would still be fast enough. As alternative to GL one can also use other libraries to upscale the framebuffer, for example there is IPP image transforms.

Including upscaling directly in OSPRay is not so easy. Although we have image operations (post processing nodes), those cannot change the resolution. Adding this flexibility complicates OSPRay's implementation and also its usage considerably. Thus I think it is fine to leave that as external task.