[solved] Rendering GUI in 3D space ( Ogre )
Moderators: CEGUI MVP, CEGUI Team
[solved] Rendering GUI in 3D space ( Ogre )
We have a 3D scene in which we want to incorporate GUI elements. I presume the first step is to get CEGUI to render to a render target, which texture our object / quad with. So, what's the easiest way to get this going? The current approach I have in mind is using setRenderingSurface() to associate the render target with the GUI element, and then simply fire off a render() on it. Would this work or is the perhaps a better way?
Last edited by Sairon on Wed Dec 09, 2009 16:35, edited 1 time in total.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Re: Rendering GUI in 3D space ( Ogre )
Hi,
What you suggest as a possible approach is largely correct (but see below). In some future 0.7.x release this will be made easier still since such things have been planned for 0.7 from the start (though omitted so far due to the need to have new releases in a timely fashion).
A couple of points to be aware of in our related not-quite-ready-yet parts of the system...
The layout / root window for the particular UI in question will possible (or even likely) not be attached to the set GUI sheet. This means the regular System::renderGUI call will not update the rendering on this part of the UI - to overcome this, you need to perform the update yourself (so calling Renderer::beginRendering, clearing the target of imagery & geometry, calling Window::render for the root of the UI part, calling RenderingSurface::draw, and finally calling Renderer::endRendering - you might like to look at the code for System::renderGUI, since that's pretty much what you need to reproduce). NB: you likely will not want to do that *every* frame unless you like slow rendering, so the update should be done before the call to System::renderGUI, so you can check whether a redraw is required via System::isRedrawRequested.
The second potential issue is with input processing - currently this always uses whatever is set as the GUI sheet as the root, so you may have to take some action to work around this if you need to.
Lastly, at certain points in the system, basically when looking for the parent size of a root window, we currently always use the display size / size of the default rendering surface. This is technically incorrect and should use the size of the root rendering surface of any given UI hierarchy. Whether this is an issue at all will depend upon what you're doing exactly and what your expectations are.
CE.
What you suggest as a possible approach is largely correct (but see below). In some future 0.7.x release this will be made easier still since such things have been planned for 0.7 from the start (though omitted so far due to the need to have new releases in a timely fashion).
A couple of points to be aware of in our related not-quite-ready-yet parts of the system...
The layout / root window for the particular UI in question will possible (or even likely) not be attached to the set GUI sheet. This means the regular System::renderGUI call will not update the rendering on this part of the UI - to overcome this, you need to perform the update yourself (so calling Renderer::beginRendering, clearing the target of imagery & geometry, calling Window::render for the root of the UI part, calling RenderingSurface::draw, and finally calling Renderer::endRendering - you might like to look at the code for System::renderGUI, since that's pretty much what you need to reproduce). NB: you likely will not want to do that *every* frame unless you like slow rendering, so the update should be done before the call to System::renderGUI, so you can check whether a redraw is required via System::isRedrawRequested.
The second potential issue is with input processing - currently this always uses whatever is set as the GUI sheet as the root, so you may have to take some action to work around this if you need to.
Lastly, at certain points in the system, basically when looking for the parent size of a root window, we currently always use the display size / size of the default rendering surface. This is technically incorrect and should use the size of the root rendering surface of any given UI hierarchy. Whether this is an issue at all will depend upon what you're doing exactly and what your expectations are.
CE.
Useful Links: Forum Guidelines | Documentation | Tutorials | HOWTO | Videos | Donate to CEGUI | CEGUI Twitter
Re: Rendering GUI in 3D space ( Ogre )
Ah, thanks for the indepth response
Re: Rendering GUI in 3D space ( Ogre )
Got it working. The largest problem actually was me forgetting to handle device reset. Since CEGUI doesn't use RendererListner in the Ogre renderer there was some problems restoring the surface since doing it with a RendererListner didn't guarantee that CEGUI surfaces had been restored at that point.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Re: [solved] Rendering GUI in 3D space ( Ogre )
Cool. Thanks for letting us know you got it working, and for mentioning the pitfall as regards to device / resource restoration.
CE
CE
Useful Links: Forum Guidelines | Documentation | Tutorials | HOWTO | Videos | Donate to CEGUI | CEGUI Twitter
Return to “Modifications / Integrations / Customisations”
Who is online
Users browsing this forum: Bing [Bot] and 2 guests