<div dir="ltr"><div dir="ltr">On Tue, Aug 6, 2019 at 5:38 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
<br>
I think this is already governed by X3D specification about<br>
X3DBackgroundNode and bindable nodes. The 1st X3DBackgroundNode in<br>
file becomes the "current background on top of the stack", and user<br>
can call set_bind to change it.<br></blockquote><div><br></div><div>Yes, of course, that makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That's how existing Background,<br>
TextureBackground work, and also (as far as I know) as InstantReality<br>
extensions like SolidBackground, ImageBackground, GradientBackground<br>
work ( <a href="http://doc.instantreality.org/documentation/nodetype/SolidBackground/#" rel="noreferrer" target="_blank">http://doc.instantreality.org/documentation/nodetype/SolidBackground/#</a><br>
, <a href="http://doc.instantreality.org/documentation/nodetype/ImageBackground/#" rel="noreferrer" target="_blank">http://doc.instantreality.org/documentation/nodetype/ImageBackground/#</a><br>
, <a href="http://doc.instantreality.org/documentation/nodetype/GradientBackground/#" rel="noreferrer" target="_blank">http://doc.instantreality.org/documentation/nodetype/GradientBackground/#</a><br>
).<br>
<br>
><br>
> The simple feature A) of just having static, fixed image as a backdrop is also very useful. Here is an example:<br>
><br>
> <a href="https://codepen.io/anon/pen/ZgXPVq?editors=1000" rel="noreferrer" target="_blank">https://codepen.io/anon/pen/ZgXPVq?editors=1000</a><br>
><br>
<br>
Indeed, this is useful.<br>
<br>
Looking at InstantReality extensions, it already has ImageBackground (<br>
<a href="http://doc.instantreality.org/documentation/nodetype/ImageBackground/" rel="noreferrer" target="_blank">http://doc.instantreality.org/documentation/nodetype/ImageBackground/</a><br>
) with a simple field "texture" of texture of SFNode. This is what I<br>
imagined earlier as "BackgroundImage" :)<br>
<br>
So:<br>
<br>
- ImageBackground seems like a cleaner way to provide a single 2D<br>
image, that would be static in the background.<br>
<br>
     Why did X3DOM decided to "overuse" Background node (specially<br>
treating the case when only backUrl is filled) instead of supporting<br>
ImageBackground from InstantReality? Was it just an omission, or does<br>
ImageBackground have other meaning than I think?<br></blockquote><div><br></div><div>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'.</div><div><br></div><div>Reading InstantReality description's of ImageBackground it appears to have the meaning you have in mind.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- ImageBackground also seems like a natural node that could take a<br>
cubemap in "texture" field. So if you place a cubemap in<br>
ImageBackground, you can get the same functionality as current<br>
Background node. ImageBackground.texture could be ImageCubeMapTexture<br>
node (with DDS or KTX), ComposedCubeMapTexture (6 images) etc.<br></blockquote><div><br></div><div>Yes, ImageBackground would be the natural place for a dds/ktx background.</div><div><br></div><div>Is it your impression that KTX is already in wide use ? Googling around does not seem result in too many hits.</div><div><br></div><div>glTF did not decide on a supported texture format (yet):</div><div><br></div><div><a href="https://github.com/KhronosGroup/glTF/issues/835">https://github.com/KhronosGroup/glTF/issues/835</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Best regards,<br>
Michalis<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div></div>