CEGUI (Crazy Eddie's GUI) Forums

Hi,

we've been using CEGUI to mostly for simple things, such as overlaying our OpenSceneGraph based 3D application with semi-transparent panels and buttons. Everything we do is currently defined through XML layout files and with ImageSets.

Now our client has the requirement that we show and refresh some dynamic data, such as simple bar plots (with axes, and colored bars, possibly some text labels too).

I was wondering if it is possible to integrate CEGUI with 3rd party plotting toolkits such as MathGL. MathGL should be able to render using OpenGL APIs, and that in turn should integrate with CEGUI somehow. Alternatively MathGL can create image in formats like PNG, which we could load into CEGUI.

Any idea how to start with this integration? Is there some example source code showing how to do custom OpenGL rendering into a CEGUI widget, or alternatively displaying a graphics file (PNG) that may be updated (exchanged) at run time?

Christian

This has been discussed before in the forum and elsewhere.

Option 1: Use render-to-target and render whatever plots you want with whatever tool you want to a texture (OpenGL, Ogre, D3D, Irrlicht) and use that one as an Image that you render using a Generic/Image widget. See the wiki for an example http://cegui.org.uk/wiki/Rendering_to_t ... 9_in_CEGUI

Option2: I added Custom Shape Drawing as part of my last GSoC project - but this is, and can only be, available on CEGUI default branch (upcoming 1.0 release) Porting this to v0-8 is not possible. CEGUI default branch is unstable and not good for production use, we will break compatibility regularly and there are issues on that branch right now with performance (mainly).

I assume you want it now, so rendering whatever you want to a texture target is probably the best choice. MathGL sounds like it can easily be rendered to a OpenGL texture as render target. So use that.

Can you confirm that inheriting from FrameWindow and using a GeometryBuffer along with a RenderingSurface::addGeometryBuffer inside of FrameWindow::drawSelf call is not supported in 0.8.x? I am porting from 0.7 and this code will generate lots of what seems to be heap corruption crash in the rendering process.

I am referring to this tutorial :
http://cegui.org.uk/wiki/Performing_cus ... right_time

Could you please update porting tips related to this point?
http://cegui.org.uk/wiki/Porting_tips_a ... X_to_0.8.X

We used to draw custom data visualization directly in OpenGL inside of different dynamically created FrameWindows.

Thanks

I do not know much about 0.7 rendering, since I was not part of the team back then.

Feel free to update the wiki porting tips with all information you found.

If you need help with rendering please create a new thread with more specific info. I must say though that the Geometrybuffer approach is more or less a hack and therefore not really intended to be forward compatible. Doing RTT is a more viable approach and also "higher-level" on CEGUI-side, therefore will be more likely to still work on higher versions.

Now I see depth buffer is not used and I can't insert custom OpenGL code in between layers, all is hard coded to 0 depth... I will then modify my code to use render targets. Is it planned to use depth test in CEGUI 1.0? It would be so simple to add layers at custom depths in post CEGUI draw calls.

CEGUI uses no depth testing because it renders the window in back to front order. Since we allow semi-transparent windows we can't really use depth-testing anyways (unless fully deactivated), so there is no point to it.

You can make full use of OpenGL features using RTT rendering and then use the RTT texture in CEGUI.

In CEGUI 1.0 I implemented a new feature called custom rendering. While not being fully perfect yet, it does allow you to render custom shapes or even just upload custom triangles to CEGUI. We only allow solid colouring or texturing as inbuilt shaders for this. In the future we will feature gradient shading as well, as known from inkscape/illustrator and SVG in general.

I take it however that you need more complicated facets of OpenGL rendering, and due to this i want to direct you to the RTTs again. That's what I would use as well.