[X3D-Public] X3D MultiTexturing - how about we start fixing the spec? :)

Michalis Kamburelis michalis.kambi at gmail.com
Tue Aug 6 11:07:15 PDT 2013

> Item 5, in your proposal:
> Proposed clarification: function="COMPLEMENT" works only on RGB, does not
> touch alpha channel. This seems more suitable for usual cases, and follows
> the majority of implementations.
> I can think of times I would simply want to invert the A channel. Is there a
> preferred way to do that? I like your earlier proposal of using a slash / to
> specify Alpha behavior, thus "/COMPLEMENT" would just invert the alpha
> channel. Sometimes alpha is 'transparent' and sometimes 'opacity'

If you think it's useful enough, we could indeed propose honoring
separate MultiTexture.function for RGB and alpha channels, just like I
already proposed for MultiTexture.mode and MultiTexture.source.

Two caveats:

1. Your use case (inverting alpha channel of texture): "/COMPLEMENT"
may not do what you want. MultiTexture.function works *after* the
texture stage is calculated (X3D spec says "The function field defines
an optional function to be applied to the argument after the mode has
been evaluated."). So your texture alpha is mixed with material alpha
(mixing math depending on mode field), and then the alpha of result is
inverted. This is not the same as just inverting the alpha of the
texture before the calculation... You could force it to do what you
want by using mode="../REPLACE", or by using function="/COMPLEMENT"
one stage later (but none of these things are 100% clean solutions).

I have no idea why MultiTexture.function has such weird definition.
IMHO, it would be much more useful if the calculation was done
*before* the mode calculations...

2. The other note is that maybe extending the existing multi-texturing
possibilities is not such a good idea. My hope for this effort is to
make them cleanly defined and fixed (which is also connected to
cleaner single-texturing). But for new features, a new approach is
necessary, like CommonSurfaceShader that exposes useful functions, or
my compositing shaders extensions (that makes shader languages
actually useful with X3D). See below.

> I would love it if there were a clear and/or simple way to specify: Diffuse,
> Specular, Diffuse+Specular, Diffuse+Bump, Specular+Bump,
> Diffuse+Specular+Bump, etc. And easy ways to specify Self-Illuminated,
> Lightmap (shadows), Parallax, etc. Note Bump being Normals or Displacement
> (Height). These are all just combinations of RGB(A) textures, right?

Current multi-texturing approach in X3D is completely not ready for
this. MultiTexture nodes in X3D allow you to manually specify how
textures mix with each other, but there's no mechanism to say what
"functional role" the texture has.

To allow what you describe, I would propose to include
CommonSurfaceShader from InstantReality
(http://doc.instantreality.org/tutorial/commonsurfaceshader/ ) as X3D
standard. But that's a completely different beast.

And at the same time I would like to make explicit shader code (like
GLSL) more useful with X3D. So that it's not a problem to e.g. invert
a texture alpha in single line of GLSL code, without breaking the rest
of the rendering. For this view3dscene and Castle Game Engine have
extensions to add shader effects:
http://castle-engine.sourceforge.net/compositing_shaders.php .


More information about the X3D-Public mailing list