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

Sun Apr 24 16:21:41 PDT 2022

Thanks for all in-depth analysis that there is a good case for
deprecation/removal.

These fields first appeared in X3D 3.2 but I have never seen them used in
authored content.

We do not want to leave any ambiguity regarding rendering consistency
between X3D4 with glTF.  In order to be able to encounter (presumed) X3D3
content without failing, we might add something like

* " The borderWidth and borderColor fields are not supported in X3D4 models.
"

We will consider spec modification options in next editors meeting.

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

-----Original Message-----
From: Michalis Kamburelis <michalis.kambi at gmail.com> 
Sent: Sunday, April 24, 2022 1:57 PM
To: Leonard Daly <Leonard.Daly at realism.com>
Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Public Mailing
List (x3d-public at web3d.org) <x3d-public at web3d.org>
Subject: Re: [x3d-public] TextureProperties - borderWidth upper limit
constrained to 1 or made unbounded?

NPS WARNING: *external sender* verify before acting.

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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khrono
s.org%2Fregistry%2FOpenGL-
Refpages%2Fes3.0%2Fhtml%2FglTexParameter.xhtml&data=05%7C01%7Cbrutzman%4
0nps.edu%7C0a2206038bd041a9736508da26350ba9%7C6d936231a51740ea9199f757896337
8e%7C0%7C0%7C637864306679765629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2cd
NQD7AxhG4m5N4sxDwNG9hFtB713ZWZLhLvzKH4Sg%3D&reserved=0
. 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khrono
s.org%2Fregistry%2FglTF%2Fspecs%2F2.0%2FglTF-
2.0.html&data=05%7C01%7Cbrutzman%40nps.edu%7C0a2206038bd041a9736508da263
50ba9%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637864306679765629%7CUnkn
own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
I6Mn0%3D%7C3000%7C%7C%7C&sdata=aoA%2B%2F12mUpoQV8DKZWhKBcUN1vV9nS%2F6CeG
C%2B2vgsZw%3D&reserved=0

    - Though "clamp to border" remains supported in OpenGL 4 (see OpenGL 4
glTexParameter). See
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khrono
s.org%2Fregistry%2FOpenGL-
Refpages%2Fgl4%2Fhtml%2FglTexParameter.xhtml&data=05%7C01%7Cbrutzman%40n
ps.edu%7C0a2206038bd041a9736508da26350ba9%7C6d936231a51740ea9199f7578963378e
%7C0%7C0%7C637864306679765629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wk07h
hj63VZ%2FlzNfNHSID9ICzlcIz%2FTvGTfOhuzmyeA%3D&reserved=0
. 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.w3.org%2FTR%2Fcss-backgrounds-3%2F%23border-width&data=05%7C01
> > %7Cbrutzman%40nps.edu%7C0a2206038bd041a9736508da26350ba9%7C6d936231a
> > 51740ea9199f7578963378e%7C0%7C0%7C637864306679765629%7CUnknown%7CTWF
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6Mn0%3D%7C3000%7C%7C%7C&sdata=wiGJBQfxGLXJigImNivgGTd4rt727yXE%2
> > FZ8PMWhB8ZI%3D&reserved=0
> >
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220424/632f284a/attachment.p7s>