[x3d-public] new EnvironmentLight Node

[Andreas Plesch]

Hi Michalis,

let's just follow what you had in mind, especially if it requires less
wordsmithing for the spec..

To use the color field as a multiplier or default is a good idea.
Probably both diffuse and specular need to be affected as you
suggested.

It would be sufficient to just add a sentence that for
PhyscialMaterial the ambientIntensity light field is ignored (for any
light).

Cheers,

-Andreas

On Tue, Mar 10, 2020 at 8:18 PM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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



-- 
Andreas Plesch
Waltham, MA 02453