Re: [Request] Make the OgreRenderer work with the new Ogre 2

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?

I don't actually know what CEGUI does but the simple Ogre Overlay and far too many other GUI libraries just put all their stuff on all the windows (or just the first), which defeats the point of having multiple windows as people usually want different things on different windows.

What I am trying to say is that all the render targets (different windows) should be able to have different gui contents on them.As in there being a main window with a HUD for a game and then another window having for example a textbox containing the log.But if the renderer in CEGUI knows which contexts belong to which window then it is all fine.

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 17:20

by Ident

I am not really sure I correctly understand what you are saying but this sounds somewhat inefficient. You want a separate viewport and rendertarget for every single GUI widget that you render?

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 17:45

by Boost113

Ident wrote:I am not really sure I correctly understand what you are saying but this sounds somewhat inefficient. You want a separate viewport and rendertarget for every single GUI widget that you render?

That's not what I tried to say...I want the ability to have different window hierarchies on different windows windows that all have their own render target (the window object is a render target for Ogre).

I tried to draw it, here the windows are different windows on the desktop and their contents are the GUI objects:

So what I tried to say was that multiple Windows windows should be supported.

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 20:46

by Ident

I am still not sure what you mean, as far as I understand all of this can already be done in CEGUI, but maybe you can explain it further. You talk about "Window windows" i have no idea what that's supposed to mean. What is a "window" here?? CEGUI has windows (widgets), the application window is a window too, please be more specific. Also: What kind of windows are Window 1, 2, and 3?

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 21:28

by nicoo

[u]If[\u] I understand what he wrote, each windows '1,2,3' are three windows for one same process created with OGRE (mean threading each window trough one process, like gimp). Then each windows would have its own cegui root...

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 21:29

by Ident

Like a separate application/host window?

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 21:36

by nicoo

Ident wrote:Like a separate application/host window?

I won't say separate application (for me application == process), but separate windows yes. For me this should not be a problem for cegui but for the library used to create the window(s). But this is always in the case I understood what he wrote

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 21:47

by Ident

for me application == process

two totally different things

but separate windows

what windows.... the ones you have in your operating system? with a frame and buttons on top right/ top left for closing minimizing etc?

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 21:55

by nicoo

nicoo wrote:two totally different things

then plz explain, I will learn something

Ident wrote:what windows.... the ones you have in your operating system? with a frame and buttons on top right/ top left for closing minimizing etc?

that's what I understood

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 22:12

by Ident

A process is (more or less) an instance of an applicatio but considering the context we were talking about, the difference was actually not important there, so i ll take my statement about it back...

If boost means what we think he means then I see no issue. With some small changes it should be possible to attach each cegui guicontext to different rendertargets... even if those are different framebuffers (or to whatever you render in such a window) and not a RTT. However, I am not aware that this was/is possible in Ogre. It is very rarely used in OpenGL. You basically need multi-OpenGL-context support with shared resources as far as i remember. There is hardly any use for such a setup in reality.

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sat Apr 12, 2014 22:51

by nicoo

Ident wrote:It is very rarely used in OpenGL. You basically need multi-OpenGL-context support with shared resources as far as i remember. There is hardly any use for such a setup in reality.

well, some months ago I made something like that with pthread. I simply rendered in one window, then moved my camera, rendered in the second window each frame.

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sun Apr 13, 2014 07:29

by Boost113

Ident wrote:A process is (more or less) an instance of an applicatio but considering the context we were talking about, the difference was actually not important there, so i ll take my statement about it back...

If boost means what we think he means then I see no issue. With some small changes it should be possible to attach each cegui guicontext to different rendertargets... even if those are different framebuffers (or to whatever you render in such a window) and not a RTT. However, I am not aware that this was/is possible in Ogre. It is very rarely used in OpenGL. You basically need multi-OpenGL-context support with shared resources as far as i remember. There is hardly any use for such a setup in reality.

Attaching cegui contexts to different rendertargets is what I meant. (because of the changes in the new Ogre 2.0 it will be necessary to know which contexts are connected to which rendertargets)Many games support multiple windows, one that came to mind was Supreme Commander where you could have something like this:Not my image. But being able to have a fully zoomed out map on one screen and a focused area on another is really handy in a game like that.

Btw sometime ago I searched how to do this with Ogre and what the helpful people on their forums said it was possible, it just required few little tricks.

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sun Apr 13, 2014 09:19

by Boost113

I started working on making it work with Ogre 2.0. After reading the style guides I noticed that the file (Renderer.cpp) has tabs.should I untabify it (as in change them to spaces)?

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sun Apr 13, 2014 11:50

by Ident

change only those lines that have tabs into spaces, which you actually modify. otherwise it will look a mess in the diff. thanks for considering this.

Multi-screen capability is something i havent thought about. thats a valid point. however, since cegui was changed to have GUIContexts for multi-target rendering, it is definitely laid out for such purposes. In D3D11 and OpenGL it is up to the user to render each GUIContext to the right framebuffer, so there it is definitely posible to do this already. Setting up a shared OpenGL context is of course out of the domain of CEGUI and something that the user has to care about. If Ogre offers this out of the box then this is definitely a nice thing.

Re: [Request] Make the OgreRenderer work with the new Ogre 2

Posted: Sun Apr 13, 2014 12:17

by Boost113

Ident wrote:change only those lines that have tabs into spaces, which you actually modify. otherwise it will look a mess in the diff. thanks for considering this.

I tried to untabify the entire file(s) and pretty much all files I looked at had tabs in them and from what I quickly checked about 80%-90% of all lines in the file had tabs.