Environment lighting support

[gjcope]

It's increasingly common for 3D viewers to support image-based lighting solutions (often in the form of "environment maps") that allow more accurate physically based shading of 3D scenes.

Moreover, many viewers (such as Voyager, model-viewer, glTF Viewer) now default to this environment lighting.

This becomes an issue when looking to export scenes from a viewer as a compliant IIIF manifest. A plausible scenario with our viewer (Voyager) is as follows:

1. User imports a manifest with no lighting defined.
2. User gets the default environment lighting, which acceptably lights their model.
3. User adds a directional light to their scene to cast a shadow or highlight a specific attribute of the model.
4. User exports their scene.

When this exported scene is imported into another compliant viewer (or even back into Voyager), they will end up with only the supplementary directional light in their scene which is likely a poor rendering result.

Will this support require an extension post 4.0 release? This is currently a blocker to use having an "official" release of IIIF export functionality.

[JulieWinchester]

Aleph-R3F also uses image-based environment lighting. I recall there was discussion of environment lighting at the Basel 3D TSG working meeting in 2023 (?), where at the time this was considered out of scope for 4.0. If the Presentation 4 spec continues with the basic approach to lights that is currently present in the drafts, then yes, supporting environment lighting would require an extension and/or a 4.1 version of the spec to support.

I know a number of different 3D viewers support environment lighting. Do they specify environment lighting in an interoperable way, where it would be straightforward to pass that information between viewers? Some more information on how environment maps are specified would be helpful. For Aleph-R3F, we mainly allow for specifying a Drei HDRI preset asset (or potentially specifying a custom HDRI preset asset), but thus far we haven't allowed any control over deeper environment-based lighting parameters.

[gjcope]

I think the lowest common denominator information would be image URI, projection type (Equirectangular, Cubic, Angular), and potentially intensity. I know there are a bunch of encoding variations, etc., but I think that could be left to viewer support. It also opens the door for tone mapping, but that could be a separate discussion.