| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| gamedev:renderables [2012/12/01 17:30] – dragonlord | gamedev:renderables [2019/05/24 23:43] (current) – ↷ Links adapted because of a move operation dragonlord |
|---|
| | {{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> |
| |
| 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. |
| |
| ====== Render Target ====== | ====== Canvas View ====== |
| 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. | The content of the texture is the output of a [[gamedev:canvassystem:view|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. |
| |
| 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. | 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 view. Using 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 components) is usually not too much slower while using complex worlds (for example camera in the same game world) is slower. |
| |
| ====== Camera ====== | ====== Camera ====== |
| ====== Video Frame ====== | ====== 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. | 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 half column centeralign> |
| | </WRAP> |
| | </WRAP> |
| | |
