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

[Boost113]

Well know it doesn't crash to the rendering step.
(It stopped crashing after I commented out the workspace creation, so I have no idea why it works, it just seems to work)

But it quits after printing this:

Code: Select all

WindowManager::loadLayoutFromFile - loading of layout from file 'SampleBrowser.layout' failed.

(Full log here: http://pastebin.com/FKwaaPDr)
Is this a missing file or something else?

[Ident]

It isnt missing https://bitbucket.org/cegui/cegui/src/6 ... at=default

I assume something breaks while loading.

[Boost113]

Then I'm just going to see if it renders the initial loading screen correctly...
Right now it is working, but it isn't working like it should. I need to test it a bit more to figure out why the "right" way crashes and the wrong way renders correctly (at least without any other content on the screen)

[Boost113]

I think that I found the issue, there is the following code in the Ogre sample:

Code: Select all

void CEGuiBaseApplication::renderSingleFrame(const float elapsed)
{
    CEGUI::System& gui_system(CEGUI::System::getSingleton());

    gui_system.injectTimePulse(elapsed);
    d_sampleApp->update(static_cast<float>(elapsed));

    updateFPS(elapsed);
    updateLogo(elapsed);

    beginRendering(elapsed);

    CEGUI::Renderer* gui_renderer(gui_system.getRenderer());
    gui_renderer->beginRendering();

    d_sampleApp->renderGUIContexts();

    gui_renderer->endRendering();
    CEGUI::WindowManager::getSingleton().cleanDeadPool();

    endRendering();
}

This code renders all the contexts and everything, which is something I didn't expect. I though that my render queue listener was the one who triggered the rendering. I'll have to test tomorrow if disabling the above will fix the issue...

[Ident]

The sample browser does things in a way that might not be typical for the average application, because it uses render-to-texture and multiple GUICoontexts. This is done to make it possible to easily preview and view specific samples. However, once everything works and renders correctly in the SampleBrowser, it is very very certain that most things are actually implemented the right way and will work in every other application as well. The SampleBrowser covers a large spectrum of use-cases. Only a few are not covered.

If it turns out everything is done right, but still does not work, it might actually be a general CEGUI bug. For comparing such things, the other renderers are always a good basis.

So anyways: once you manage to jump over that first hurdle of getting stuff to render in the SampleBrowser, you might have already simultaneously passed through the final goal.

[Boost113]

So after learning more about how CEGUI actually renders things I was able to get the samples correctly loading (I don't know how I was able to break the sample loading).
Turns out that CEGUI uses rtts to render things to and not just the main render window...

So now that I basically have made it use the whatever functionality is left in ViewPorts, it works.
Also now that I fixed the clearing problem it looks like I think it should look like.

The only problem is that I'm using ViewPorts, still. So I can't guarantee that the GUI actually ends up on top of everything.

What I think needs to be done is quite a large OgreRenderer overhaul using just a single Ogre scene where everything is located.
So that all the ViewPort and texture usage would be changed to Ogre objects (manual objects or something else) actually where scene objects for which Ogre would handle redrawing/ordering.
From what I've seen this would reduce things that the renderer would have to do since the scene can manage much of the shaders and custom matrices etc.

Making a pull request for the now working code.

[Boost113]

I just came up with a simple idea that could fix all the issues with little effort.
So instead of redoing everything we could render everything to a texture and then use the new system to make that be on top of everything.
This might even be as easy as changing the main target to a texture. Might try later if this works.

[Ident]

Regarding the previous-previous post:

Screenshot looks entirely correct to me.

You are also completely correct about the needed rework of the OgreRenderer, and this has been suggested as a Google Summer of Code project for CEGUI/Worldforge over the past 3 years. However, it hasn't been done by anyone yet / no one adequate applied for this. The changes can also be done by anyone else, and we would be very thankful for that.

Those changes would indeed reduce a lot of the OgreRenderer code. The issue is that the OgreRenderer has to work with older and newer Ogre versions (I guess 1.8, 1.9 and 2.0 should be supported, I am not sure how many people use 1.8 though, so if it is difficult to support it could also be dropped). This might turn out to be a bit of a challenge.

I just came up with a simple idea that could fix all the issues with little effort.
So instead of redoing everything we could render everything to a texture and then use the new system to make that be on top of everything.
This might even be as easy as changing the main target to a texture. Might try later if this works.

This will slow things down. It introduces an unnecessary step inbetween. Such solutions aren't good for when you try to get the maximum performance out of your application, so many people would be very unhappy with that. Also forcing RTT requires that a quite large texture has to be saved, so it would also waste some graphics card ram.

[Boost113]

Regarding the previous-previous post:

Screenshot looks entirely correct to me.

You are also completely correct about the needed rework of the OgreRenderer, and this has been suggested as a Google Summer of Code project for CEGUI/Worldforge over the past 3 years. However, it hasn't been done by anyone yet / no one adequate applied for this. The changes can also be done by anyone else, and we would be very thankful for that.

Those changes would indeed reduce a lot of the OgreRenderer code. The issue is that the OgreRenderer has to work with older and newer Ogre versions (I guess 1.8, 1.9 and 2.0 should be supported, I am not sure how many people use 1.8 though, so if it is difficult to support it could also be dropped). This might turn out to be a bit of a challenge.

It would be quite a large overhaul that needs to be done if it were attempted.
Regarding Ogre version support it might even offer better support since it would use some core Ogre components that are quite unlikely to drastically change.
For example many tutorials written for 1.8 still work just fine and I've been using the 1.8 manual and everything seems to still be correct in Ogre 2.0.
I think I even might attempt this this summer.

This will slow things down. It introduces an unnecessary step inbetween. Such solutions aren't good for when you try to get the maximum performance out of your application, so many people would be very unhappy with that. Also forcing RTT requires that a quite large texture has to be saved, so it would also waste some graphics card ram.

I doubt it would cause a noticeable difference, especially since the overlay can be applied using a single triangle in Ogre 2.0 - but you never know about performance until you actually try.

[Ident]

I doubt it would cause a noticeable difference, especially since the overlay can be applied using a single triangle in Ogre 2.0 - but you never know about performance until you actually try.

It does make a significant difference. It doesnt matter if it is just two triangles, they are drawn over the whole screen, thats a fragment shader execution for every pixel. http://en.wikipedia.org/wiki/Fillrate

I study computer graphics and I have myself programmed an OpenGL-based renderer from scratch which uses deferred shading and all kinds of jazz. I had serious issues due to the fillrate overdraw, which the deferred shading and post-processing effects introduced, especially because my notebook (now i got a desktop) GPU had not so great capabilities in that respect. It happens with high end desktop GPUs too though, but depending on the hardware specifics, the impact on the framerate might be better or worse on certain hardware, but it will always have an impact. Either way, if fill-rate was no issue then simple post-processing effects would be almost entirely for free, which they are definitely not. Check out the filters in the Ogre demo. They are all costy, even the simpler ones.

The way to go would be ManualObjects or something similar, just like you said before.

[Boost113]

I've been trying to test the default render method. Because the sample doesn't use it I've been trying to get CEGUI running in my project.
So far I have had constant issues with library dlls. First I had to setup dynamic Boost libraries since it didn't want to run without them.
Now that I found out that I have to manually copy Boost dlls to the boost/stage folder it can now complain about the dependencies dlls.
Right now I have already renamed png and expat dlls to have lib prefix. At least that seemed to fix all the naming issues and I can now actually test it.

Now it just renders my scene but no GUI, more fixing required.

Found out that the Ogre render queue listener never gets called and thus it never renders, now I just have to figure out why...

[Boost113]

After changing the listener to a CompositorWorkspaceListener it started drawing right:




The only issue is that there should a skybox rendered on the background. For some reason the GUI clears the target to black.

GPUPerfStudio's frame debugger says that after the skybox is drawn there is call to draw trianglelist with 6 indices having just a black colour and clearing the screen. Next call is drawing the first GUI overlay texture.
I wonder where this call to clear the target is made.

EDIT: Just remembered that I added a clear to black for testing purposes and removing it should fix this...

[Boost113]

Alright, now it is finally finished (I didn't do the multi window support, I'll save that for later)

Rendering just as it should:


The rendering method is a bit different in Ogre 2.0 than in other versions, so should I create a tutorial/guide for using CEGUI in Ogre 2.0?

[Ident]

How is the rendering method different? IT should be the same if possible (for simplicity and for easier maintainement of docs and code), if you let me look at it we might find a way to accomplish this.

[Boost113]

How is the rendering method different? IT should be the same if possible (for simplicity and for easier maintainement of docs and code), if you let me look at it we might find a way to accomplish this.

As the rendering doesn't require the user to call any rendering methods it should say this somewhere (I think that it already says that you don't have to call rendering with Ogre).
But since the Workspace uses order value of -1 for rendering last the user needs to know that he cannot create a workspace with a rendering order of -1 or the rendering MIGHT break.

Not counting the style setting code which is the same as in the documentation all the code that I have for creating the GUI system is this:

Code: Select all

CEGUI::OgreRenderer& guirenderer = CEGUI::OgreRenderer::bootstrapSystem(*OgreWindowPointer);

and then creating the context

Code: Select all

GuiContext = &CEGUI::System::getSingleton().createGUIContext(guirenderer.getDefaultRenderTarget());

and then of course loading a file and setting it as the root window.
This might be exactly what the documentation says.