<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Michalis,<br>
<br>
These are very good points. I must confess to not being on top of
all the changes, so please forgive me if this has been discussed
already:<br>
<br>
Anywhere there is DEFAULT or 'up to the browser' is an opportunity
for content behaving very differently on different browsers, at
least by default. I do like DEFAULT, but I would say, everything
that can have a DEFAULT or 'up to the browser', the browser MUST let
the user specify what that default is. And I would also be in favor
that not only should the browser have a UI and API which allows for
these settings, but there be some sort of 'Defaults' node where
these things can be set. It would be akin to 'Project
Settings/Render Settings/Input Settings/Time Settings' etc. as found
in IDE's like Unity.<br>
<br>
Should there be more specific ways to supply compression? I'm
thinking maybe for mobile platforms where this is a bigger issue, to
specify 16,24,32 bit depth. For example, here are some options from
Unity (note other options for mipmaps, alpha, Po2, etc too)<br>
<img src="cid:part1.07070408.09040905@realmofconcepts.com" alt=""><br>
<br>
Thanks<br>
<br>
Dave A<br>
<br>
<div class="moz-cite-prefix">On 8/3/2013 9:44 AM, Michalis
Kamburelis wrote:<br>
</div>
<blockquote cite="mid:51FD3380.1090900@gmail.com" type="cite">Hi,
<br>
<br>
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.
<br>
<br>
I post them here to encourage discussion, if there will be no
objections I'll submit a spec comments with them.
<br>
<br>
For reference, the TextureProperties spec in X3D 3.3:
<a class="moz-txt-link-freetext" href="http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/texturing.html#TextureProperties">http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/texturing.html#TextureProperties</a>
.
<br>
<br>
Issues:
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
ImageTexture { url "sample.png" }
<br>
<br>
To add anisotropric filtering = 2, *without changing anything
else*, I have to write this:
<br>
<br>
ImageTexture {
<br>
url "sample.png"
<br>
textureProperties TextureProperties {
<br>
anisotropicDegree 2
<br>
# without writing lines below, I would accidentally change
<br>
# compression/filtering compared to previous declaration
<br>
magnificationFilter "DEFAULT"
<br>
minificationFilter "DEFAULT"
<br>
textureCompression "DEAFULT"
<br>
}
<br>
}
<br>
<br>
Suggested specification fix: Change defaults of
magnificationFilter, minificationFilter and textureCompression to
use "DEFAULT".
<br>
<br>
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."
<br>
<br>
This is bad, as it means that to add anisotropic filtering to
<br>
<br>
ImageTexture { url "sample.png" repeatS FALSE }
<br>
<br>
I should change it to
<br>
<br>
ImageTexture {
<br>
url "sample.png"
<br>
textureProperties TextureProperties {
<br>
anisotropicDegree 2
<br>
# without writing lines below, I would accidentally change
<br>
# compression/filtering compared to previous declaration
<br>
magnificationFilter "DEFAULT"
<br>
minificationFilter "DEFAULT"
<br>
textureCompression "DEAFULT"
<br>
boundaryModeS "CLAMP_TO_EDGE"
<br>
}
<br>
}
<br>
<br>
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.
<br>
<br>
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".
<br>
<br>
3. In table "Table 18.7", the definitions of "CLAMP" and
"CLAMP_TO_BOUNDARY" constants, and the borderWidth, are broken in
some subtle ways...
<br>
<br>
- 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*".
<br>
<br>
- "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
<a class="moz-txt-link-freetext" href="http://www.opengl.org/sdk/docs/man/xhtml/glTexParameter.xml">http://www.opengl.org/sdk/docs/man/xhtml/glTexParameter.xml</a>
description of GL_CLAMP_TO_BORDER.
<br>
<br>
- "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...
<br>
<br>
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.
<br>
<br>
Proposed solution: bring the table and constants in sync with
modern OpenGL GL_TEXTURE_WRAP_* definition:
<a class="moz-txt-link-freetext" href="http://www.opengl.org/sdk/docs/man/xhtml/glTexParameter.xml">http://www.opengl.org/sdk/docs/man/xhtml/glTexParameter.xml</a>. Also,
don't talk about "border texel" (what is this?), talk only about
"border color" (which is in borderColor field). So:
<br>
<br>
- New definition of "CLAMP": "This is the same as "CLAMP_TO_EDGE".
<br>
<br>
- New definition of "CLAMP_TO_EDGE": like before, but replace
"border texel" with "borderColor".
<br>
<br>
- 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."
<br>
<br>
- 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").
<br>
<br>
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?
<br>
<br>
For these reasons, view3dscene right now simply ignores this
field, I see no sensible way to handle it.
<br>
<br>
I propose to fix the spec by
<br>
1. Removing the generateMipMaps field, and
<br>
2. Add the following paragraph to TextureProperties spec
clarifying mipmap approach:
<br>
<br>
"""
<br>
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.
<br>
<br>
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.
<br>
"""
<br>
<br>
Regards,
<br>
Michalis
<br>
<br>
_______________________________________________
<br>
X3D-Public mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:X3D-Public@web3d.org">X3D-Public@web3d.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
<br>
<br>
<br>
-----
<br>
No virus found in this message.
<br>
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a>
<br>
Version: 2013.0.3392 / Virus Database: 3209/6547 - Release Date:
08/02/13
<br>
</blockquote>
<br>
</body>
</html>