Best way to render into a window using latest CEGUI

[Liberator]

I was wondering whether there is an optimized way of rendering to a window in CCEGUI in a way that does not really effect performance to badly.

This is the Ogre article on it (see render to texture section:
http://www.ogre3d.org/wiki/index.php/Basic_Tutorial_7

I have a API in my framework that wraps GUI libraries and I use CEGUI trough a GUI driver I made. I was thinking of adding support for a RenderContext Widget which would be defined as a widget that gives you an optimized section to render in that can be embedded within other GUI widgets which in the case of the CEGUI driver can then be a CEGUI FrameWindow or something similar.

I'm thinking of defining a custom CEGUI widget that I can hook to and detect from a .layout file. Such a widget should ideally not do anything at all with the contents of the window and if possible provide an easy to use API for updating the CEGUI texture used if a texture is required, although again I'd prefer to delegate rendering control completely.

Suggestions are welcome as to the best way to achieve this, the aim is finding the fastest method of rendering using Ogre into a CEGUI widget.

[CrazyEddie]

Hi,

The main issue with trying to perform direct rendering is that CEGUI content is not rendered to the display when it is 'drawn'; rather the imagery to be drawn is queued and/or batched (for performance reasons, obviously).

This gives rise to the situation where if you were to hook into the window and render something directly at that time, it would not appear where you want in the final output. So, anything you 'render' needs to be done so by queuing quads to the renderer - which basically requires the use of rendering to texture so that that rendered content can appear on a CEGUI window.

This gives rise to the situation where effectively the texture and area of the texture to be drawn never really changes (just the content of the texture), so that information could be put into the render cache and forgotten about. Leaving just the job of updating the texture content; this could be done in the Window::drawSelf member if desired, although whether that is the most optimal way would be debatable.

So, not many real answers there, I know, but it's certainly an interesting discussion

CE.

[Liberator]

I was thinking maybe a solution could be overlays,.. you render the entire CEGUI GUI as usual (allowing caching of the entire GUI) and then we could add support for an additional render pass that renders just the overlays for the non occluded overlay sections. The same as video overlays in win32 which are rendered from hardware as a second pass ontop of the win32 GUI.

This method would require adding support for the additional loop in CEGUI which should not be that hard apart from the occlusion tests. Then we would have to make a simple overlay interface class with an API CEGUI can understand and control,.. just the non-occluded quads of where we should render.

Code: Select all


class IGUIOverlay
{
     virtual void RenderOverlay( const TQuadList& renderSurfaceList ) = 0;
}



This would basically give you the options of adding a more immediate mode rendering using the rendering backend of choice while taking advantage of CEGUI's window occlusion testing without contaminating CEGUI with renderer specifics. Plus since it's a second pass the first pass render pass would work as normal allowing caching of the GUI texture.

What do you think?

[CrazyEddie]

Yeah, this is a definite possibility for a solution that would work. Obviously there may be some decisions and trade-offs to be made for example with regards to such things appearing behind alpha blended parts - although if that was an established limitation then obviously there would be no issue.

I'd already been toying with the possibility of adding some level of occlusion testing for CEGUI windows (as part of the renderer updates), although I did not make any decision as to whether to actually go ahead with it, nor as to how to do it, but it is something that I'm happy to consider having in the system.

So in conclusion, I think the idea you describe has potential

CE.

[Liberator]

Without the occlusion testing we would have an overlay, lets say video, that is always rendered as the complete quad. This is something we could add to CEGUI in mere minutes using the API/technique as described. Passing in the CEGUI widget that holds the overlay should do the trick. The obvious downside would be that if you move another window partially over the window that has the overlay on it then it would appear to have moved behind the overlay instead. But for now we could just make our layouts such that we don't have that scenario until occlusion testing becomes available.

In regards to alpha blending... I'd leave that to the renderer rendering the overlay. IF the implementor of the overlay renderer chooses to render to a texture for example which has an alpha of 0.5 then you have your transparent overlay. Since your rendering in immediate mode there are few limitations.

[CrazyEddie]

Ok

I'm hoping that some concrete ideas, as far as designs go, will arrive from that portion of CrazyEddie's brain this coming weekend; the occlusion testing may not be so far off either, depending how things pan out.

If you want any mods you make to be incorporated (most likely for >= 0.7.0), just stick the patches onto Mantis.

CE.