[x3d-public] new EnvironmentLight Node

[Andreas Plesch]

I am looking at

https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures#new-environmentlight-node

and are considering how to transform the existing
PhysicalEnvironmentLight node to the proposed node.

The main difference is that PhysicalEnvironmentLight only supported
cubemap dds (which is not unreasonable, perhaps along with some other
single file cubemap tex. formats) and therefore directly has diffuse
URL and specular URL fields. EnvironmentLight makes use of the
existing X3DEnvironmentTextureNode instead which allows for greater
flexibility, eg.  use of both, ImageCubeMapTexture for dds, and
ComposedCubeMapTexture for separate cube images (although I am not
sure how ComposedCubeMap deals with mipmapping, probably dynamically
autogenerated)

This is good with the only drawback that it requires containerField
attributes in the xml encoding for the diffuse and specular textures.
But I cannot think of a way to avoid that. Perhaps two nodes:
EnvironmentDiffuseLight and SpecularLight ? If only one is given the
other one is black ?

Could shortening the field names from "diffuseTexture" to "diffuse",
and "specularTexture" to "specular" be considered ? Since it is clear
that these are texture from the node names ?

<ImageCubeMapTexture containerField='diffuseTexture' ..

reads somewhat repetitive to me. There is probably precedence somewhere.

What is the browser supposed to do in the NULL value default cases for
the texture fields ? black or grey to see something ? Perhaps the
behaviour can be left undefined since it is probably never intended.

Should there be a recommendation in the spec. to support hdr textures
for the environment ? I seem to remember that hdr is more important
for PBR.

For dds support, x3d has ImageCubeMapTexture. x3dom did not have it
because Background and ComposedCubeMapTexture supported cubemap dds,
if it was provided as the back url. But ImageCubeMap will be easy to
add.
It looks like it is necessary in x3dom to first replace completely
PhysicalEnvironmentLight with EnvironmentLight everywhere, and then
perhaps reimplement PhysicalEnvironmentLight for backward
compatibility (and convenience) as a special case of EnvironmentLight.
Eg. by internally adding a EnvironmentLight node with
ImageCubeMapTextures.

-Andreas
-- 
Andreas Plesch
Waltham, MA 02453