This component defines nodes for using 3D textures. 3D textures often allow a simple coordinate mapping, and enable a variety of graphic effects, particularly since they may be utilized by Programmable shaders component shaders. 3D textures may be loaded from image files or inlined in the VRML/X3D file. 3D texture coordinates may be specified explicitly or automatically generated, and they may be transformed.
TextureTransformMatrix3D (API reference),
TextureTransform3D (API reference),
TextureCoordinate3D (API reference),
TextureCoordinate4D (API reference),
ImageTexture3D (API reference),
ComposedTexture3D (API reference),
PixelTexture3D (API reference)
3D textures, coordinates for 3D textures, transforming coordinates for 3D textures — all supported.
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
PixelTexture3D with RGBA values has a
problematic behavior because it uses
MFInt32 field for colors.
When you encode RGBA colors (following
the most significant byte of Int32 may have to be non-zero,
which means that you will have to write negative values
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 (
Cylinder) is done
(according to X3D spec, 33.2.4 Texture coordinate generation for primitive objects).
Copyright Michalis Kamburelis. Thanks go to Paweł Wojciechowicz from Cat-astrophe Games for various graphics. Even this documentation is open-source, you can redistribute it on terms of the GNU General Public License.