[x3d-public] new EnvironmentLight Node

[Andreas Plesch]

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

yeah, x3dom just generates mipmaps for ComposedCubeMapTexture as well.

> 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 :)

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.


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
}

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.

-Andreas

> 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



-- 
Andreas Plesch
Waltham, MA 02453