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

[Don Brutzman]

Thanks for review.  This node had a reduced time interval for consideration, but given its maturity and importance in glTF am glad we have a "first draft" of this node in the X3D4 committee draft.

On 2/5/2021 8:14 AM, Andreas Plesch wrote:
> 
>> 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

I think this might be topmost:

* https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based

> 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.

Agreed.  As with other X3D lights and Background* nodes, I'd expect that this node would be affected by transformation 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.

Based on other email, apparently a fairly large number of implementations are out there.  A stated glTF motivation for this node is

"Many 3D tools and engines support image-based global illumination but the exact technique and data formats employed vary. Using this extension, tools can export and engines can import image-based lights and the result should be highly consistent."

If X3D4 implementations think we can add other formats, or pursue other capabilities beyond a strict reading of glTF that are similar to other X3D capabilities, all progress is certainly worth considering.

>> 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.

So thought Michalis too, agreed.  As a precaution I tossed that in for this last round of review to confirm what you guys thought, it is always good to be careful about scoping of lights.  That field is now removed.

>> 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.

It is unfamiliar to me and does seem a bit confusing at times.  Key reference that they list appears to be

* https://en.wikipedia.org/wiki/Cube_mapping

For node definitions, I suggest that we either use glTF names precisely or else explicitly define the correspondences in our definition of EnvironmentLight.

> 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.

Yes we have that approach (and not radius) in X3D4 draft spec.

> (That said x3dom does not
> support scoping of lights).

It is always good to have worthy challenges!  8)

> 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.

Agreed and fixed, that was for discussion to ensure nothing was misunderstood or overlooked.  Only X3DLightNode shadow-related fields should be included now.

Github version and online version should be up-to-date and ready to go (on Monday morning when Dick and I finalize submission to ISO).

Any last-minute refinements to draft are welcome now, future implementation/evaluation/finalization expected that will remain aligned with glTF.

* X3D4 Architecture, Working Draft 3, Lighting component, 17.4.2 EnvironmentLight
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/lighting.html#EnvironmentLight

> Cheers, -Andreas

Again thanks for your in-depth review.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman