[2.1] Using CEGUI v8

[Frankincense]

Hi all,

I recently updated to Ogre 2.1 from 1.10 and I am trying to get CEGUI (OgreRenderer, Linux) to work with it too, with mixed results. I first attempted to use the default CEGUI branch which I could get working but the performance was not great - even in Release mode with only a single window and a few controls.

I have now attempted to go back to the CEGUI v0.8 branch and apply the patches mentioned in this thread: viewtopic.php?f=25&t=82911, but for what-ever reason I cannot get anything to render (just a black screen) which I assume is due to the compositor setup or viewport changes.

I used the files in this post: viewtopic.php?p=539373#p539373 to compare against for the CEGUI OgreRenderer and scene setup but nothing seems to work.


Is anyone using CEGUI (v0.8 or default branches) with the latest Ogre 2.1 successfully?


Cheers,
Frank

[dermont]

Hi,

I'm not used Ogre 2.1 for some time but it sill appears to work with with the current cegui v0-8 and Ogre v2-1 git repos. The changes/updates were from other users, I only zipped them up for someone who was trouble applying the changes.

I added an include path to CMake file <your_path>/sdk/v2-1/include/OGRE/Hlms/Common and commented out :

Code: Select all

 //CEGUI::System::getSingleton().getDefaultGUIContext().getMouseCursor().setDefaultImage(
      //    "OgreTrayImages/MouseArrow");

It's been so long but the one thing I do recall is that Ogre2.1/default CEGUI branch combo was about 50% slower that of the 2.1/ modified cegui v0-8.

[Frankincense]

With the v0-8 branch from Github I had to make almost all of the changes in those files to get it to compile, so I assumed that v0-8 hadn't been kept up-to-date with the latest Ogre 2.1

Unless I'm missing something I don't believe v0-8 builds with Ogre 2.1 straight from the repo? Maybe because 2.1 now has the merged PBO branch?

[Arth]

Hi,

i'm also using cegui-default-branch with Ogre2.1.
i was previously using cegui v0.8 an Ogre2.0 but there were issues that not everything was working.

i also had performance problems at first, but when i started setting text to widgets as following everywhere in my code, it was going away:

Code: Select all

if(window->getText() != text)
	window->setText(text);

Also i had to not use any CEGUI::ProgressBar, as this widgets performace was very bad (was not any problem with cegui v0.8 ) .

I have only one problem left, see viewtopic.php?f=25&t=95988

If you have clipping problems (cegui-default-branch with Ogre2.1), there is a unmerged pull request for a fix:
https://github.com/cegui/cegui/pull/1208

[Frankincense]

i also had performance problems at first, but when i started setting text to widgets as following everywhere in my code, it was going away:

Code: Select all

if(window->getText() != text)
	window->setText(text);

Thanks, I will have a look - if I cannot get v0-8 working I may have to go back to default and use your changes. Where do you put this exactly? Whenever you set the text of a Window?

i'm also using cegui-default-branch with Ogre2.1.
i was previously using cegui v0.8 an Ogre2.0 but there were issues that not everything was working.

I think I would prefer to stick with v0-8 if I could, as I know its reasonably stable, and I can't see anything in default that actually benefits me yet!


Does anyone have a working CEGUI v0-8 OgreRenderer with Ogre 2.1 latest (after the PSO merge)?

[Arth]

Thanks, I will have a look - if I cannot get v0-8 working I may have to go back to default and use your changes. Where do you put this exactly? Whenever you set the text of a Window?

yes, whenever you set the text of a Window.

think I would prefer to stick with v0-8 if I could, as I know its reasonably stable, and I can't see anything in default that actually benefits me yet!

I had the problem that RenderTextures were not correctly implemented in the CEGUI-OgreRenderer and i had to
"window->setUsingAutoRenderingSurface(false)" for all CEGUI-framewindows to account for that. Also it cased the problems that it was not possible to rotate a image in CEGUI and also rendering a CEGUI window to an Ogre object's (Entity or item) texture, was not possible.

[Frankincense]

My final issue in moving to Ogre 2.1 is that AutoRenderingSurface's do not work in CEGUI (which I need to perform some custom shading). Does anyone have a working CEGUI v0.8 with AutoRenderingSurface set to True?

In RenderDoc there are two draw calls made for a Window that has an AutoRenderingSurface. The first has the input texture which appears to write to the backbuffer:




And the second I think is the 'normal' rendering of the surface which should receive the output from the above render, but instead the input is a blank texture:


To me, I would have thought that the first draw call should be to an RTT instead of the backbuffer?


I imagine that the render target (whether its the main render window or an RTT) is held by the viewport? So maybe the issue is in https://github.com/cegui/cegui/blob/v0- ... Target.inl somewhere


Edit: This looks like an outstanding issue for Ogre 2.1 - https://github.com/cegui/cegui/issues/1137

[Frankincense]

I figured the issue was something to do with the fact that when using the new Compositor2, CEGUI does not create viewports for its texture render targets (https://github.com/cegui/cegui/blob/v0- ... Target.inl & https://github.com/cegui/cegui/blob/v0- ... Target.cpp).

I had a go at removing the '#if !defined(CEGUI_USE_OGRE_COMPOSITOR2)' checks and changing

Code: Select all

d_viewport = OGRE_NEW Ogre::Viewport(0, d_renderTarget, 0, 0, 1, 1, 0);

to

Code: Select all

d_viewport = d_renderTarget->addViewport( 0, 0, 1, 1 );

but Render Doc still shows the first pass as rendering to the backbuffer rather than the RTT that's created.



I think that CEGUI OgreGeometryBuffer is always using the main render target's viewport rather than the RTT's viewport: https://github.com/cegui/cegui/blob/v0- ... r.cpp#L178.
If I change the line to

Code: Select all

Ogre::Viewport* currentViewport = previousViewport;//d_owner.getOgreRenderTarget()->getViewport(0);

then the first pass of the auto render window gets rendered to the texture rather than the backbuffer!

So I presume that the solution is to use the RTT's viewport when we are rendering it, not sure exactly how this should be done yet though.