User Tools

Site Tools


gamedev:renderables

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
gamedev:renderables [2012/11/30 15:49] dragonlordgamedev:renderables [2019/05/24 23:43] (current) – ↷ Links adapted because of a move operation dragonlord
Line 1: Line 1:
 +{{tag>graphic skin renderable}}
 <WRAP youarehere> <WRAP youarehere>
-[[:start|Start Page]] >> [[gamedev:main|Game Development with the Drag[en]gine]] >> **Dynamic content using renderables**+[[:start|Start Page]] >> [[:gamedev|Game Development with the Drag[en]gine]] >> **Dynamic content using renderables**
 </WRAP> </WRAP>
  
-====== 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: 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:
  
-<WRAP boxheader> +====== Single Value ======
-===== Single Value ===== +
-</WRAP> +
-<WRAP boxcontent>+
 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 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.
-</WRAP> 
  
-<WRAP boxheader> +====== Color ======
-===== Color ===== +
-</WRAP> +
-<WRAP boxcontent>+
 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 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.
-</WRAP> 
  
-<WRAP boxheader> +====== Image ======
-===== Image ===== +
-</WRAP> +
-<WRAP boxcontent>+
 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 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.
-</WRAP> 
  
-<WRAP boxheader> +====== Canvas View ====== 
-===== Render Target ===== +The content of the texture is the output of a [[gamedev:canvassystem:view|canvas view]]The size of texture image is specified by the renderableTo get proper 1-to-1 mapping the size of the canvas view and the renderable size has to matchIf not matching the image is scaled to fit. This allows to reuse canvas views on different renderables with different sizes if requiredThe graphic module updates the texture if needed, for example if an object is visible or not or if the canvas view content changed or notIf multiple render targets use the same canvas view the graphic module updates the canvas view only once and reuses the output.
-</WRAP> +
-<WRAP boxcontent> +
-The renderables uses a temporary texture created on the fly by the Graphic Module if requiredRender Target renderables can be applied to all texture properties requiring an image. Render Target renderables are similar to images but are 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 applyThe 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 ownFor 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 targetTo 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 renderablesUse the dirty flag to avoid not required updates if the texture stays the same ( for example the user reads something on monitor and does not interact with the computer over 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. +Canvas view renderables are the most flexible solution since you can use the same [[gamedev:canvassystem:introduction|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 viewUsing pure 2D content (hence not using [[gamedev:canvassystem:renderworld|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 componentsis usually not too much slower while using complex worlds (for example camera in the same game worldis slower.
-</WRAP>+
  
-<WRAP boxheader> +====== Camera ======
-===== Camera ===== +
-</WRAP> +
-<WRAP boxcontent>+
 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 ). 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 ).
  
Line 45: Line 26:
  
 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. 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.
 +
 +====== Examples ======
 +<WRAP group>
 +<WRAP half column box centeralign>
 +{{ youtube>PTyNnAOtOow?600x480 |Dynamic Content in Action}}
 +Dynamic Content in Action doing an interactive computer screen.
 </WRAP> </WRAP>
  
-<WRAP boxheader> +<WRAP half column centeralign>
-===== Video Frame =====+
 </WRAP> </WRAP>
-<WRAP boxcontent> 
-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. 
 </WRAP> </WRAP>
 +
gamedev/renderables.1354290592.txt.gz · Last modified: 2012/11/30 15:49 by dragonlord