Pathtracer/scivis renderer inconsistent alpha values in framebuffer

[paulmelis]

This is with the devel branch. When rendering a scene and only varying the renderer type (and materials of course) the generated framebuffer always contains alpha 0 for the path tracer independent of the value of bgColor. The scivis renderer does listen to bgColor.

[jeffamstutz]

Because the path tracer focuses on being physically based, it lets lights determine what the appearance of primary ray misses: either the HDRI light directly maps this to a texel, and/or virtual lights (usually ambient) are directly sampled and provide that as the "background" appearance.

We do have a feature on the path tracer that lets users place a texture as the constant background (see the backplate parameter), which plays a similar role to what bgColor does with all our other renderers, including scivis.

@johguenther what do you think about the idea of having bgColor as an "opt-in" option if there's no backplate specified?

[jeffamstutz]

Also, FYI: these properties of the path tracer were also true for v1.x version of OSPRay. It's timely for us to consider any changes before the v2.0 release though. :)

[paulmelis]

Ah, the fact that bgColor in the devel docs was promoted from being a scivis-only parameter to one understood by all renderers threw me off :) The description of the two renderer types also doesn't really indicate that the color of pixels in which nothing was hit is computed differently, other than from the remark for the path tracer's backplate option. So the latter is the only method to get a certain color for pixels in which no primary hits where found that does not influence the scene's lighting?

Since we're discussing lighting: what exactly does geometryLights do? It's a new parameter that seems very similar in function to a light's visible flag, but I could be misunderstanding what "whether to render light emitted from geometries" means. Or is it a scene-global flag that simply disables light coming from emitting geometries?

And finally, if I'm asking things that aren't fully settled yet in the devel branch then please tell me. So far I've assumed that what the docs say is what has been decided and functional (and unlikely to change before 2.0 is released).

[paulmelis]

So the latter is the only method to get a certain color for pixels in which no primary hits where found that does not influence the scene's lighting?

Oh wait, the tutorial samples (specifically the stuff in apps/ospray_testing/lights) use the trick of a zero-intensity ambient light for the same purpose?

[johguenther]

This is actually a bug in the documentation: the pathtracer does not support bgColor (never has). Although I like the documentation to always reflect the current state (of devel), we are not 100% there yet.

[paulmelis]

This is actually a bug in the documentation: the pathtracer does not support bgColor (never has). Although I like the documentation to always reflect the current state (of devel), we are not 100% there yet.

Understandable :) Would it help if I opened an issue listing the things I noticed so far in the docs for 2.0?

[jeffamstutz]

That is always welcome feedback, if you are willing! :)

[paulmelis]

Sure, no problem, see https://github.com/ospray/ospray/issues/350

[paulmelis]

We do have a feature on the path tracer that lets users place a texture as the constant background (see the backplate parameter), which plays a similar role to what bgColor does with all our other renderers, including scivis.

Was just testing with this, but it appears this only works in pixels of the image where something is hit. For those pixels I indeed see a blending with the backplate color. But for pixels where primary rays hit nothing I still get pixels with alpha 0. See this crop of a render:

Here's the relevant snippet I used

        float texel[4] = { 
            0.0f, 1.0f, 0.0f, 1.0f
        };

        OSPData data = ospNewData(1, OSP_VEC4F, texel);

        OSPTexture backplate = ospNewTexture("texture2D");    
            ospSetVec2i(backplate, "size", 1, 1);
            ospSetInt(backplate, "type", OSP_TEXTURE_RGBA32F);
            ospSetData(backplate, "data", data);
        ospCommit(backplate);            
        ospRelease(data);

        ospSetObject(renderer, "backplate", backplate);
        ospCommit(renderer);    
        ospRelease(backplate);

[johguenther]

OK, we need to look into that. In general this issue points out that we need to better harmonize SciVis and Pathtracer, i.e.

• PT should support bgColor (and also maxDepthTexture)
• SciVis should support backplate and also HDRI light (as environment map, not for illumination)

[paulmelis]

FYI, with

float texel[4] = { 
            world_settings.background_color(0),
            world_settings.background_color(1),
            world_settings.background_color(2),
            world_settings.background_color(3)
        };

        OSPData data = ospNewData(1, OSP_VEC4F, texel, 0);

        OSPTexture backplate = ospNewTexture("texture2d");    
            ospSetInt(backplate, "format", OSP_TEXTURE_RGBA32F);
            ospSetVec2i(backplate, "size", 1, 1);            
            ospSetObject(backplate, "data", data);
        ospCommit(backplate);            
        ospRelease(data);

        ospSetObject(renderer, "backplate", backplate);
        ospRelease(backplate);

I now get a working backplate in 2dda6dc39bedca3abbc6fc2a235acefd70fe360b

[johguenther]

The release-2.0.x branch now contains fixes to support background color and backplate in both SciVis renderer and Path Tracer. Also the alpha channel should now be correct (note that the alpha channel of the background color is also regarded).