This is an old revision of the document!
The Drag[en]gine game engine uses a very open and flexible way to handle skins for models. Instead of defining hard coded material properties that can not be changed anymore the principle of dynamic texture properties is used. A texture property defines one property of a material the texture composes of. A texture property is identified by a unique name which defines what corresponding material property is altered. The names are not defined by the game engine itself. They can be chosen arbitrarily as long as the various modules ( Graphic, Audio and Physics ) and the Artists attribute the same meaning to the same names. For this purpose a list of texture properties is maintained here providing texture property names and their intended use. Modules and Artists should stick to this list of texture properties for existing property names but can of course introduce new ones to enhance the engine.
Properties can define a material property in various ways.
Defines a static value for a property. Static values are different from colors in that they can have any value outside the range from 0 to 1. Colors on the other hand are limited to this range since images can not define colors with values outside this range.
Defines a static color for a property. In contrary to static values a color can only hold values between 0 and 1 inclusive for all 4 components. Many properties require only 3 components ( RGB colors ) in which case the 4th component is left unused.
Defines the property using an image. The UV coordinates stored in a mesh are used to index into the image. The range of UV coordinates is matched to the size of the texture with uv=(0,0) being the upper left corner and uv=(1,1) the lower right corner. The format of the image can be 8-bit gray scale ( often called intensity images ), 32-bit RGB ( 3-color image ) or 32-bit RGBA ( 3-color image with alpha channel ). In memory the image is arranged in the same way in row order from left to right and top to bottom without any padding. Specifying a static color for an image is allowed but not the other way around.
Defines the property using an video. The UV coordinates stored in a mesh are used to index into the video images. The range of UV coordinates is matched to the size of the video with uv=(0,0) being the upper left corner and uv=(1,1) the lower right corner. The format of the video can be 8-bit gray scale, 24-bit RGB or 32-bit RGBA. A video is automatically played back using a play speed relative to the update calls done to the world object containing a component with a video texture property. In contrary to videos used over renderables the control over static videos is limited. Specifying a static color for an video is allowed but not the other way around.
All types mentioned above produce a static texture. These textures are the fastest ones and require the least memory as the individual parts of the texture can be reused. Sometimes though complex and dynamic textures are required. For this a source can be specified. A source is the root of a tree defining the production process of a texture. This method is very flexible but also not that fast. If you need highly dynamic textures have a look first at renderables and use self painted images of video frames instead. With the growing artistic content of games it is a good idea to avoid costly textures. Specifying a source overrules image and static color but not renderables.
A source can be either a producer or a combiner. A producer omits a value or an image and resides in the leafs of the tree. Combiners reside at the nodes and take one or more sources combining them into a new value or image. Furthermore sources can be static or dynamic. Most sources are static and produce the same content every time they are invoked. Dynamic sources have controllers that can be manipulated during run time using the Skin State of a Component. Dynamic sources should only be used if there is no other way since they tend to eat quite some time since the textures have to be updated each time a controller changes.
In addition each texture property can be assigned a renderable name. Using static colors or images a texture is static and has the same look all the time. Using renderables though you can change individual texture properties on the fly during a game. The renderable name is not required to be unique and allows therefore to use a renderable content for more than one texture property simultaneously. Once specified the user can add a renderable to a component and fill it with appropriate values. A renderable overrules the static property as soon as the renderable name is not empty and a component contains a dynamic skin with a renderable of the same name. You can thus use a renderable to dynamically alter a texture property or let it be static if not used. This gives a lot of flexibility even if you don't know if a component is actually going to provide dynamic content or not.
Each property can have a transfrom assigned. Transform are used to manipulate the incoming texture coordinates before they are used for texturing. Transforms are similar to sources in that they are also organized in a tree shape. The advantage of transforms is that they are very fast and produce textures looking dynamic although they are not. Whenever possible use first a transform to animate a texture and resort to renderables or even sources only if there is no other way.