Initialize HDRI's image field as an OSPTexture

[szellmann]

Just setting the image as an OSPData didn't work for me, the "map" received in OSPRay's HDRILight would be 0x0 (and subsequently the renderer crashed on dereferencing that nullptr). Using an OSPTexture instead fixes that.

[szellmann]

Seems there's more issues with HDRI lights though:

The HDRI is publicly available, it's the 8K version of this one: https://polyhaven.com/a/blue_lagoon_night

Left is with my own device, right is anari-ospray. First there are those rings that shouldn't be there. But also note the colors are different. As though some sRGB to linear conversion happens (which shouldn't, as the input is raw floating point).

This might eventually have to become a bug report on the OSPRay issue tracker, I don't know, but for now I'm leaving it here as a comment. As after all, HDRI aren't really supported in anari-ospray yet, and it might also be an issue related to what the device does (or my PR, but I'm relatively confident about that, I checked that the input format matches that of the input image). And I don't have a vanilla OSPRay app at hand to test HDRI outside ANARI.

[johguenther]

Thanks for your fix!

Loading that map with OSPRay Studio looks fine.:

The issue was that unpackedColors is a local, temporary vector which was shared with OSPRay, which consequently then used stale data. I fixed that (by sharing the original radiance array using the matching texture format) and merged locally.

Here now with anariViewer, but notice that either the camera or the HDRI map is mirrored:

Your images above are also with anariViewer? Because the map there is also mirrored. I could not display a glTF file (camera is wrong due to querying the bounds too early, I think)

[szellmann]

Awesome, thanks for fixing this.

The images were rendered with a currently still private tool @jeffamstutz shared with me (that also allows for multi-viewport multi-device rendering, hence the side-by-side views).

I also noticed the images were mirrored, and also that according to the specs the up and direction vectors have different default values in OSPRay and in ANARI. But then, my own device doesn't implement up/dir at all, so I suspected this to be a bug that needs fixing on my end. I had hardcoded anari-ospray to match the orientation of my own device, but just to generate the two images, to make them comparable.