Development:Ogre:Docs:GUI
 Development:Ogre
|
Contents
Unified User Interface
Reminder
This is a WIP. As such... don't:
- Rely on it
- Whine about incompleteness
And please, don't fill missing links - I (klauss) will, when I have something to type in them, for I might decide to remove them instead (and them having something inside will make that task... undesirable...). Feel free to remind me to do so, though.
Overview
The usual distinction between cockpit GUI, VDUs, maps, and bases will disappear. Under the new framework, there are only UI Targets, and UI Elements. The screen being one special UI Target - special in meaning, but not in usage.
Targets do not receive focus. Rather, elements do. UI Elements are of many kinds, and even will accept plugins. Example of UI Elements are buttons, pictures, gauges... anything displayable or interactive - either. Non-displayable but interactive UI elements include keyboard handlers, for instance. Non-interactive but displayable UI elements would include pictures and gauges. Non-interactive and non-displayable elements, however, have no place in the UI Framework.
Capabilities
What can you do with it?
- Very powerful base interfaces, completely customizable (you only will have to code a lot in python if you want to override too much of the built-in functionality)
- Very powerful and interactive VDUs (they use the same framework, hence can do all the things base interfaces can)
- Texture targets will allow placement of interface screens (including VDUs) on 3D meshes, enhancing visual possibilities.
- External cameras - you can define a 3D camera, in the 3D world, and a viewport associated to it, and place that as an interface element in both cockpits and base interfaces - effectively implementing external cameras. Want to see what's going on on the outside?
- Simple stuff - easily. I intend to make it very powerful, but easy to use when you want simple stuff. There's no need to make implementing a point-and-click interface worth a thesis.
- Data-driven interfaces - simple ones - should boost moddability. Hence, base layout scripts will be designed, to be able to describe the most common point-and-click interfaces. Some code may be needed, and embedded in them, but it should be rather simple - javascript-like.
How-Tos
Using Texture Targets efficiently
Texture targets are powerful. But if misused, they have also the power of crippling performance. Avoiding that, means following the following rules:
Gauges and VDUs
Gauges will most likely be implemented as UI elements assigned to a Texture target, and 3D meshes or 2D overlays using that texture for rendering. It is very compelling the notion of having one texture for each gauge, because of the simplicity in unwrapping the geometry, for instance. But that must be avoided, because many gauges implemented this way would hinder performance. Rather, a single texture target for all gauges would be preferred.
- Create one texture target for all gauges
- Create one texture target per VDU
- Do not reference texture targets inside a texture target. I need not say, you mustn't reference the texture target you're rendering... but might (although not recommended) reference others.
- Allocate space for gauges in blocks never crossing power-of-two boundaries. That is:
- Make the size-in-texture of a gauge have power-of-two dimensions (not necessarily equal)
- Place it in the texture in such a way that it does not cross MIP-thresholds (see later)
- Try to make all gauges render at a similar resolution, to make MIP-threshold selection easier.
- Try to use 256x256 textures. Failing that, 512x512. Failing that, 1024x1024. Failing that... reconsider your GUI layout. (smaller textures are possible, of course, but I would reconsider my layout if I deemed acceptable the use of such - it's possible you would be abusing of texture targets).
- MIP-threshold selection: Select the biggest gauge. Compute log2(Dt/Dg) with Dt being the texture dimension, and Dm being the biggest gauge's dimension for each axis. Select the minimum of those, and use it as maximum MIP level for the texture (see TextureTarget). If the number is too low, it may be harmful - tweak it as you please, but if you have to, I would suggest you reconsider gauge space allocation.
