[x3d-public] inaccessible Background urls

[Michalis Kamburelis]

I'd say that it makes sense to clarify specification for this. A
missing background texture should IMHO behave like a transparent one
(not black).

The question remains should *one* missing texture result in 1. *all*
skybox textures being ignored, 2. or just this one texture/side being
transparent. CGE uses separate textures for skybox (not cubemap) so
ignoring only one of them is not a problem. Ultimately it's a question
what is better for authors, and I do not know myself.

I'm a bit more leaning toward 2 (only the missing texture is ignored,
i.e. transparent) as it is consistent with behavior if you leave URL
of this one texture unspecified (so none, as default).

I could go with this simple sentence:

"""If any Background texture is missing, the rendering result is as if
this texture was fully transparent."""

Regards,
Michalis

czw., 21 paź 2021 o 03:34 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> I am exploring if it is feasible to employ MS Babylon.js as an engine
> to render X3D, first without any runtime. I implemented a few basic
> nodes which went pretty well. While working on Background I noticed
> that the X3D spec. seems silent on behaviour for the case if none of
> the urls provided for a given face is available from the network, and
> therefore the texture is left undefined.
>
> 9.3.2 X3DUrlObject (see links below) mentions that case and refers
> back to the specific node type descriptions for further instructions.
> But 24.4.1 Background does not deal with this case.
>
> Some examples have comments that assume that a browser would use
> skyColor et al. as a fallback. But this is not required it seems.
>
> The tooltips do not offer guidance for this case.
>
> For an implementation it may come down to if a non-accessible url
> should be replaced with a transparent image (letting the sky show), or
> a black image.
>
> In Babylon.js, if any of the six images is not viable or null, the
> whole skybox is rendered black. This is due to webGL cubemap
> requirements. Of course, it is possible for a browser to check the
> urls first and replace them, if necessary, with a transparent pixel,
> for example. But perhaps this should be left as a responsibility to an
> author.
>
> A question to the group here would be if this case should be left unspecified ?
>
> Outdated, obsolete urls may be common enough to justify tightening of
> the spec. But GIGO may apply here and suffice as well.
>
> -Andreas
>
> Relevant links:
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD/Part01/components/environmentalEffects.html#Background
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD/Part01/components/networking.html#X3DUrlObject
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD/Part01/components/networking.html#URLs
>
> https://www.web3d.org/x3d/content/X3dTooltips.html#Background
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org