[x3d-public] new EnvironmentLight Node

[Michalis Kamburelis]

Hi,

1. ComposedCubeMapTexture can indeed have mipmaps autogenerated.
glGenerateMipmap works nicely in CGE, for all 3 cubemap types
(ImageCubeMapTexture, GeneratedCubeMapTexture,
ComposedCubeMapTexture). Sometimes ImageCubeMapTexture doesn't have
mipmaps provided too (DDS and KTX (formats which CGE supports) allow
but don't require mipmaps).

2. As for field names and future changes:

I called the field "diffuseTexture" (and so, consistently,
"specularTexture") because there may be another way of specifying it,
without a texture.

Namely, https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based
specifies diffuse using spherical harmonics coefficients (see their
"irradianceCoefficients"). I will want to implement and read about
this alternative. I was using spherical harmonics once (I implemented
radiance transfer in CGE), it's basically a way to approximate any
function whose domain is a 3D direction (i.e. f(normalized vector) ->
some float). You can convert a cubemap to it, or generate the cubemap
from the coefficients of course, but both these conversions take time
and will loose some information.

So we may have "diffuseCoefficients" as an alternative to providing
"diffuseTexture" in EnvironmentLight. Implementation could
- convert coefficients -> cubemap, and implement cubemap,
- or convert cubemap -> coefficients, and implement coefficients,
- or implement them both "natively", which allows both approaches to
be useful and efficient.

Having just "diffuseTexture" seems easier (and also it's implemented
in glTF-Sample-Viewer, and described in paper
https://instantuv.org/wp-content/uploads/2017/03/pbr2016.pdf about
PBR). But then, "diffuseCoefficients" have been chosen for some reason
in https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based
, I guess they may be more efficient (to transfer and//or calculate).

Also, maybe it should be "irradianceTexture" and "irradianceCoefficients".

So, I'm unsure here about various details. I'll test them by trying to
understand them perfectly, and attempting to implement in CGE :)

3. As for HDR -- I would prefer to make this independent of the
EnvironmentLight, I think.

One thing is allowing HDR image formats (like RGBE format, designated
by HDR extension in glTF-Sample-Viewer assets).

Related thing is having a field inside various texture nodes that say
the color space ("SRGB" or "LINEAR", default "SRGB"). For HDR formats,
like RGBE, it should be forced to be treated as "LINEAR" I guess.

Regards,
Michalis


wt., 10 mar 2020 o 05:12 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org