[x3d-public] TextureProperties - borderWidth upper limit constrained to 1 or made unbounded?

Sun Apr 24 13:56:52 PDT 2022

The texture "border" concept (TextureProperties.borderWidth,
TextureProperties.borderColor) is a completely different thing than
borders you may know from CSS (and other technologies for designing 2D
UI). Comparing the TextureProperties.borderWidth capabilities to HTML5
/ CSS border doesn't make much sense :)

The X3D spec does not describe it properly, but it is clear that
TextureProperties.borderWidth, TextureProperties.borderColor were
supposed to translate to OpenGL GL_CLAMP_TO_BORDER,
GL_TEXTURE_BORDER_COLOR when looking at X3D boundary mode values, and
looking at what is actually possible in GPU APIs like OpenGL, Direct3D
etc.

Moreover, texture borders are removed from most modern APIs/formats,
because it didn't find much traction/use-cases in real applications.
They are not available in OpenGLES. They are not implementable in most
X3D browsers already, to say it simply.

IMHO texture borders in X3D should be removed (or deprecated).

Definitely they should not be extended -- the proposition in this
thread is completely not implementable. Whether you use border or not
-- is actually a boolean choice. There is no border width.

1. To explain what border means and why it is a boolean choice:

    Texture borders come into play when you use "clamp to border"
texture clamp (called "CLAMP_TO_BOUNDARY" in X3D), and you use
"linear" (not "nearest") filtering. When the queried position on the
texture is very close to texture edge, then the border color may
"leak" onto the texture, tinting the texture border with given color.
It's when bilinear filtering needs to lookup color that is outside of
the texture area.

    There's no actual "width" of the border. "borderWidth" doesn't
make sense, TBH. It's rather a boolean choice: do you use border color
when filtering, or not? And this choice is actually already determined
by whether you use "CLAMP_TO_BOUNDARY" or "CLAMP_TO_EDGE". Maybe the
default X3D "CLAMP", which is underspecified in this regard, makes
sense when combined with "borderWidth" ("CLAMP" with "borderWidth=0"
could equal to "CLAMP_TO_EDGE", "CLAMP" with "borderWidth=1" could
equal to "CLAMP_TO_BOUNDARY"), though this is not specified and I
don't know if any X3D browser actually does this (CGE/view3dscene
definitely not).

2. To explain why I'd like to actually remove/deprecate
TextureProperties.borderWidth/Color:

    Texture borders didn't gain much traction. Likely due to low
practical applications. Most OpenGL developers know them just because
OpenGL, for historic reasons, defaults to "clamp to border" and many
developers have been stumbled by "why are my textures getting black
tint at the borders?".

    Looking at what others are doing:

    - GL_CLAMP_TO_BORDER or GL_CLAMP (which corresponded to "clamp to
border" in old OpenGL) is not present in OpenGLES 3 (see OpenGLES 3
glTexParameter). See
https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexParameter.xhtml
. The only possible clamp method is "GL_CLAMP_TO_EDGE".

    - glTF doesn't support it (see gltF spec - it only has "Repeat",
"Mirrored Repeat", "Clamp to edge"). See
https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html

    - Though "clamp to border" remains supported in OpenGL 4 (see
OpenGL 4 glTexParameter). See
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexParameter.xhtml
. Though you have to use clear name GL_CLAMP_TO_BORDER now (generic
GL_CLAMP should not be used). And I dare saying that GL_CLAMP_TO_EDGE
is just much more useful.

In CGE/view3dscene, we made conscious choice to never support "clamp
to border". It's a bit pointless -- not used by any 3D model I saw in
my entire career, not supported by many other APIs, not possible at
all in OpenGLES.

Regards,
Michalis

niedz., 24 kwi 2022 o 21:18 <Leonard.Daly at realism.com> napisał(a):
>
> Normally I just read these, but this seems to scream out for a sanity
> check.
>
> What happens if the specified border size is greater than the texture or
> even greater than the rendered size of the geometry. There may al.so bee
> the need to describe what happens if TextureTransform or
> TextureCoordinate is used.
>
> In HTML5, the border size of a box is used in the determination of
> layout. A large border size increases the space required by the box.
>
> Leonard Daly
>
>
>
> On 2022-04-24 12:02, Brutzman, Donald (Don) (CIV) wrote:
> > Current issue needing group discussion:
> >
> >       * Mantis 18.4.9 TextureProperties - borderWidth upper limit
> >       * https://www.web3d.org/member-only/mantis/view.php?id=921
> >       * Roy Wlamsley: “In the signature for the TextureProperties node
> > the borderWidth field is listed as being of type SFInt32, having a
> > default value of zero, and having limits of [0,1]. This implies that
> > only a single pixel may be used as a border. Is this correct? Or
> > should the limits be [0,inf) so that any number of pixels can be used
> > as a border?
> >
> >       * X3D4 Architecture, Texturing component, 18.4.9 TextureProperties
> >       *
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/texturing.html#TextureProperties
> >       * SFInt32     [in,out] borderWidth         0         [0,1]
> >       * “The _borderWidth_ field describes the number of pixels to use
> > for a texture border.”
> >
> > Leaving _borderWidth_ unconstrained seems like a useful presentation
> > feature, especially for animation highlighting individual textures.
> >
> > HTML5 allows specification of border-width in pixels (default) or
> > percent or by enumeration.  We will stick with pixels only, not making
> > any changes to functionality during this final review..
> >
> >       * CSS Backgrounds and Borders Module Level 3
> >       * W3C Candidate Recommendation Draft, 26 July 2021
> >       * 3.3. Line Thickness: the border-width properties
> >       * <line-width> = <length [0,∞]> | thin | medium | thick
> >       * https://www.w3.org/TR/css-backgrounds-3/#border-width
> >
> > Please advise if any problems seen with removing upper bound, absent
> > any objections we will apply the change.
> >
> > all the best, Don
> >
> > --
> >
> > Don Brutzman  Naval Postgraduate School, Code USW/Br
> > brutzman at nps.edu
> >
> > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> > +1.831.656.2149
> >
> > X3D graphics, virtual worlds, Navy robotics https://
> > faculty.nps.edu/brutzman
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org