[X3D-Public] TextureProperties issues

[Michalis Kamburelis]

> 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.

IMHO, you will always have some bits behaving differently, depending
on OpenGL/Direct3D capabilities, mobile(OpenGL ES)/desktop, GPU
capabilities, etc. Just like HTML: a webpage may look differently on
different OSes/devices/browsers, and that's good (to a certain extent
of course).

And the TextureProperties stuff is quite mixed with rendering speed
and what GPU can. E.g. anisotropicDegree is limited by GPU
(GL_MAX_TEXTURE_MAX_ANISOTROPY), just like in Unity 3D, and there's no
way to avoid it.

Of course I agree that a browser should allow user to choose these
defaults, although that's up to the browser to make a good UI for
this.

I'm not against some node like DefaultTextureProperties... But don't
put everything there. E.g. having *all* textures automatically use
anisotropicDegree >= 4 is a bad idea, it may slow down the rendering
too much without any good (noticeable) reason. In Unity 3D, you also
don't have any way to increase anisotropy of *all* textures at once
(although you can write an import script to do that in Unity 3D :)

>
> 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)
>

I'm not sure are texture GPU compression methods common enough to add
their names to X3D yet. E.g. S3TC compression used to be a leader
(that's why Unity3d and Castle Game Engine and many others support
them :). But the ugly patent issues appeared (see
http://dri.freedesktop.org/wiki/S3TC/ ), and so other compression
methods became used in some implementations, like
http://en.wikipedia.org/wiki/PVRTC .

Another note relating to "mobile platforms" you mention: it's the X3D
browser, not X3D author, that knows whether it runs on a mobile device
(or a slow desktop, or a fast desktop...). Specifying compression
methods as generic low/medium/high is an advantage in this case. E.g.
on desktop "low compression" may equal "none compression", but on
mobile "low compression" may actually do something.

That being said, after all my above whining, I would probably agree on
adding some explicit compression methods to X3D :), just with good
recommended fallback behavior. Like:

- DXT1 - "The browser should use DXT1 compression, or other
compression suitable for arbitrary RGB data and 1 bit (yes/no) alpha
channel. Eventually, the browser should fallback to it's default
compression method (possibly none)."

- DXT3 / DXT5 - "The browser should use, appropriately, DXT3 or DXT5
method. Eventually, the browser should use any compression suitable
for arbitrary RGB and arbitrary (using full 0..1 range) alpha.
Eventually, the browser should fallback to it's default compression
method (possibly none), as above."

Note that this means it's not possible to fallback from DXT3 / DXT5 to
DXT1. And that's very good (it's most likely not desired, as it
changes blending into 0-1 test).

Michalis