[X3D-Public] is MultiTexture for 3D textures as well as 2D textures?

[Michalis Kamburelis]

2011/8/2 Don Brutzman <brutzman at nps.edu>:
> Wondering, is MultiTexture node applicable to 3D textures as well as
> 2D textures?

It is definitely applicable to both 2D and 3D textures, and also to
cube map textures. IMHO, it would be weird (and would really hurt our
possibilities) to define it differently (like limiting it to 2D),
since hardware doesn't have such limitations. You really always use
multi-texturing commands when applying textures on GPU nowadays.

>        The texture field contains a list of texture nodes (e.g., ImageTexture, PixelTexture, and MovieTexture). The texture field may not contain another MultiTexture node.

Maybe this should be changed to

"The texture field contains a list of texture nodes (any
X3DTextureNode, with the exception of another MultiTexture node)."

That's how it's interpreted in my engine, and I believe this is
natural on GPUs, and makes a lot of effects possible (e.g. I
frequently mix mirrors by cube maps with other textures on a single
shape). If you have to list possible children of MultiTexture.texture,
you can say "X3DTexture2DNode, X3DTexture3DNode,
X3DEnvironmentTextureNode", but it's probably easier (and more
future-proof) to just say "anything except another MultiTexture".

There are also extensions like
http://doc.instantreality.org/documentation/nodetype/RenderedTexture
(also implemented in my engine), and my GeneratedShadowMap. They are
all allowed in MultiTexture.texture.

> There are 3 pertinent node interfaces:
>        X3DTexture2DNode
>        X3DTexture3DNode
>        X3DTextureNode

Again, remember there's also X3DEnvironmentTextureNode for cube maps.
This is something different (conceptually, and for GPUs) than both 2D
and 3D textures.

>
> a.  If applicable to both 2D and 3D, then no change is needed to the
>        MultiTexture node per se.  But we might need to change some
>        of the 2D texture transform operations in the Volume Rendering
>        component might to also allow use of MultiTexture with 2D nodes.

I don't know "Volume Rendering component", so can't comment about
changes needed there.

>
> b.  If applicable to both 2D and 3D, we probably ought to say that
>        combined operations with a mix of both 2D and 3D nodes are
>        not allowed at the same time.

Why? They are allowed, they mix without problems. You apply a 3D
texture with some texture coordinates, and it yields a color on a
pixel. Same thing with 2D texture, same with cube map. The colors are
mixed together, and with color from lighting equations, following
MultiTexture.mode.

Unless you mean that they don't mix for "Volume Rendering component"
--- I can't comment about that.

I'm going to read the "X3D Architecture and base components V3" spec
now. BTW, kudos for adding Volume Rendering to X3D -- I know at least
two people who were really interested about this, they'll be happy to
know that X3D 3.3 includes it :)

>
> d.  If applicable to both 2D and 3D, then we might also add the preceding
>        fields anyway, since it is reasonable to want to apply them to
>        the result of 2D multitexture operations.  In that case we
>        should likely also say that the fields are only appropriate
>        when using 2D textures.

This feels strange --- what exactly would be the meaning of
MultiTexture.repeatS (does it cause repeat on all texture units? How
does it cooperate with repeatS for particular units?)

Right now, every particular texture unit has it's own repeatS/T/R,
this is natural, no change is needed I believe.

>
> I hope that we have some multitexture experts who can shed light on this.
> We have an opportunity to make X3D v3.3 modifications/clarifications
> that is just a few weeks way.  TIA for all review.
>

I hope that my issues with multitexturing are fixed, I reported them a
couple of times. See
http://vrmlengine.sourceforge.net/vrml_implementation_texturing.php#section_multi_texturing_spec_problems
. Browsing "X3D Architecture and base components V3", they are not...

Michalis