<div dir="auto">Thanks, Michalis, good arguments!</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 24, 2022 at 3:58 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">The texture "border" concept (TextureProperties.borderWidth,<br>
TextureProperties.borderColor) is a completely different thing than<br>
borders you may know from CSS (and other technologies for designing 2D<br>
UI). Comparing the TextureProperties.borderWidth capabilities to HTML5<br>
/ CSS border doesn't make much sense :)<br>
<br>
The X3D spec does not describe it properly, but it is clear that<br>
TextureProperties.borderWidth, TextureProperties.borderColor were<br>
supposed to translate to OpenGL GL_CLAMP_TO_BORDER,<br>
GL_TEXTURE_BORDER_COLOR when looking at X3D boundary mode values, and<br>
looking at what is actually possible in GPU APIs like OpenGL, Direct3D<br>
etc.<br>
<br>
Moreover, texture borders are removed from most modern APIs/formats,<br>
because it didn't find much traction/use-cases in real applications.<br>
They are not available in OpenGLES. They are not implementable in most<br>
X3D browsers already, to say it simply.<br>
<br>
IMHO texture borders in X3D should be removed (or deprecated).<br>
<br>
Definitely they should not be extended -- the proposition in this<br>
thread is completely not implementable. Whether you use border or not<br>
-- is actually a boolean choice. There is no border width.<br>
<br>
1. To explain what border means and why it is a boolean choice:<br>
<br>
    Texture borders come into play when you use "clamp to border"<br>
texture clamp (called "CLAMP_TO_BOUNDARY" in X3D), and you use<br>
"linear" (not "nearest") filtering. When the queried position on the<br>
texture is very close to texture edge, then the border color may<br>
"leak" onto the texture, tinting the texture border with given color.<br>
It's when bilinear filtering needs to lookup color that is outside of<br>
the texture area.<br>
<br>
    There's no actual "width" of the border. "borderWidth" doesn't<br>
make sense, TBH. It's rather a boolean choice: do you use border color<br>
when filtering, or not? And this choice is actually already determined<br>
by whether you use "CLAMP_TO_BOUNDARY" or "CLAMP_TO_EDGE". Maybe the<br>
default X3D "CLAMP", which is underspecified in this regard, makes<br>
sense when combined with "borderWidth" ("CLAMP" with "borderWidth=0"<br>
could equal to "CLAMP_TO_EDGE", "CLAMP" with "borderWidth=1" could<br>
equal to "CLAMP_TO_BOUNDARY"), though this is not specified and I<br>
don't know if any X3D browser actually does this (CGE/view3dscene<br>
definitely not).<br>
<br>
2. To explain why I'd like to actually remove/deprecate<br>
TextureProperties.borderWidth/Color:<br>
<br>
    Texture borders didn't gain much traction. Likely due to low<br>
practical applications. Most OpenGL developers know them just because<br>
OpenGL, for historic reasons, defaults to "clamp to border" and many<br>
developers have been stumbled by "why are my textures getting black<br>
tint at the borders?".<br>
<br>
    Looking at what others are doing:<br>
<br>
    - GL_CLAMP_TO_BORDER or GL_CLAMP (which corresponded to "clamp to<br>
border" in old OpenGL) is not present in OpenGLES 3 (see OpenGLES 3<br>
glTexParameter). See<br>
<a href="https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexParameter.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexParameter.xhtml</a><br>
. The only possible clamp method is "GL_CLAMP_TO_EDGE".<br>
<br>
    - glTF doesn't support it (see gltF spec - it only has "Repeat",<br>
"Mirrored Repeat", "Clamp to edge"). See<br>
<a href="https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html" rel="noreferrer" target="_blank">https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html</a><br>
<br>
    - Though "clamp to border" remains supported in OpenGL 4 (see<br>
OpenGL 4 glTexParameter). See<br>
<a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexParameter.xhtml" rel="noreferrer" target="_blank">https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexParameter.xhtml</a><br>
. Though you have to use clear name GL_CLAMP_TO_BORDER now (generic<br>
GL_CLAMP should not be used). And I dare saying that GL_CLAMP_TO_EDGE<br>
is just much more useful.<br>
<br>
In CGE/view3dscene, we made conscious choice to never support "clamp<br>
to border". It's a bit pointless -- not used by any 3D model I saw in<br>
my entire career, not supported by many other APIs, not possible at<br>
all in OpenGLES.<br>
<br>
Regards,<br>
Michalis<br>
<br>
<br>
<br>
<br>
niedz., 24 kwi 2022 o 21:18 <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>> napisał(a):<br>
><br>
> Normally I just read these, but this seems to scream out for a sanity<br>
> check.<br>
><br>
> What happens if the specified border size is greater than the texture or<br>
> even greater than the rendered size of the geometry. There may al.so bee<br>
> the need to describe what happens if TextureTransform or<br>
> TextureCoordinate is used.<br>
><br>
> In HTML5, the border size of a box is used in the determination of<br>
> layout. A large border size increases the space required by the box.<br>
><br>
> Leonard Daly<br>
><br>
><br>
><br>
> On 2022-04-24 12:02, Brutzman, Donald (Don) (CIV) wrote:<br>
> > Current issue needing group discussion:<br>
> ><br>
> >       * Mantis 18.4.9 TextureProperties - borderWidth upper limit<br>
> >       * <a href="https://www.web3d.org/member-only/mantis/view.php?id=921" rel="noreferrer" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=921</a><br>
> >       * Roy Wlamsley: “In the signature for the TextureProperties node<br>
> > the borderWidth field is listed as being of type SFInt32, having a<br>
> > default value of zero, and having limits of [0,1]. This implies that<br>
> > only a single pixel may be used as a border. Is this correct? Or<br>
> > should the limits be [0,inf) so that any number of pixels can be used<br>
> > as a border?<br>
> ><br>
> >       * X3D4 Architecture, Texturing component, 18.4.9 TextureProperties<br>
> >       *<br>
> > <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/texturing.html#TextureProperties" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/texturing.html#TextureProperties</a><br>
> >       * SFInt32     [in,out] borderWidth         0         [0,1]<br>
> >       * “The _borderWidth_ field describes the number of pixels to use<br>
> > for a texture border.”<br>
> ><br>
> > Leaving _borderWidth_ unconstrained seems like a useful presentation<br>
> > feature, especially for animation highlighting individual textures.<br>
> ><br>
> > HTML5 allows specification of border-width in pixels (default) or<br>
> > percent or by enumeration.  We will stick with pixels only, not making<br>
> > any changes to functionality during this final review..<br>
> ><br>
> >       * CSS Backgrounds and Borders Module Level 3<br>
> >       * W3C Candidate Recommendation Draft, 26 July 2021<br>
> >       * 3.3. Line Thickness: the border-width properties<br>
> >       * <line-width> = <length [0,∞]> | thin | medium | thick<br>
> >       * <a href="https://www.w3.org/TR/css-backgrounds-3/#border-width" rel="noreferrer" target="_blank">https://www.w3.org/TR/css-backgrounds-3/#border-width</a><br>
> ><br>
> > Please advise if any problems seen with removing upper bound, absent<br>
> > any objections we will apply the change.<br>
> ><br>
> > all the best, Don<br>
> ><br>
> > --<br>
> ><br>
> > Don Brutzman  Naval Postgraduate School, Code USW/Br<br>
> > <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> ><br>
> > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA<br>
> > +1.831.656.2149<br>
> ><br>
> > X3D graphics, virtual worlds, Navy robotics https://<br>
> > <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">faculty.nps.edu/brutzman</a><br>
> > _______________________________________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>