User Tools

Site Tools


gamedev:renderables

This is an old revision of the document!


Dynamic content using Renderables

Skins provide only static texture content to be applied to meshes. Transforms can be used to manipulate the texture coordinates to create simple textures giving the impression to be dynamic. For fully dynamic textures though you need renderables. For most texture properties a renderable name can be specified. This name identifies uniquely a renderable in the parent component. Once a renderable with the matching name exists the content of the texture property uses the content found in the renderable. Renderables can be used for all kinds of texture properties including single value ones. What kind of content a renderable has to use depends on the texture property in question. Since you can use the same renderable name for multiple texture properties it is advised to ensure the properties having compatible types since a renderable can have only one type of content. How you interact with renderables depends the Scripting Module of your choice. Renderables can have the following content:

Single Value

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.

Color

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.

Image

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.

Render Target

The renderables uses a temporary texture created on the fly by the Graphic Module if required. Render Target renderables can be applied to all texture properties requiring an image. Render Target renderables are similar to images but are a lot more flexible. Instead of using an image stored on disk or created somewhere during run-time a Render Target renderable provides you with a dynamic texture that you can render to each frame update. This is the preferred way to simulate interactive monitors where you can render entire application interactions right into the texture. Speed and efficiency is crucial for this kind of renderable therefore a couple of special rules apply. The Graphic Module determines for each frame update which renderables with render targets are visible. For all those a temporary Render Target Resource is provided by the Graphic Module. The game developer is not required to do this juggling on his own. For each renderable a callback is used then ( see the Scripting Module of your choice to learn how this callback gets to you ) requesting the game scripts to render the texture into the provided render target. To further speed up this process render target renderables have a dirty flag. If the game changed in a way requiring the texture to be recreated the renderable can be marked dirty. The Graphic Module can optimize the rendering behavior and request texture updates from the game scripts only if necessary.

Even though render targets are fast to use if done correctly it is a good idea to avoid littering objects with render target renderables in close proximity since during each frame update they can potentially trigger an update of the renderables. Use the dirty flag to avoid not required updates if the texture stays the same ( for example the user reads something on a monitor and does not interact with the computer over a longer time period ). If a texture reaches a final state ( for example the monitor is shot and does not change anymore ) or tends to stay the same for a very long time consider replacing the renderable with an image renderable using a copy of the last update you rendered ( you can turn a render target into an image if required ). This way the Graphic Module can better optimize rendering. Experiment around with Render Target renderables to find the best trade-off between speed and eye candy.

Camera

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.

Video Frame

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.

Links

You could leave a comment if you were logged in.
gamedev/renderables.1354230379.txt.gz · Last modified: 2012/11/29 23:06 by dragonlord