API Reference · Materials and textures
Texture
public sealed class TextureAn image: either encoded bytes (PNG or JPEG) or raw RGBA pixels.
Decoding is deferred to the renderer, and deliberately so: a scene like Sponza carries twenty-five of these, and decoding them all up front allocates hundreds of megabytes at once — which is survivable on desktop and is not in a 32-bit WebAssembly heap. Raw pixels are deferred the same way: they stay in managed memory until a renderer uploads them, and the same streaming budget applies.
Use Texture.FromPixels for anything generated at runtime. Encoding a procedural texture to PNG only for the renderer to decode it again is pure round-trip waste, and it lands on the thread that can least afford it.
Textures are shared by identity, like Mesh; the same instance on many materials is uploaded once.
Properties
| Member | Description |
|---|---|
| How this texture's bytes are encoded — sRGB, linear, or whatever the slot expects.
Honoured the same way on every renderer, at upload or decode rather than in the shaders: the bytes are re-encoded once into what the slot expects. An eight-bit linear image through a colour slot keeps eight bits of sRGB, which is coarser in the darks than the linear original; for values that have to survive exactly, keep the map linear and put it in a data slot. It has no effect on an environment image or on a sprite's texture. |
| PNG or JPEG bytes, exactly as they came from the source file. Null when this texture carries Exactly one of the two has to be set, and prefer |
| How the image is sampled between its texels. |
| What
|
| Height in pixels. Only meaningful with |
| Whether this texture's bytes are block-compressed and must go to the card as they are. |
| Whether this texture carries raw pixels rather than encoded bytes. |
| Where each mip level begins in Compressed textures carry their own chain: a block format cannot be filtered down by |
| Optional name, carried through from the source image for diagnostics. |
| Tightly packed RGBA8, row-major, top-left origin: |
| How many times |
| Width in pixels. Only meaningful with |
| How the horizontal texture coordinate behaves outside 0..1. |
| How the vertical texture coordinate behaves outside 0..1. |
Methods
| Member | Description |
|---|---|
| A block-compressed image, in bytes the card can take without decoding.
|
| How many bytes one level of a compressed image takes. Block formats round up to whole blocks, which is why a 5×5 BC1 image is the same size as an 8×8 one. Getting that rounding wrong is how a payload comes out short by exactly one row of blocks, which the driver reads past the end of. |
| A tileable detail field: a value, its own gradient, and a finer octave, packed into one texture.
|
| A texture from PNG or JPEG bytes, decoded by whichever renderer first needs it.
|
| A texture from raw pixels, for anything generated at runtime.
|
| A string, drawn into a texture, sized to what it actually measured. The measuring is the reason this is here rather than in the application. Drawing text into an image is a few lines of Skia and any host can do it; knowing how wide the result came out is what a quad in a scene needs and what a host cannot hand over with the pixels. Miss it and every label is stretched by however far the guess was out — which on a face that fell back to a substitute is a different amount for every string, on the machines least likely to be the ones it was authored on. The image is tight to the ink plus whatever
|
| A radial glow: opaque and white at the centre, fading to nothing at the rim.
|
| Tileable fractal value noise, grey in RGB and opaque.
|
| A normal map from a height map.
|
| Says that A texture is cached by identity, so a renderer that has uploaded one never reads its bytes a second time — which is right for the overwhelming majority of textures and wrong for the few that change: a video frame, a minimap, a procedural map being animated, a game drawn into a buffer. The obvious workaround is to build a new So: keep the instance, write into the array you gave it, and call this. The handle already uploaded keeps being drawn — showing the previous picture, which is at worst one frame stale — right up to the moment the new pixels replace it. Nothing is ever white and nothing is allocated. |