[x3d-public] inaccessible Background urls

[Andreas Plesch]

Thanks for the feedback. I agree with the recommendation. A single sentence
should suffice to cover this case.

Another way to resolve this question would be to assign a default value to
the url fields. The value would then be a data url for a transparent pixel
png.

Andreas

---on the phone---

On Fri, Oct 22, 2021, 6:11 AM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211022/bdc939a7/attachment.html>