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

John Carlson yottzumm at gmail.com
Sun Apr 24 14:45:55 PDT 2022


Thanks, Michalis, good arguments!

John

On Sun, Apr 24, 2022 at 3:58 PM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220424/5ac6fb7e/attachment-0001.html>


More information about the x3d-public mailing list