[x3d-public] new EnvironmentLight Node

[Michalis Kamburelis]

Andreas Plesch <andreasplesch at gmail.com> wrote:
> Understood. Perhaps irradiance should then become a node with texture
> and coefficient fields:
>
> <EnvironmentLight>
>   <Irradiance coefficents=MFFloat> // or
>     <X3DEnvironmentTextureNode/> // preferred if provided
>   </Irradiance>
>   <X3DEnvironmentTextureNode /> // for specular
> </Environment>
>
> The asymmetry between Irradiance and Specular seems a bit off but
> probably reflects their roles and allows avoiding containerFields.
>

I guess it's a matter of taste -- I would prefer a version without
intermediate <Irradiance> node, but with containerField, and with
specularTexture. I.e. version A is more obvious to me:

A:

```
<EnvironmentLight>
  <ImageCubeMapTexture url="diffuse.dds" containerField="diffuseTexture" />
  <ImageCubeMapTexture url="specular.dds" containerField="specularTexture" />
</EnvironmentLight>
```

B:

```
<EnvironmentLight>
  <Irradiance>
    <ImageCubeMapTexture url="diffuse.dds" />
  </Irradiance>
  <ImageCubeMapTexture url="specular.dds" />
</EnvironmentLight>
```

But I immediately agree it's a matter of taste :) For me,
"containerField" isn't that bad (and new textures in Material /
PhysicalMaterial / UnlitMaterial will require it also, otherwise we
would need a *lot* of new extra nodes). And it allows to have simpler
hierarchy, without the need for new nodes.

> Deriving EnvironmentLight from X3DLightNode does not seem like a
> perfect fit currently since X3DLightNode
> has color and ambientIntensity.
>
> X3DLightNode : X3DChildNode {
>   SFFloat [in,out] ambientIntensity 0     [0,1]
>   SFColor [in,out] color            1 1 1 [0,1]
>   SFBool  [in,out] global           FALSE
>   SFFloat [in,out] intensity        1     [0,1]
>   SFNode  [in,out] metadata         NULL  [X3DMetadataObject]
>   SFBool  [in,out] on               TRUE
> }

As for color:

- We can multiply the resulting sample (from specular and diffuse
cubemap) by a "color" vector value.

- If the diffuseTexture or specularTexture is NULL, then we can just
use only this "color" as a value of given sample.

- So "color" is the "basis" with which to multiply texture (diffuse /
specular). And it can be used to e.g. make light "reddish" (regardless
of textures), it can be animated easily too.

- Fortunately it's white by default, no leaving "color" unspecified
means to use unmodified textures.

- This also means that leaving diffuseTexture or specularTexture as
NULL is equivalent to them being pure white. This is a bit unnatural
(it would be more natural if leaving  them unspecified was equivalent
to having them black)?
https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based
just says that specular texture is required, period.

- As far as I see this makes sense, and is also consistent with how
textures on materials work (they multiply component-wise with
vector/scalar).

As for ambientIntensity:

- It has some sense for EnvironmentLight, i.e. it can be handled there
exactly as for other light nodes (PointLight / SpotLight /
DirectionalLight).. when you use (Phong) Material. The problem with
ambientIntensity is actually that it only makes sense for Phong
lighting model, i.e. Material. The PhysicalMaterial will ignore it.
(UnlitMaterial too, but it ignored whole light source of course :) ).

I don't have a better solution to this than just saying in the spec:
"Note that the ambientIntensity is only used by the Phong lighting
model, that is: by shapes using Material node (not e.g.
PhysicalMaterial or UnlitMaterial)".

Aside from it, I think I'll add X3DPunctualLightNode to the spec
anyway. As an ancestor for existing PointLight / SpotLight /
DirectionalLight, but not of EnvironmentLight. It works nicely in CGE,
and it's a place where you can move all functionality/properties that
don't make sense for EnvironmentLight. Although I don't yet see how it
would differ in X3D spec from X3DLightNode.

>
> Finally, glTF has a 'rotation' field for the cube, and x3dom has a
> 'direction' which I think is the same. I guess that this is
> unnecessary
> since lights are child nodes, eg. are affected by the transform
> hierarchy. Hm, it may still be useful for scoped lights.

Good point, I wrote it to my TODO :)

Regards,
Michalis