TextureTransformMatrix3D,
TextureTransform3D,
TextureCoordinate3D,
TextureCoordinate4D,
ImageTexture3D,
ComposedTexture3D,
PixelTexture3D
3D textures, coordinates for 3D textures, transforming
coordinates for 3D textures — all done.
Note that 3D and 4D (homogeneous) coordinates, and transformations
in 3D space / by 4x4 matrix, may be used to transform 2D textures as well.
In case of 2D textures, the 3rd component is just ignored
and the 4th is normal divisor (as usual for homogeneous coordinates).
DDS file format to specify 3d (volume)
textures is supported by ImageTexture3D.
Note that PixelTexture3D with RGBA values has a
problematic behavior because it uses MFInt32 field for colors.
When you encode RGBA colors (following SFImage specification),
the most significant byte of Int32 may have to be non-zero,
which means that you will have to write negative values
inside PixelTexture3D.image. (Of course we handle it correctly,
I'm just signalling there's a strangeness here. For normal
SFImage fields this problem doesn't exist because our lexer
can actually understand integer values outside of int32 range, so when parsing
SFImage this is handled Ok, without going through int32.)
Automatic 3D texture coord generation for primitives (Box,
Sphere, Cone, Cylinder) is done
(according to X3D spec, 33.2.4 Texture coordinate generation for primitive objects).