[x3d-public] draft EnvironmentLight signature needed (Michalis Kamburelis)

[Andreas Plesch]

> Date: Fri, 5 Feb 2021 11:29:08 +0100
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> To: Don Brutzman <brutzman at nps.edu>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] draft EnvironmentLight signature needed

> New "rotation" field indeed is good, following glTF.

I took to opportunity to reread the proposed update/alternative to the
glTF extension which is an unofficial non Khronos vendor extension,
here:

https://github.com/KhronosGroup/glTF/pull/1850
https://github.com/KhronosGroup/glTF/blob/785ce36c9146343be349281067807afa8a753092/extensions/2.0/Vendor/EXT_lights_environment/README.md

Sofar the glTF update omits the rotation field but the last few
comments discuss it. Introducing the rotation field may require
additional language clarifying that it does not (or does) replace
transformations higher up in the hierarchy.

I also noticed that the glTF update only allows single images to
define the cube map. SH coefficients are not included anymore.

Reading more on the glTF IBL history from
https://github.com/KhronosGroup/glTF/issues/946#issuecomment-667505436

onwards I get the impression that the glTF efforts are very much developing.

The main point this update/alternative brings up is that .hdr
panoramic images are popular as environments and should be directly
supported.

> I do not think we need "radius". "EnvironmentLight" doesn't have a
> natural position (conceptually it's an infinite sphere around each
> shape that gets the light). It also wouldn't look sensible to have
> part of some shape within, part outside the radius of the
> EnvironmentLight. This one is more naturally controlled by scoping,
> IMHO.
>
> Not sure what you mean by "TODO avoid any variations from glTF IBL at
> this stage?" -- the current spec in practice matches glTF IBL :)

It is worth keeping in mind that glTF does not have IBL. There is only
a vendor (Microsoft) extension which some feel is not suitable for
their needs.

I agree with scoping rather than having a radius. Going from room to
room, or from the inside of a house to the outside would benefit
greatly from switching the environment. (That said x3dom does not
support scoping of lights).

On another note, the shadow* fields in the x3dom
PhysicalEnvironmentNode are just inherited from the abstract node, are
not supported and should not be in a signature.

Cheers, -Andreas