[Feature request] Back-face culling

[stukowski]

It would be very useful if OSPRay could support back-face culling for mesh faces in the future. What I am asking for is an option similar to VisRTX's experimental cullBackfaces option, which can be set on ANARI triangles geometries.

A typical use case would be rendering two-sided meshes with differently colored front and back sides of the surface. Such meshes consist of pairs of faces with opposite winding orders, and back-face culling would allow only one of the faces to be visible (the front-facing one). An example:

Currently, rendering of such two-sided meshes can only be realized by performing the (view-dependent) back-face culling on the application side prior to handing the filtered face list to OSPRay.

[johguenther]

See also https://github.com/RenderKit/ospray/issues/545. Alternatively, how about a two-sided material (like USD / MaterialX have it)? Because winding-order is very Mesh specific and does not work for other geometries (iso-surfaces, spheres, ...). At least we need a generic and consistent definition of "front" and "back". For example, via shading normals as it is done with clippingGeometry.

[stukowski]

From my perspective, a two-sided material (or, actually, two color attributes per face) would not be the optimal solution, because the input mesh already consists of pairs of faces, and our application's data structure only supports one color attribute per face. Changing that, and merging the face pairs during hand-over to OSPRay is not impossible, but it would represent a deviation with respect to all other rendering backends currently in use by our application aside from OSPRay (OpenGL, ANARI/VisRTX, Tachyon), which all use the back-face culling technique.

But still, if you are convinced that a two-sided material is the best solution, it would still mean an improvement (i.e., at least better than the current workaround, which is performing the view-dependent face culling on the application side).

For our application, two-sided coloring is needed only for mesh geometries, not other geometry types.