Texture System

From Skycastle

A procedural texture system.

Can be used for things like defining creature and other object textures.

The procedural textures will be rendered in the background on the client when needed, possibly at increasing resolutions. They are not meant for real-time rendering on the graphics card.

The textures can take constant parameters, as well as per pixel parameters (defined at the corners, and interpolated over the area).

The textures can have arbitrary output channels with floating point values. The rendering engine will probably be able to use RGBA channels as well as normal and bump maps, and possibly specularity, as suitable shaders are implemented.

[edit] Status

• The core engine is now implemented: compiled procedural textures blog entry -- zzorn 2007-09-09
• A blog entry by zzorn on the procedural texture system (2007-09-06).

[edit] Data Flow

Types of parameters:

• Constants, for a texture. These parameters are provided when the procedural texture is created, and are not changed during rendering.
• Corner parameters. These are provided for each corner of the texture to be rendered, and are interpolated over the textured area.
• Per pixel parameters. These are the interpolated values of corner parameters.

This procedural texture approach differs to some degree from classical ones, that use 2d or 3D coordinates as input for each pixel. Instead, we support a number of per-pixel parameters, that can be interpolated

[edit] Compiling

A procedural texture generator instance is generated from a design, by having each component provide a piece of source code, and then compiling it to bytecode. This way rendering will be as fast as possible.

[edit] Component connections

Supported parameter types:

• double
• Vector2
• Vector3 (for colors and normals and such)
• Vector4
• String? (for embedding text in a texture, e.g. for signs and such in the game world)

Components can provide inputs and outputs of these types. The inputs and outputs can be per pixel or per texture. Per pixel output parameters actually return an interface that can be queried for the value, given some pixel parameters.

[edit] Types of Functions

Components could be treated as functions also.

E.g. float => float, (float, float, float) => (float, float), PixelParameters => (Vector3, Vector3, float), etc.

In this case we are simply specifying the source where we get each input parameter as a constant value, or as an output of another function.

The components could simply be scala functions wrapped in a component container that has names for the inputs and outputs, and remembers where the inputs come from.

[edit] Components

• Various float => float functions
• Circles (using some point distribution)
• Stripes
• Perlin Noise
• Vornoi Cells - see algorithm at: http://www.blackpawn.com/texts/cellular/default.html

More complex components can be built from these basic ones, and added to the component library.

[edit] 3D shader based implementation?

A 3D card could probably calculate many of the functions faster in parallel, but it might be a bit tricky to interleave with normal rendering.

And some operations might not be possible on a 3D card (like text - a bit awkward, although maybe a font texture could be indexed).

Still, it's a natural solution for this problem, so it's worth considering. It could also render the result directly to a texture, avoiding the need to move the rendered texture from the PC to the card.

On the other hand it would complicate the implementation, and could have card specific issues.