[x3d-public] Background static image and dds

[Andreas Plesch]

On Tue, Aug 6, 2019 at 5:38 AM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > I agree, a dedicated BackgroundImage node may be more appropriate rather
> than layering on top of Background. Sounds like a pretty obvious and
> straightforward spec. enhancement to me since all the functionality is
> already there, only in separate places. Thinking ahead, there would be need
> to be a rule of what to do when both Background and BackgroundImage are
> provided.
>
> I think this is already governed by X3D specification about
> X3DBackgroundNode and bindable nodes. The 1st X3DBackgroundNode in
> file becomes the "current background on top of the stack", and user
> can call set_bind to change it.
>

Yes, of course, that makes sense.


>
> That's how existing Background,
> TextureBackground work, and also (as far as I know) as InstantReality
> extensions like SolidBackground, ImageBackground, GradientBackground
> work (
> http://doc.instantreality.org/documentation/nodetype/SolidBackground/#
> , http://doc.instantreality.org/documentation/nodetype/ImageBackground/#
> ,
> http://doc.instantreality.org/documentation/nodetype/GradientBackground/#
> ).
>
> >
> > The simple feature A) of just having static, fixed image as a backdrop
> is also very useful. Here is an example:
> >
> > https://codepen.io/anon/pen/ZgXPVq?editors=1000
> >
>
> Indeed, this is useful.
>
> Looking at InstantReality extensions, it already has ImageBackground (
> http://doc.instantreality.org/documentation/nodetype/ImageBackground/
> ) with a simple field "texture" of texture of SFNode. This is what I
> imagined earlier as "BackgroundImage" :)
>
> So:
>
> - ImageBackground seems like a cleaner way to provide a single 2D
> image, that would be static in the background.
>
>      Why did X3DOM decided to "overuse" Background node (specially
> treating the case when only backUrl is filled) instead of supporting
> ImageBackground from InstantReality? Was it just an omission, or does
> ImageBackground have other meaning than I think?
>

Good question. I can only speculate. Using an image url directly for
Background does save use of an extra Texture node, so perhaps it was
considered more 'ergonomic'.

Reading InstantReality description's of ImageBackground it appears to have
the meaning you have in mind.


> - ImageBackground also seems like a natural node that could take a
> cubemap in "texture" field. So if you place a cubemap in
> ImageBackground, you can get the same functionality as current
> Background node. ImageBackground.texture could be ImageCubeMapTexture
> node (with DDS or KTX), ComposedCubeMapTexture (6 images) etc.
>

Yes, ImageBackground would be the natural place for a dds/ktx background.

Is it your impression that KTX is already in wide use ? Googling around
does not seem result in too many hits.

glTF did not decide on a supported texture format (yet):

https://github.com/KhronosGroup/glTF/issues/835

Best regards,
> Michalis
>


-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190806/dcbf4cc9/attachment.html>