Best way to handle GUI rendering in Ogre?

[areay]

Sounds good. I don't need much to be impressed. A fluid dynamic layout with buttons, edit boxes, and text areas would do

Yeah, and it should also generate an RSS feed of events too.

Auskiller, I can recommend CEGUI for you. If it can't be done in CEGUI, it can't be done, heh. About your multiple coordinate styles, check out this CEGUI datatype http://www.cegui.org.uk/docs/current/cl ... _1UDim.htm can be absolute screen-position, or relative pixel position or both.

For example, here's how you could place a window 32 pixels to the right of the dead centre of the screen

Code: Select all

titleWindow->setPosition( UVector2( UDim( 0.5f, 32 ), UDim( 0.5f, 0 ) ) );

[mkultra333]

Ha, the cruel GUI cynics are out in force!

I say write your own. Either

A: You only want a simple gui. In that case, a few sprites and input detection routines will cover you.

Or

B: You want a fancy, complicated gui. In that case, it's far better to be able to control and customize it to the nth degree with your own coding, than it is to have to wrestle with someone else's way of thinking. It'll be structure from the ground up to do what you need, instead of trying to shoe-horn it into some other system.

This is why there are so many guis: They are relatively easy to write, compared to a physics engine or networking engine. How good the gui looks in the game will probably depend more on how good your sprites and art assets look than on the underlying code that drives them.

[AusSkiller]

I say write your own. Either

A: You only want a simple gui. In that case, a few sprites and input detection routines will cover you.

Or

B: You want a fancy, complicated gui. In that case, it's far better to be able to control and customize it to the nth degree with your own coding, than it is to have to wrestle with someone else's way of thinking. It'll be structure from the ground up to do what you need, instead of trying to shoe-horn it into some other system.

Yeah, I'm mostly looking at category A, though I do want a few things that would fall under category B like a large range of unit types that are relative to various things to make it easier to layout UIs in XML files.

This is why there are so many guis: They are relatively easy to write, compared to a physics engine or networking engine. How good the gui looks in the game will probably depend more on how good your sprites and art assets look than on the underlying code that drives them.

Yeah, which is why I grabbed Bullet for "physics" (I only really needed high performance ray casting though) but don't mind writing a UI myself, besides I've written them before so I already have plenty of experience doing so .


I've been reading up on various bits of tech that might influence what I do/how I do it, in particular with how to deal with text rendering, and have found that it's just too much of a pain to bother with languages that need large character sets. I was tempted to use cairo for font rasterizing but I just wasn't confident that the performance would be good enough for large numbers of dynamic text fields and given the relatively small scale of this project the complexity needed to handle caching the rasterized text on a texture would create more work than I was willing to do to have full language support. So now I'll probably just write a tool using freetype to build up a distance field texture of the font and use a much easier bitmap font style of rendering text which I'm much more familiar with anyway.

I also just realized that next weekend is the MTG Dragon's Maze pre-release so if I start work on the UI in the next few days (I'll let you know exactly when I actually start) I'm probably not going to get as much work done next week as normal, I might still get it done in under 2 weeks, but if it does go over by two or three days that will be the reason, of course any more than that and I just over estimated my abilities .

[mkultra333]

When I wrote my gui, I based it on the 2D sprite code found in the wiki: http://www.ogre3d.org/tikiwiki/tiki-ind ... eManager2d

SpriteManager2D is very low level. It'll render all your sprites in one batch, based off one large texture. You can use multiple textures too, but each one will add one batch. Downside is it doesn't use any materials, it's that raw and to the bone. It just pokes stuff directly into the render system.

I added a few small modifications, so it can accept an alpha and RGB value per sprite, allowing you to colour and fade them, and I made it so you could output to any render surface rather than just the main screen. If you're interested in the modifications I'll post the code. ( I removed the listener so my version also requires you do manual frame updating.)

Edit: I may have modified my version to only allow one texture, I can't remember. But at any rate, I remember you mentioned wanting multiple fonts/languages. Since the original SpriteManager2D can allow multiple textures, you could easily have a different texture for each language. So at worst 2 batches, one for any language elements and one for any icons or images.

[AusSkiller]

When I wrote my gui, I based it on the 2D sprite code found in the wiki: http://www.ogre3d.org/tikiwiki/tiki-ind ... eManager2d

SpriteManager2D is very low level. It'll render all your sprites in one batch, based off one large texture. You can use multiple textures too, but each one will add one batch. Downside is it doesn't use any materials, it's that raw and to the bone. It just pokes stuff directly into the render system.

Nah I'll just write my own rendering solution, I specialize in graphics so it's something that's easier for me to do, and since I'll probably use distance fields I'll be wanting to use materials and shaders.

Edit: I may have modified my version to only allow one texture, I can't remember. But at any rate, I remember you mentioned wanting multiple fonts/languages. Since the original SpriteManager2D can allow multiple textures, you could easily have a different texture for each language. So at worst 2 batches, one for any language elements and one for any icons or images.

I'm planning on allowing translucent windows and other UI elements so dependance on the render order will probably cause me to need a few more than 2 batches to deal with the fonts, though I suppose I could create a shader that has both textures loaded and switches between them based on some additional vertex data (and changes the render method to distance fields for the text too) allowing for a single render batch but I suspect that the impact on shader performance would probably have a bigger performance hit than a few extra render batches anyway.

[AusSkiller]

Time for me to stop slacking off, time for me to start work on the UI . So two weeks from now I'll post a screenshot or something of the progress I make, if I'm not done sooner .

[Grognard]

I think it took me more than two weeks just to make a stupid text editor widget, but I have not been working on it that much.

It would be really nice if the fonts could be set to generate to partial pixel sizes, I nearly yanked a tooth out in frustration trying to figure out why things are always off.

The best way in my not so humble opinion would be render to texture and n-buffering, with smart updating so you don't rewrite stuff when not needed. Then you would do one batch per frame and not waste much CPU when you are forced to draw. So chop chop get to it won't you? Please?

When I wrote my gui, I based it on the 2D sprite code found in the wiki: http://www.ogre3d.org/tikiwiki/tiki-ind ... eManager2d

SpriteManager2D is very low level. It'll render all your sprites in one batch, based off one large texture. You can use multiple textures too, but each one will add one batch. Downside is it doesn't use any materials, it's that raw and to the bone. It just pokes stuff directly into the render system.

I added a few small modifications, so it can accept an alpha and RGB value per sprite, allowing you to colour and fade them, and I made it so you could output to any render surface rather than just the main screen. If you're interested in the modifications I'll post the code. ( I removed the listener so my version also requires you do manual frame updating.)

Edit: I may have modified my version to only allow one texture, I can't remember. But at any rate, I remember you mentioned wanting multiple fonts/languages. Since the original SpriteManager2D can allow multiple textures, you could easily have a different texture for each language. So at worst 2 batches, one for any language elements and one for any icons or images.

Even though you are labeled a troll, I agree. You aren't going to get an all purpose easy to use good looking GUI for a 3D engine with good performance, sadly. It would take years to do that, and every one I know of for any engine fails at least some points. So then you either need something real simple, or you need something painfully complex, so you ultimately have to do it alone.

[bstone]

Even though you are labeled a troll

lol, what? can I see the label please?

Edit: I see it! The ranking system is so merciless! That's hilarious!

[tbz]

CEGUI is amazing, and has Lua bindings too!

[AusSkiller]

I think it took me more than two weeks just to make a stupid text editor widget, but I have not been working on it that much.

Was it a multi-line text editor? Those things can be a pain to write, fortunately I'm fairly sure I don't need one .

It would be really nice if the fonts could be set to generate to partial pixel sizes, I nearly yanked a tooth out in frustration trying to figure out why things are always off.

The way I set up my font stuff already allowed for that sort of thing before it even became an issue, and better still my measure functions to determine text size are perfectly proportional to the font size I pass in for rendering, so if I measure something and it's exactly 2 times too big to fit at a font size, then I can just halve the font size and I know it will fit exactly .

The best way in my not so humble opinion would be render to texture and n-buffering, with smart updating so you don't rewrite stuff when not needed. Then you would do one batch per frame and not waste much CPU when you are forced to draw. So chop chop get to it won't you? Please?

Yeah that's pretty much the best way to do it, but it's probably overkill for my game and I might want to add some shader based animations later to fancy it all up which requires rendering most stuff each frame anyway. So I've just decided to cache certain values so that when it comes to rendering it's 90% just copying values into a buffer and then rendering the buffer when it's full or a state change is needed.



Update:
Things are looking on schedule despite all the slacking I've been doing , got the mouse cursor, windows, buttons, text and sliders all working well and doing what they should (though I haven't bothered hooking up callbacks for them yet). I'm having a bit of trouble trying to decide how exactly to handle automatic layouts but it's mostly irrelevant at this point so I'm just going to ignore it and finish off a scrollable layout, check/radio buttons, a text edit, and maybe a progress bar which should get me as far as I need for a functional UI (I'll post screenshots or a vid at that point) and can just add anything else as needed later.

BTW I ended up using distance fields for the text and it is awesome . I've got nice crisp text at all sizes and with a single pixel of edge softening it can even fake anti-aliasing, I highly recommend using it if anyone else is thinking about doing so.

[AusSkiller]

And here's a vid showing the UI, took me less time than I thought it would but I also slacked of more than I thought I would to so it ended up taking two weeks anyway, had I been working proper 8 hour days instead of just 2-6 hours I'd probably have got it done in under a week. At any rate as you can see it's functional but I'll probably improve bits a pieces as needed later on, and in particular it really needs some better art, though I ripped the cursor from an old UI I made for another game because the one I'd whipped up as a place holder for this one was just way too ugly . The main time sink was just getting all the font/text stuff going, it also took a bit of time making sure all the clipping worked properly so I can have that nice scrollable panel without things rendering where they shouldn't.

http://youtu.be/aCLCToFknAE

[saejox]

Good job. I wouldn't dare such a thing

[jacmoe]

Looks a bit like imGui
Respect.

[Grognard]

Very nice work. Looks pretty good, too.

[AusSkiller]

Good job. I wouldn't dare such a thing

Looks a bit like imGui
Respect.

Very nice work. Looks pretty good, too.

Thanks , I'll have to post another vid once I've got some better art for the UI, but that will probably be quite a while off yet because now that I have a functional UI to cover my needs I'm going to focus more on the gameplay.

[Nickenstein79]

[Foamy-mouthed-rant]

Just sticking my oar in here, as I myself have spent(wasted) some(lots of) time making my own GUI system for Ogre, and I have finally decided to switch to using CEGUI.

It only took a few hours of tinkering and a few helpful pointers from the nice chaps on the CEGUI forum to get it all compiled and linking with my game.

http://youtu.be/3-EzARo2EBM

[youtube]3-EzARo2EBM[/youtube]

In the vid you can see my own GUI which I am switching out in favour of using CEGUI. In the top left you can see a CEGUI::TaharezLook test window, and a CEGUI::TaharezLook mouse pointer in the centre of the screen.
Tomorrow I can plumb in the key/mouse injection code from OIS->CEGUI and then start making some proper GUIs with it.

My own GUI system is one that I wrote a couple of years ago for console games when I was in the games industry before I went Indie. It's actually in a whole bunch of 360/PS2/PS3/Wii games. But getting it to half-work with Ogre has been an utter pain in the arse.

The reason for me switching is also seen in the video. Whenever I toggle on an Ogre postrender filter effect it interferes with my sprite system and my GUI disappears (some renderstate conflict somewhere), which is no good.
Note that CEGUI does not suffer from this problem, and stays perfectly visible when post-filter effects are applied. Also my sprite code interferes with Ogre's shadow buffer so I have had to disable shadows until now, which again, is no good.

My sprite system is based on the HMoraldo Ogre2D class which can be found on these forums. And I have spent countless hours trying to make it not interfere with Ogre's post-filter effects and shadow textures.

An additional problem I have struggled with when using my own GUI system alongside Ogre: I can't for the life of me get the texture-filtering to be consistent between DirectX and OpenGL. (Another renderstate conflict somewhere.) This is a new problem I recently encountered when getting my game Linux/Mac-ready. Just be aware, there are a bunch of hurdles and conflicts to overcome when you try and implement a flexible 2D sprite system alongside Ogre. CEGUI has already wrangled these conflicts into submission for you.

I have wanted to make the switch to CEGUI for a while now as the scrollable windows will make doing things like scrollable tech/research-tree GUIs a breeze. My scrollbars don't yet function, and my font support is nowhere near as good as CEGUIs.

I accidentally stumbled upon the CEGUI-Unified editor a couple of days ago and after tinkering with it for a bit, I saw how easily I could change the look of the CEGUI::demos with it. This is the point where I finally swallowed my stupid pride and decided to make the switch to CEGUI.

So, given the time I have lost implementing my own solution (because of myriad conflicts between my sprite code and Ogre's PostFilters & ShadowTargets), and given that I got CEGUI working in only a few hours, and also given that CEGUI now has a very nice Drag&Drop GUI editor, I would strongly suggest you spend at least _one_ day playing with CEGUI before you spend any time rolling your own GUI system.

I SURE WISH I HAD!

[/Foamy-mouthed-rant]

Cheers,
Nick

[AusSkiller]

My own GUI system is one that I wrote a couple of years ago for console games when I was in the games industry before I went Indie. It's actually in a whole bunch of 360/PS2/PS3/Wii games. But getting it to half-work with Ogre has been an utter pain in the arse.

Haha yeah, it's always hard to get generic rendering engines to do the tricks you learn when writing your own engines for consoles, but I managed to get access to what I needed from Ogre to do the UI rendering the way I'm used to, I don't have quite as much control as I'm used to be it should be fine for my needs.

An additional problem I have struggled with when using my own GUI system alongside Ogre: I can't for the life of me get the texture-filtering to be consistent between DirectX and OpenGL. (Another renderstate conflict somewhere.) This is a new problem I recently encountered when getting my game Linux-ready. Just be aware, there are a bunch of hurdles and conflicts to overcome when you try and implement a flexible 2D sprite system alongside Ogre. CEGUI has already wrangled these conflicts into submission for you.

I haven't run into any inconsistencies between DirectX and OpenGL yet, but I'm focusing on the OpenGL render system for windows so that there will be fewer issues porting to the other platforms, and if any inconsistencies do arise in DirectX I can just not support it if I'm feeling too lazy to figure out what the problem is . I'm also using Ogre to do all the UI rendering rather than doing it in 2D so I'm hoping it'll be unlikely that I'll run into any conflicts or hurdles when porting to linux (and maybe mac).

I have wanted to make the switch to CEGUI for a while now as the scrollable windows will make doing things like scrollable tech/research-tree GUIs a breeze. My scrollbars don't yet function, and my font support is nowhere near as good as CEGUIs.

I already got the scrollable stuff working in my UI, and I can support any font that I can be bothered making a bitmap font that uses distance fields .

I accidentally stumbled upon the CEGUI-Unified editor a couple of days ago and after tinkering with it for a bit, I saw how easily I could change the look of the CEGUI::demos with it. This is the point where I finally swallowed my stupid pride and decided to make the switch to CEGUI.

So, given the time I have lost implementing my own solution (because of myriad conflicts between my sprite code and Ogre's PostFilters & ShadowTargets), and given that I got CEGUI working in only a few hours, and also given that CEGUI now has a very nice Drag&Drop GUI editor, I would strongly suggest you spend at least _one_ day playing with CEGUI before you spend any time rolling your own GUI system.

I SURE WISH I HAD!

Yeah CEGUI was certainly looking like the best UI library for my tastes, but I've always found that libraries take me ages to learn and use properly and for something simple like a UI I tend to be much more productive in the long term just writing it myself. I've only spent two weeks on the UI and it's pretty much capable of everything I need already so I really don't need to look into other UIs any more.

[Nickenstein79]

Well, I certainly know where you are coming from. (Like I said, I've stuck to my home-rolled solution alongside Ogre for a year now.)

I have been sticking to my own GUI solution for a long time, as I know it inside-out and it has shipped in a bunch of console games. At the outset I thought "All I need to make this work with Ogre is the ability to render textured 2D quads".

That's all I have ever needed in the past, as I initially wrote the system in straight 'C' (not C++) for a PS2 game, knowing I could easily port 'C' to any platform in the future.
All I needed to make it work on any other console/platform was to wrap some 2D-textured-quad functions. And that worked for me just fine when I got contracts for x360/ps3/Wii games (it's even shipped in a couple of PSP games), as I had full control of rendering.

But with Ogre I just kept running into renderstate conflicts with post-filters and ShadowTargets. (Because they are black-box systems if you use the pre-built stable Ogre releases like I do.)

I guess you can avoid those problems by using a source-code version of Ogre to circumvent the conflicts. But then you run the risk of becoming incompatible with the stable releases of Ogre, and you find that you need to re-edit a bunch of Ogre source files when a new release with lots of features and fixes that you want is released.

It can get very messy.
Imagine you need some help on the forum in the future, and somebody asks "What version are you using?" And your answer is "I'm using 1_8_1, but I have totally changed the source code in the main renderer files to make my sprite system work."

You will find that you are shit out of luck to get any help with that issue.

Save yourself the future pain, dude. Use a known and tested system.

Sure, there is some extra baggage/bloat of new DLLs in your distro, and an additional learning curve to acclimatise yourself with somebody else library. But the pros seriously outweigh the cons here. Trust me. I've lost months by being pig-headed about sticking to my own GUI system.

Believe me, all of this is painful for me to say, because I fucking love my GUI system, and I think it's slick-as-fuck, and it works great in a tonne of shipped console games. But for the sake of staying compatible with future Ogre releases: that's the bitter pill I have to swallow.

[areay]

The reason for me switching is also seen in the video. Whenever I toggle on an Ogre postrender filter effect it interferes with my sprite system and my GUI disappears (some renderstate conflict somewhere), which is no good.
Note that CEGUI does not suffer from this problem, and stays perfectly visible when post-filter effects are applied. Also my sprite code interferes with Ogre's shadow buffer so I have had to disable shadows until now, which again, is no good.

Just wondering if you tried setting your GUI stuff to use the RENDER_QUEUE_OVERLAY Render Queue? I think this is how CEGUI avoids getting mucked about with post-processing.

[Nickenstein79]

Just wondering if you tried setting your GUI stuff to use the RENDER_QUEUE_OVERLAY Render Queue? I think this is how CEGUI avoids getting mucked about with post-processing.

Yeah, tried everything. Changing the render queue orders, making special shadowtarget listeners, making it work in pre-render/post-render, the lot. It's obviously fixable, it just was becoming a time sink that would waste a few days here and there, then I would leave it and get back to making my game. Then waste more time on it later, all the while not being able to use the shadows or post filters that I wanted.

It just became a constant source of annoyance that was always distracting me from actually getting on with coding my game.