The renderable stores a single floating point value which is not limited in any direction. Single value renderables can be applied to all texture properties but their value can be clamped to the [0-1] range if used for colors. Usually this used for texture properties requiring a single value themselves.

The renderable stores a 4 component color value. The value of each component is limited to the [0-1] range. Color renderables can be applied to all texture properties requiring a color or an image. Only the required number of components are consumed from the renderable. Hence if a texture property requires only one component only the first component of the color is used the rest ignored. Using a color for an image texture property defined an image of arbitrary ( at the discretion of the Graphic Module ) size with all pixels initialized to the given color.

The renderable stores a reference to an image resource. Image renderables can be applied to all texture properties requiring an image. This is a fast and efficient way to use dynamic textures since the images can be kept by the Graphic Module in accelerated memory. Switching image each frame is therefore fast and recommended if the same images are used. A typical example for this would be a monitor displaying a couple of different images depending on player input.

The content of the texture is the output of a canvas view. The size of texture image is specified by the renderable. To get a proper 1-to-1 mapping the size of the canvas view and the renderable size has to match. If not matching the image is scaled to fit. This allows to reuse canvas views on different renderables with different sizes if required. The graphic module updates the texture if needed, for example if an object is visible or not or if the canvas view content changed or not. If multiple render targets use the same canvas view the graphic module updates the canvas view only once and reuses the output.

Canvas view renderables are the most flexible solution since you can use the same canvas system for producing your textures as you use for rendering your entire game. In particular you can use it to create 2D monitor displays mixed with 3D renderings using cameras without having to worry about the details. The render performance depends on the content of the canvas view. Using pure 2D content (hence not using render world canvas) is the most fast. Using simple scenes with a render world canvas (for example a virtual status view of an object with a world containing only one or two components) is usually not too much slower while using complex worlds (for example camera in the same game world) is slower.

The renderable uses a camera to render the content of mesh faces covered by texture properties using this renderable. Camera renderables can be applied to all texture properties requiring an image. The camera renderable is similar to the render target but it does not produce a texture. Imagine the functionality of an image render target as if the faces using this renderable are a mask on the rendered screen. Rendering the same scene using the camera only affects the pixels covered by the renderable. This can be used to simulate all kinds of portals you can look through into a different part of the same game world ( also security monitors can use this to provide live feeds ).

Using camera renderables can be tricky especially speed wise. Rendering a scene multiple times never is cheap and can bog down the performance if used excessively. It provides though a high level of eye candy since all rules applying to cameras do also apply here ( modifiers, post processing effects ). It is also pixel accurate since the scene is rendered right into the one you are looking at. Sometimes it can be though better to render a scene into a texture of a given size ( like simulating a security monitor with limited resolution ). If this is desired or you need to apply particular 2D post processing or you want to use skin transforms use the render target renderables and render a scene into it like you would do for the main game camera.

As a side note camera renderables are slightly restricted in their use in texture properties. A camera renderable can only be applied to the diffuse texture property since it produces final pixels ( fully lit and post processed ). You can not use this renderable type on any other texture property.

The renderable takes the texture image from a video frame. Video Frame renderables can be applied to all texture properties using an image. You assign a video resource to the renderable and you set a time frame. The given frame from the video is then used as the image. This is the preferred way for using sequential textures playing a series of images. The speed is usually slower than with image renderables since video frames tend to be uploaded to the graphic card each time it is used. Depending on the usage in your game it might be better to use image renderables instead with a bunch of images loaded into memory.