[Request] Make the OgreRenderer work with the new Ogre 2.0

[Boost113]

Hi,

I wanted to test how CEGUI compares to other GUI libraries I have used but I can't since the new Ogre 2.0 compositor system is not supported.
In the upcoming 2.0 release ViewPorts should not be used and thus the OgreRenderer needs an overhaul, from the 2.0 porting draft:
"3.5 Where is RenderTarget::update? Why do I get errors in Viewport?
Advanced users are probably used to low level manipulation of RenderTargets. As such they're used to setting up their custom Viewports and calling RenderTarget::update.
That is too low level. Instead, users are now encouraged to setup Compositor nodes and multiple workspaces to perform rendering to multiple RTs, even if it's for your own custom stuff"

So this means that all the ViewPort related code needs to be changed to work with the latest releases.

I haven't used the library at all and only worked a little bit with the new compositor2 but I did some changes that could be a base for properly fixing/improving the renderer.

(Syntax coloured version for your viewing pleasure: http://boostslair.com/files/CEGUI_fixes_colour.htm)

Code: Select all

// Put this to a static initialize which is called before any OgreRenderer instances are created
// Define a workspace template //
    auto templatedworkspace = manager->addWorkspaceDefinition("CEGUI_workspace");

    // Create a node //
    auto rendernode = manager->addNodeDefinition("OverlayRenderNode");
    // Use the render target passed from the workspace for rendering on top of //
    rendernode->addTextureSourceName("renderwindow", 0, TextureDefinitionBase::TEXTURE_INPUT);

    // Pass for it //
    auto targetpasses = rendernode->addTargetPass("renderwindow");
    targetpasses->setNumPasses(2);

    Ogre::CompositorPassClearDef* clearpass = static_cast<Ogre::CompositorPassClearDef*>(targetpasses->addPass(Ogre::PASS_CLEAR));

    // Only clear depth and stencil since we are rendering on top of existing image //
    clearpass->mClearBufferFlags = Ogre::FBT_DEPTH | Ogre::FBT_STENCIL;

    // Now the render scene pass during which the render queue listener should render the GUI //
    Ogre::CompositorPassSceneDef* scenepass = static_cast<Ogre::CompositorPassSceneDef*>(targetpasses->addPass(Ogre::PASS_SCENE));

    // Just render the overlay group since it is the only one used //
    scenepass->mFirstRQ = Ogre::RENDER_QUEUE_OVERLAY;
    scenepass->mLastRQ = Ogre::RENDER_QUEUE_OVERLAY;

    // Connect the main render target to the node //
    templatedworkspace->connectOutput("OverlayRenderNode", 0);
   
// Then put this into initialize method for all individual OgreRenderers (every window should have their own and they should
// have some of the functionality moved to a static class/OgreRenderMaster class
    Ogre::Root& root = Ogre::Root::getSingleton();

    // Set up a scene to use //
    // These might not be required, but since they are empty it shouldn't matter that much
    auto OverlayScene = Ogre::Root::getSingleton().createSceneManager(Ogre::ST_INTERIOR, 1, Ogre::INSTANCING_CULLING_SINGLETHREAD,
        "Overlay_forGUI_ID1");

    auto OverLayCamera = OverlayScene->createCamera("empty camera");

    Ogre::CompositorManager2* manager = root.getCompositorManager2();
   
    // This is the part that replaces the ViewPorts
   
    // Create the workspace to the render target //
    // Pass this as a parameter to this function
    Ogre::RenderTarget* target = NULL;
    // The -1 should quarantee this to be rendered last on top of everything
    manager->addWorkspace(OverlayScene, target, OverLayCamera, "CEGUI_rendering_for_window0", true, -1);

    // TODO: start listening for RENDER_QUEUE_OVERLAY rendering and render during it //
    // What this should accomplish is that pretty much everything else except setting up the matrices can be removed and of course the render queue listener
    // needs to be added
   
   
static class OgreGUIFrameListener : public Ogre::RenderQueueListener
{
public:
    OgreGUIFrameListener(OgreRenderer* owner) : Owner(Owner), d_enabled(true){};

    void setCEGUIRenderEnabled(bool enabled);
    bool isCEGUIRenderEnabled() const;

    virtual void renderQueueStarted(RenderQueue *rq, uint8 queueGroupId, const String& invocation, bool& skipThisInvocation){
        if (d_enabled){

            // We should only render contexts that are on this render target //
            // Pass pointer to the renderer here //
            Owner->beginRendering();

            // Stuff from System::renderAllGUIContexts
            // We should get the right context from the OgreRenderer instance somehow
            d_guiContexts[0]->draw();
            // Maybe a vector
            //Owner->VectorOfContextsOnThisTarget;

            // This probably should only be called once //
            // do final destruction on dead-pool windows
            WindowManager::getSingleton().cleanDeadPool();

            // This wouldn't even be required //
            Owner->endRendering();
        }
    }


private:
    bool d_enabled;
    OgreRenderer* Owner;

} S_frameListener;


void OgreRenderer::beginRendering()
{
    // Should now be called from the render queue listener //
    initialiseRenderStateSettings();
}

void OgreRenderer::endRendering()
{
    // Cleanup should no longer be required, at least it would be quite hard to try to restore the matrices etc //

}
   


Would be great if this would be supported in the future so I could actually use CEGUI
thanks

[Ident]

Have you tried to use CEGUI default branch with Ogre 2.0? I made it work with Ogre default branch including Ogre-OpenGL 3.2+ Renderer. I would have assumed this also works with 2.0 then but I have actually not tried out 2.0 specifically and in my default branch changes I have not changed any viewport stuff.

[Boost113]

I changed to the default branch and it seems that the cmake file cannot be configured without the GLM dependency.
I'll try to compile the dependencies again with GLM and see if I can get it to configure after that...

But without checking if it compiles I think that it won't if no ViewPort related code is changed.
I'll post any errors soon.


EDIT: after compiling the dependencies with GLM it now configures, now to see if it actually compiles...

[Ident]

What OS do you use? GLM has become a dependency, for mac os and windows you can use our dependency package: https://bitbucket.org/cegui/cegui-dependencies

[Boost113]

Okay, so the default branch is even more broken as in not even the GeometryBuffer compiles (Vertex is undefined for some reason).
There are also missing includes (at least in the version of Ogre I have you need to include stuff like OgreSharedPtr.h to make it work). My Ogre version is almost the newest commit of v2-0 branch (just checked and I'm a couple of commits behind).
Before getting to the part that previously didn't work I got tons of other errors: OgreRenderer being abstract, some types are wrong (cannot assing, converting Ogre::TexturePtr to int) etc.

Now to the errors caused by the new Ogre version:

Code: Select all

cegui\src\RendererModules\Ogre\Renderer.cpp(545): error C2039: 'getCamera' : is not a member of 'Ogre::Viewport'
3>          H:\OgreBuild\Ogre\sdk\include\OGRE\OgreViewport.h(56) : see declaration of 'Ogre::Viewport'

and what I know cannot find: the constructor for the ViewPort no longer accepts the z-order parameter.
It is now:

Code: Select all

/** The usual constructor.
            @param camera
                Pointer to a camera to be the source for the image.
            @param target
                Pointer to the render target to be the destination
                for the rendering.
            @param left, top, width, height
                Dimensions of the viewport, expressed as a value between
                0 and 1. This allows the dimensions to apply irrespective of
                changes in the target's size: e.g. to fill the whole area,
                values of 0,0,1,1 are appropriate.
            @param ZOrder
                Relative Z-order on the target. Lower = further to
                the front.
        */
        Viewport(
            RenderTarget* target,
            Real left, Real top,
            Real width, Real height );

So due to the missing camera and ViewPort losing functionality bit by bit there needs to be some major changes.

[Boost113]

What OS do you use? GLM has become a dependency, for mac os and windows you can use our dependency package: https://bitbucket.org/cegui/cegui-dependencies

I'm using windows, but it will also have to work on linux.
The doxygen documentation said that I didn't have to compile GLM, so I fixed it by setting it too to compile.

[Ident]

Which doxygen version of CEGUI are you referring to

[Boost113]

Which doxygen version of CEGUI are you referring to

The one online? http://static.cegui.org.uk/docs/current/index.html
More specifically here http://static.cegui.org.uk/docs/current/dependencies.html it doesn' mention GLM under "Core Functionality" so I thought I don't need it.

[Ident]

The version for the online one is the one of our releases, so currently this would be 0.8.3. It says this clearly on the top. CEGUI 0.8.3 doesnt depend on GLM as a core dependency. The doxygen docs in default are not updated yet because we are far from a release so it makes no sense to add stuff that isnt even certain yet. But it is very certain that GLM will become a core dependency starting with the next major release. Default branch is unstable so it is not recommended to be used. But since you want to use the latest Ogre, this is the only way to go. Btw, the samplebrowser is broken for Ogre currently on default, so dont be surprised by that. I redid the rendering superclasses and structures entirely during GSoC2013, I have only adapted Direct3D and OpenGL so far.

[Boost113]

Okay, so the OgreRenderer is basically broken on all Ogre versions?
Would it be possible to render on top of Ogre window with OpenGL renderer, or do I need to do some sort of render to texture?
The "GUI" library I'm using at the moment basically gives me a pointer to texture that I copy to a fullscreen quad and render so that could be adapted to work with CEGUI.

Maybe I could (try to) fix the OgreRenderer in the 0.8 branch to work with the latest Ogre?

[Ident]

Sorry i gave you a wrong info. Do not use default branch, it is indeed broken there for all versions. You need CEGUI "v-0" branch. This branch works with 1.9 and default, i tested it myself. I am not sure about older versions and 2.0. I am also unsure how 2.0 related to default.

Would it be possible to render on top of Ogre window with OpenGL renderer, or do I need to do some sort of render to texture?

I doubt that is a good idea. If you use Ogre just use the Ogre interfaces, otherwise Ogre might be unaware of changed states etc. Just use v-0 branch. I am sorry for hinting you to the wrong branch..

The "GUI" library I'm using at the moment basically gives me a pointer to texture that I copy to a fullscreen quad and render so that could be adapted to work with CEGUI.

Nasty

Please try v-0 branch!

PS: I had added the info about CEGUI v-0 branch Ogre compatibility here a couple weeks ago, after i adapted the CEGUIOgreRenderer: http://cegui.org.uk/wiki/Building_CEGUI ... reRenderer

[Boost113]

Please try v-0 branch!

Yeah, the v0 branch also fails to build with the same Ogre related errors.
The v2-0 branch that I'm using has ditched the support for ViewPorts and that causes the issues (I don't think that the v2-0 branch has been merged to default anytime lately).

The "GUI" library I'm using at the moment basically gives me a pointer to texture that I copy to a fullscreen quad and render so that could be adapted to work with CEGUI.

Nasty

Unrelated to the issue, but the library I'm using (Chromium Embedded Framework, isn't really for use in games) has a multiprocess architecture making it pretty much impossible to render with Ogre directly since the rendering is done in child processes.


Maybe I should fork the v0 branch and try to make it work with the latest Ogre v2-0 branch.

[Ident]

Maybe I should fork the v0 branch and try to make it work with the latest Ogre v2-0 branch.

That would be fantastic. It would allow us to easily merge it later-on. Of course for it to be merged into CEGUI, the code has to follow our coding conventions. I would also need to see if it still works with 1.9 and default branch. We usually establish such compatibility using preprocessor defines such as #ifdef

[Boost113]

Maybe I should fork the v0 branch and try to make it work with the latest Ogre v2-0 branch.

That would be fantastic. It would allow us to easily merge it later-on. Of course for it to be merged into CEGUI, the code has to follow our coding conventions. I would also need to see if it still works with 1.9 and default branch. We usually establish such compatibility using preprocessor defines such as #ifdef

I will definitely need to use #ifdefs since the component (Compositor2) is not exactly the same as the old Ogre Compositor.

Some architectural changes, that I think are required, might be a bigger issue. Since we can no longer render when we please and we have to wait for Ogre to tell the workspace to run, it is required for the OgreRenderer to know which contexts belong to wich render targets. It isn't necessarily required but being able to render the GUI to multiple windows would be a nice feature. So there will need to be new functions in the base renderer for attaching/detaching contexts. I also will probably need to change some internal OgreRenderer classes, the listener for example, but that won't break the OgreRenderer API for the other components.

[Ident]

I dont know anything about these new Ogre changes at all.

Code: Select all

It isn't necessarily required but being able to render the GUI to multiple windows would be a nice feature.

What do you mean by that? Isnt that what CEGUI already does with RTT?