Revision as of 17:24, 10 March 2008

subtitle: CrazyEddie broke my renderer

This article is intended to be a fluid piece that I will change and update as the work on the Renderer modifications is done. It's not intended as a dry, serious piece, although any technical details and such like should all be accurate.

The general goal of these modifications is to complete the 'Renderer enhancements' item from the old 0.6.0 roadmap. These items were described as:

• Renderer enhancements
  • Allow for several GUI in several context.
  • Whole window caching.
  • Each Window is attached to a rendering target.
  • Optimised non queued drawing operations.
  • General rendering optimisations.

Renderers - times are changing

To date, all rendering was done by the renderer - that's why it had that name. The new RenderTarget system breaks this functionality out of the renderer and places it elsewhere. Under the new arrangements the renderer is set to become more of a utility and factory class; mainly creating various objects that target the associated underlying API or engine, and offering support functions as required.

What is a RenderTarget

A RenderTarget is a class of objects that can be the target of rendering operations (duh!). Basically it's a generic interface to 'anything' that can be rendered to (obviously a concrete class must be implemented to support it). In general there are, or will be, two broad types of RenderTarget. The first is a 'view port' type target - this directs rendering to the screen (or a portion of it). The second type is a 'texture' type target - this directs rendering to a texture of some kind. Texture targets are useful within CEGUI for caching the imagery of window objects, though outside of CEGUI there may be various more exciting uses.

Multiple GUI Roots

The main other addition will be that the system will eventually support multiple GUI 'roots'. Each root window will have its own root RenderTarget and so offer the ability to have different GUIs in different viewports, or maybe targetting textures to have GUIs appearing on items 'in game'.

Code Location and Status

This experimental code is currently living in its own branch of subversion named 'rendertarget-devel'. It will remain here until such time it is decided that the changes are stable enough to become the new main trunk code. This will be some time after the next stable version of CEGUI gets released.

This code will likely feature in the release after the next release - as long as it proves stable enough.

Discussion / Bug Reports

If you wish to offer some opinion (but not to nag me) about some aspect of this area of development, or report some bug that is directly related to this area of development, please post in the following forum thread http://www.cegui.org.uk/phpBB2/viewtopic.php?p=13606.

Updates at last!

It's been a while, so I thought I'd better update the page with the latest news.

Some General Things

The looknfeels are updated to enable full imagery caching for FrameWindow - which largely benefits the CEGUI demos (in the real world, if FrameWindow is not used, it would be possible to create a window type based on DefaultWindow that does caching - it's also possible to enable / disable caching as needed in the Layout files. The exact approach to caching will depend hugely on your usage of the system).

I also want to improve the way things are handled in respect of 'screen area' changes and 'clipping area' changes. Currently when a window is moved, it always causes a 're-execution' of the drawing of queued quads on a RenderTarget (here we're talking about a caching target) - this is hugely wasteful, since mostly all we need to do is to draw the same cached imagery quad (meaning the whole window is drawn as one quad). So that's one area where real improvement will happen - though even as it is, it does better than before due to the fact that any other (unaffected) windows are indeed drawn as a single quad.

OpenGL Renderer

The initial implementation pass on the OpenGL renderer is now completed, although there is still work to do and much polish to be applied.

The OpenGL renderer now has a view port type target - which basically does the same job that the old renderer did, and a handful of texture based targets which can be used for caching window rendering giving a significant performance boost. The texture targets all require some kind of render to texture support from the card and underlying OpenGL implementation; so far there are targets that make use of the framebuffer object extension (for Windows and Linux), an implementation using the pbuffer support in GLX 1.3 (Linux / X only), and an implementation using pbuffer extensions in WGL (Windows only). If no such RTT support is available, the system will fall-back to the non-caching viewport roots and give generally the same results as under the old renderer system.

There have been other general improvements to the way that rendering is done. The huge impact on performance when rendering many quads 'directly' has been reduced to a very large degree. Work has also been done to improve the performance overall (though mainly when using the texture caching); there is a bare minimum of state changes and what have you going on now - although that's not to say things could not improve further before this gets released!

There are still some issues (obviously). The drag/drop type windows need some re-writes to the rendering code so that anything being dragged bypasses any intermediate targets and gets drawn directly on the root RenderTarget. This solves the 'clipping' issue (where the dragged content gets moved outside the available size / range of a caching texture), and also (hopefully) the funky blending issue that shows up too :)

Currently the 'Multiple GUI Roots' item is not in a working state - most of the underlying systems are in place (since it's largely a side-effect of having RenderTargets), though a reworking of a couple of CEGUI parts are required and I'd rather do that after I have another working renderer. So, enter my next task...

Ogre Renderer

A couple of weeks ago I 're-adopted' a copy of the files for the renderer into the CEGUI codebase - this will not be a permanent arrangement; it was done to make life easier while the changes are made. Due to the nature of these changes, once it's all up and running I'll have to liaise with the Ogre guys to see how best to get the new functionality re-incorporated into the Ogre codebase (this is a way off though, since it will need to coincide with releases from both projects).

I have today (10th March 2008) committed the initial take of the code of a rewritten Ogre renderer that can support the RenderTarget model. This code was heavily influenced by the rewritten OpenGL renderer, but also re-uses segments of the original Ogre renderer. The code is not yet in a finished state, but once it's built the results are, as they were with the OpenGL version, extremely promising.

The main renderer class changes from using a collection of constructors to a single unified version. This is an interface breaking change, but was needed to firstly support using any Ogre based render target as the primary target for CEGUI, and also to streamline the parameter order so that 'defaults' can more logically be applied.

As with OpenGL we have a texture target (which is used as the cache type), and an OgreRenderTarget target that can send CEGUI rendering to any render target from Ogre.

Currently the code for the Ogre renderer is using the Ogre project convention of prefixing CEGUI includes with 'CEGUI'. I have maintained this use because it is the intention that eventually this code will be moving back into Ogre, so maintaining their convention is intended to ease that process. The downside is that while we have that code in our repository, none of the includes will be found. To resolve this you need to either mirror a copy of the includes in a CEGUI directory at the top level, or do as I have done and create a symbolic link from 'cegui_mk2/include' to 'cegui_mk2/CEGUI' (Windows people can do this via a Junction Point – a good tool for creating / editing these can be found at http://sourceforge.net/projects/ntfslinkext).

Now I have two working renderers, I will spend some effort fixing some of the little bugs that exist in relation to the caching render targets, and also to do a little work towards multiple simultaneous gui 'roots'. When I get bored with that I'll update the Direct3D 9 renderer (the 8.1 renderer is earmarked for removal from the system, see: http://www.cegui.org.uk/phpBB2/viewtopic.php?t=3013).

Mini FAQ

This is a mini FAQ. It's kind of a repository for questions and comments that are likely to come up regarding the RenderTarget changes in CEGUI. It's not exhaustive, and it's not supposed to be.

Why are you doing this?

• In any project it is important to try and keep moving forwards. This is my attempt to address some known issues and also offer other some new functionality into the bargain.

Isn't this just some quick fix? A reaction to other projects?

• No, not at all. These changes have been planned for a long, long time (since before some of those 'other projects' even existed), and were originally intended to be in and fully tested for the 0.6.0 release that would originally have been out late Q1 2007.

So, why now?

• The main reason it wasn't done before now is because I was not around to work on the project at all, and other developers have had other things to do also. Since I have a little time to give something to CEGUI, I thought I'd try and give it something important.

You broke all the Renderers!

• Yes, I did. This is the first time the renderer interface has significantly changed since the inception of CEGUI-Mk2 in 2004.

Why did you do the OpenGL renderer first? I do not use this renderer!

• Well, I had to start somewhere! OpenGL is the one renderer that will run on all systems without requiring additional dependencies. Since it's also one of the lower-level renderers it served as a good choice for the 'reference code'.

When will the Renderer for <my engine> be updated?

• As soon as it gets done. By the time this code features in an actual release, all the existing renderers will have been updated for the new Renderer model.

I have no RTT support, this means I will no longer be able to use CEGUI!

• Not true - these changes are well designed. If it happens that such support is missing, the system should operate no worse than it did before.

Now rendered imagery is cached, you'll be using up all my video RAM!

• Not true - these changes are well designed. It is possible to disable caching to texture on various levels depending on the requirements you have.

I have volatile window content. since you're caching to textures, my performance will be worse!

• Not true - these changes are well designed. If you know that your window will suffer due to its volatile nature, you can turn off caching for just that window (leaving it enabled on others if so desired).

I have found a bug! Are you interested?

• Yeah, I'm interested. Within this context I'm more interested in bugs affecting the new Renderer / RenderTarget code only, as opposed to bugs in the core of CEGUI (which I am interested in, but post those on mantis as usual). What I'm not interested in is people telling me that their renderer module is broken (I know this already, I'm the one that broke it!), or that some other module in CEGUI needs updating (again, I already know). Please use this forum thread.

Is CrazyEddie back in charge of CEGUI?

• Nobody is 'in charge' of CEGUI. CEGUI is free software.

I don't like CEGUI. It sucks, and CrazyEddie sucks too!

• Why are you wasting your time here then? Personally I couldn't really care what some nobody on the internet thinks; I have better ways to spend my time.