[X3D-Public] TextureProperties issues

[Michalis Kamburelis]

Hi,

Always when using the X3D TextureProperties node, I feel a little 
discomfort. While the node is useful (and view3dscene handles it), there 
are some traps when using it. I feel that we can remove these traps by 
(slightly) changing the specification. The description of four problems 
and proposed changes follow.

I post them here to encourage discussion, if there will be no objections 
I'll submit a spec comments with them.

For reference, the TextureProperties spec in X3D 3.3: 
http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/texturing.html#TextureProperties 
.

Issues:

1. The default values for magnificationFilter, magnificationFilter, 
textureCompression are "FASTEST", which is usually *not* what you want. 
For example, minificationFilter = "FASTEST" in practice means 
"NEAREST_PIXEL", and honest VRML/X3D implementation should treat it like 
this.  However, the speed gain from "NEAREST_PIXEL" is often very small, 
while the quality drop is very visible.

Much better default value for minificationFilter would be "DEFAULT", 
which means "use browser default". For most modern browsers, this will 
mean trilinear filtering, "AVG_PIXEL_AVG_MIPMAP", although most browsers 
will also give user some configuration option to change it.

Consider the following use case: I want to change "anisotropicDegree" 
for an existing texture. (This is in fact the most common use case of 
TextureProperties node in my experience. Anisotropic filtering can 
improve the look a lot, but it should be tweaked selectively, 
per-texture.) Let's say I have this:

   ImageTexture { url "sample.png" }

To add anisotropric filtering = 2, *without changing anything else*, I 
have to write this:

   ImageTexture {
     url "sample.png"
     textureProperties TextureProperties {
       anisotropicDegree 2
       # without writing lines below, I would accidentally change
       # compression/filtering compared to previous declaration
       magnificationFilter "DEFAULT"
       minificationFilter "DEFAULT"
       textureCompression "DEAFULT"
     }
   }

Suggested specification fix: Change defaults of magnificationFilter, 
minificationFilter and textureCompression to use "DEFAULT".

2. Similarly, boundaryModeS/T/R are a trap, together with sentence "A 
texture with a TextureProperties node will ignore the repeatS and 
repeatT fields on the texture."

This is bad, as it means that to add anisotropic filtering to

   ImageTexture { url "sample.png" repeatS FALSE }

I should change it to

   ImageTexture {
     url "sample.png"
     textureProperties TextureProperties {
       anisotropicDegree 2
       # without writing lines below, I would accidentally change
       # compression/filtering compared to previous declaration
       magnificationFilter "DEFAULT"
       minificationFilter "DEFAULT"
       textureCompression "DEAFULT"
       boundaryModeS "CLAMP_TO_EDGE"
     }
   }

Proposed solutions: introduce in table "Table 18.7 — Texture boundary 
modes" a new value "DEFAULT", meaning: use repeatS/T/R fields specified 
inside the texture node.

Moreover, this would be a perfect place to clarify the repeatS/T/R 
meaning: repeatX = FALSE means "CLAMP_TO_EDGE", and repeatX = TRUE means 
"REPEAT".

3. In table "Table 18.7", the definitions of "CLAMP" and 
"CLAMP_TO_BOUNDARY" constants, and the borderWidth, are broken in some 
subtle ways...

- borderWidth (note it can only have 0 or 1 value): useless, and it's 
unclear how it relates to "boundaryMode*" values (which one overrides 
the other?). This fields should just be removed IMHO, the choice of 
"boundaryMode*" already tells whether we want border or not. No need for 
extra field "borderWidth", that has unknown relation with boundaryMode*".

- "CLAMP_TO_BOUNDARY". I think the definition is Ok, although it's a 
little convoluted. For me, the way OpenGL defines GL_CLAMP_TO_BORDER 
(which seems to be the intention of this X3D constant) is cleaner. It's 
also nice for implementors. OpenGL wording says that it's not about 
different clamping range, it's about using borderColor when a sample 
would fall outside the range. See 
http://www.opengl.org/sdk/docs/man/xhtml/glTexParameter.xml description 
of GL_CLAMP_TO_BORDER.

- "CLAMP": this definition, although it sounds nice and simple, is 
incorrect. When sampling at the very edge of the texel that is on the 
edge of the texture, it would mean that you mix the texel color with... 
well, we don't know. Border? But GL_CLAMP_TO_BORDER contains a better 
definition for clamping with border...

That is why modern OpenGL doesn't even have GL_CLAMP. "Normal clamp" is 
expressed by GL_CLAMP_TO_EDGE. And when you want to use border color, 
you use GL_CLAMP_TO_BORDER.

Proposed solution: bring the table and constants in sync with modern 
OpenGL GL_TEXTURE_WRAP_* definition: 
http://www.opengl.org/sdk/docs/man/xhtml/glTexParameter.xml. Also, don't 
talk about "border texel" (what is this?), talk only about "border 
color" (which is in borderColor field). So:

- New definition of "CLAMP": "This is the same as "CLAMP_TO_EDGE".

- New definition of "CLAMP_TO_EDGE": like before, but replace "border 
texel" with "borderColor".

- New definition of "CLAMP_TO_BOUNDARY": "Evaluates coordinate in a 
similar manner to "CLAMP_TO_EDGE". However, in cases where clamping 
would have occurred in "CLAMP_TO_EDGE" mode, the fetched texel data is 
substituted with the values specified by borderColor."

- Remove the borderWidth field. The choice of clamping method already 
determines if we use the border ("CLAMP_TO_BOUNDARY") or not ("CLAMP", 
"CLAMP_TO_EDGE").

4. The meaning of generateMipMaps field is unclear --- How does it work 
with minificationFilter? How does it work with formats like DDS that may 
(but don't have to) already include mipmaps inside the image data?

For these reasons, view3dscene right now simply ignores this field, I 
see no sensible way to handle it.

I propose to fix the spec by
1. Removing the generateMipMaps field, and
2. Add the following paragraph to TextureProperties spec clarifying 
mipmap approach:

"""
The value of minificationFilter determines whether texture needs 
mipmaps. See table Table 18.9 for the description of allowed 
minificationFilter values, and which ones use mipmaps. The values of 
minificationFilter that leave the filtering choice up to the browser 
(like "DEFAULT"), mean that the choice whether to use mipmaps is also up 
to the browser.

If the minificationFilter needs mipmaps, then the browser *has* to 
provide appropriate mipmaps to the GPU. The browser can either use the 
mipmaps recorded as part of image data or generate them. It's 
recommended, but not required (due to a non-standard but popular formats 
used in this field, like DDs) that browser prefers using the mipmaps 
inside the image data, if there are any (like mipmap layers in DDS), 
instead of generating them.
"""

Regards,
Michalis